Re: [cisco-voip] [External] Re: CUCM 12.5 issue with restore
It doesn’t have to be empty as such, it’s just that at some point there seems to be an issue where the restore function seems to go awry. The backup works but, a restore isn’t able to find the backup files to restore for some reason which doesn’t show in the drf logs. To “fix” the issue it would seem that create a new directory and copy the backup files to it and the restore wizard should work. Andy On Tue, 23 Feb 2021 at 20:58, Hunter Fuller wrote: > Surely "try again with an empty directory" defeats the purpose if the > goal is to restore a backup, no? > > If the directory has to be empty, it isn't much of a backup - right? > > -- > Hunter Fuller (they) > Router Jockey > VBH Annex B-5 > +1 256 824 5331 > > Office of Information Technology > The University of Alabama in Huntsville > Network Engineering > > On Tue, Feb 23, 2021 at 9:19 AM Lelio Fulgenzi wrote: > > > > > > > > I have found, and I didn’t think of this earlier, that sometimes a clean > directory works much better. It has to do with the XML files that remain > explaining what is supposed to be in there. > > > > > > > > I didn’t notice this as much with the core apps as I did with the > express apps, like CUE. IT drove me nuts for weeks. > > > > > > > > So, yes, I too have “try a new, empty directory” on my list of things to > try (in my head which I forget all the time). > > > > > > > > > > > > > > > > From: cisco-voip On Behalf Of Andy > Carse > > Sent: Tuesday, February 23, 2021 5:10 AM > > To: Wes Sisk (wsisk) > > Cc: Cisco VoIP List > > Subject: Re: [cisco-voip] CUCM 12.5 issue with restore > > > > > > > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender and > know the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca > > > > > > > > So I’m now confused, by changing the backup directory to a new directory > on our work system I can now backup and restore. > > > > It still doesn’t like to restore from the original location but will > backup to it. > > > > The permissions are the same for both. The def logs don’t show any > issues. > > > > So I’ll add it to our list of things to check in the future. > > > > Case closed > > > > > > > > > > > > On Sun, 21 Feb 2021 at 14:21, Andy Carse wrote: > > > > So, > > > > I configured a new location for the backups to be stored (a subdirectory > on the original) > > > > did a few backups to it from the cluster no problems as usual. > > > > ran the restore wizard it found the recent backups no issues, I even ran > a backup just to make sure as its my lab environment. > > > > then I copied the contents of the original backup directory into the new > location. > > > > Ran the restore wizard expecting it to time out, but no it found the > relevant files. > > > > So I'm a bit stumped. > > > > > > > > Now as this is my Lab its not exactly the same as the work environment > (network infrastructure etc) So I will raise a change control Monday so > I'll see if I can replicate the issue in Production. > > > > Just to be clear the original issue is with running the Restore Wizard > and not being able to see the backup just taken. > > > > So it's not a cop file mismatch, different versions of the cluster, it's > not file permissions. > > > > So I suggest that don't take it for granted that if you can backup your > cluster that you will be able to restore should you need to, you need to > test it periodically. > > > > Any how I'll update with the outcome. > > > > > > > > Rgds Andy > > > > > > > > > > > > On Sat, 20 Feb 2021 at 14:19, Wes Sisk (wsisk) wrote: > > > > Andy, sounds like a good start: > > > > > https://community.cisco.com/t5/ip-telephony-and-phones/disaster-recovery-problem/td-p/2767755 > > > > > > > > I see 2 other situations that might be relevant: > > > > 1. All the same .cop files not installed > > > > 2. Attempting to restore a backup of a different version > > > > > > > > > > > > -Wes > > > > > > > > On Feb 19, 2021, at 6:46 PM, Andy Carse wrote: > > > > > > > > Wes, > > > > I select Restore Wizard then select the backup device > > > > click next > > > > The Ccx then spins the hour glass for 5 mins then says > > > > “Restore request timing out. Either master agent is down or Sftp server > is inaccessible or too slow to respond” > > > > > > > > It’s the same location all the other UC apps backup to. Could it be that > there are too many files in the directory? > > > > Even though they would have different names etc? > > > > > > > > It seems to do a couple of hundred new sessions for some reason looking > at the backup server syslog. > > > > It’s keeping 14 versions of cucm cluster backups is that too many, > although I’ve not seen anything to say so. > > > > > > > > I’m going to change the file path tomorrow and see what happens with > that. > > > > > > > > Andy > > > > > > > > On Fri, 19 Feb 2021 at 19:16, Wes Sisk (wsisk) wrote: > > > > What is the exact error?
Re: [cisco-voip] [External] Re: CUCM 12.5 issue with restore
my question is do you have backups from a different version? I have found that If I have backups from a different version in the same directory it can cause the same problem. We only keep about a week of backups before we delete. But the backup server is then backed up to our long term storage so I can go back much longer if needed. YMMV Scott On Tue, Feb 23, 2021 at 1:00 PM Hunter Fuller via cisco-voip < cisco-voip@puck.nether.net> wrote: > Surely "try again with an empty directory" defeats the purpose if the > goal is to restore a backup, no? > > If the directory has to be empty, it isn't much of a backup - right? > > -- > Hunter Fuller (they) > Router Jockey > VBH Annex B-5 > +1 256 824 5331 > > Office of Information Technology > The University of Alabama in Huntsville > Network Engineering > > On Tue, Feb 23, 2021 at 9:19 AM Lelio Fulgenzi wrote: > > > > > > > > I have found, and I didn’t think of this earlier, that sometimes a clean > directory works much better. It has to do with the XML files that remain > explaining what is supposed to be in there. > > > > > > > > I didn’t notice this as much with the core apps as I did with the > express apps, like CUE. IT drove me nuts for weeks. > > > > > > > > So, yes, I too have “try a new, empty directory” on my list of things to > try (in my head which I forget all the time). > > > > > > > > > > > > > > > > From: cisco-voip On Behalf Of Andy > Carse > > Sent: Tuesday, February 23, 2021 5:10 AM > > To: Wes Sisk (wsisk) > > Cc: Cisco VoIP List > > Subject: Re: [cisco-voip] CUCM 12.5 issue with restore > > > > > > > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender and > know the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca > > > > > > > > So I’m now confused, by changing the backup directory to a new directory > on our work system I can now backup and restore. > > > > It still doesn’t like to restore from the original location but will > backup to it. > > > > The permissions are the same for both. The def logs don’t show any > issues. > > > > So I’ll add it to our list of things to check in the future. > > > > Case closed > > > > > > > > > > > > On Sun, 21 Feb 2021 at 14:21, Andy Carse wrote: > > > > So, > > > > I configured a new location for the backups to be stored (a subdirectory > on the original) > > > > did a few backups to it from the cluster no problems as usual. > > > > ran the restore wizard it found the recent backups no issues, I even ran > a backup just to make sure as its my lab environment. > > > > then I copied the contents of the original backup directory into the new > location. > > > > Ran the restore wizard expecting it to time out, but no it found the > relevant files. > > > > So I'm a bit stumped. > > > > > > > > Now as this is my Lab its not exactly the same as the work environment > (network infrastructure etc) So I will raise a change control Monday so > I'll see if I can replicate the issue in Production. > > > > Just to be clear the original issue is with running the Restore Wizard > and not being able to see the backup just taken. > > > > So it's not a cop file mismatch, different versions of the cluster, it's > not file permissions. > > > > So I suggest that don't take it for granted that if you can backup your > cluster that you will be able to restore should you need to, you need to > test it periodically. > > > > Any how I'll update with the outcome. > > > > > > > > Rgds Andy > > > > > > > > > > > > On Sat, 20 Feb 2021 at 14:19, Wes Sisk (wsisk) wrote: > > > > Andy, sounds like a good start: > > > > > https://community.cisco.com/t5/ip-telephony-and-phones/disaster-recovery-problem/td-p/2767755 > > > > > > > > I see 2 other situations that might be relevant: > > > > 1. All the same .cop files not installed > > > > 2. Attempting to restore a backup of a different version > > > > > > > > > > > > -Wes > > > > > > > > On Feb 19, 2021, at 6:46 PM, Andy Carse wrote: > > > > > > > > Wes, > > > > I select Restore Wizard then select the backup device > > > > click next > > > > The Ccx then spins the hour glass for 5 mins then says > > > > “Restore request timing out. Either master agent is down or Sftp server > is inaccessible or too slow to respond” > > > > > > > > It’s the same location all the other UC apps backup to. Could it be that > there are too many files in the directory? > > > > Even though they would have different names etc? > > > > > > > > It seems to do a couple of hundred new sessions for some reason looking > at the backup server syslog. > > > > It’s keeping 14 versions of cucm cluster backups is that too many, > although I’ve not seen anything to say so. > > > > > > > > I’m going to change the file path tomorrow and see what happens with > that. > > > > > > > > Andy > > > > > > > > On Fri, 19 Feb 2021 at 19:16, Wes Sisk (wsisk) wrote: > > > > What is the exact error? What
Re: [cisco-voip] [External] Re: CUCM 12.5 issue with restore
I feel like it’s old files that gum up the works. Like you’re set to save 3 copies and you have some files from last year. I also see It break stuff with old files where the backup looks like it’s ok, but reports failed. Clean up the old stuff and it runs fine again. Sent from my iPhone > On Feb 23, 2021, at 2:00 PM, Hunter Fuller via cisco-voip > wrote: > > Surely "try again with an empty directory" defeats the purpose if the > goal is to restore a backup, no? > > If the directory has to be empty, it isn't much of a backup - right? > > -- > Hunter Fuller (they) > Router Jockey > VBH Annex B-5 > +1 256 824 5331 > > Office of Information Technology > The University of Alabama in Huntsville > Network Engineering > >> On Tue, Feb 23, 2021 at 9:19 AM Lelio Fulgenzi wrote: >> >> >> >> I have found, and I didn’t think of this earlier, that sometimes a clean >> directory works much better. It has to do with the XML files that remain >> explaining what is supposed to be in there. >> >> >> >> I didn’t notice this as much with the core apps as I did with the express >> apps, like CUE. IT drove me nuts for weeks. >> >> >> >> So, yes, I too have “try a new, empty directory” on my list of things to try >> (in my head which I forget all the time). >> >> >> >> >> >> >> >> From: cisco-voip On Behalf Of Andy Carse >> Sent: Tuesday, February 23, 2021 5:10 AM >> To: Wes Sisk (wsisk) >> Cc: Cisco VoIP List >> Subject: Re: [cisco-voip] CUCM 12.5 issue with restore >> >> >> >> CAUTION: This email originated from outside of the University of Guelph. Do >> not click links or open attachments unless you recognize the sender and know >> the content is safe. If in doubt, forward suspicious emails to >> ith...@uoguelph.ca >> >> >> >> So I’m now confused, by changing the backup directory to a new directory on >> our work system I can now backup and restore. >> >> It still doesn’t like to restore from the original location but will backup >> to it. >> >> The permissions are the same for both. The def logs don’t show any issues. >> >> So I’ll add it to our list of things to check in the future. >> >> Case closed >> >> >> >> >> >> On Sun, 21 Feb 2021 at 14:21, Andy Carse wrote: >> >> So, >> >> I configured a new location for the backups to be stored (a subdirectory on >> the original) >> >> did a few backups to it from the cluster no problems as usual. >> >> ran the restore wizard it found the recent backups no issues, I even ran a >> backup just to make sure as its my lab environment. >> >> then I copied the contents of the original backup directory into the new >> location. >> >> Ran the restore wizard expecting it to time out, but no it found the >> relevant files. >> >> So I'm a bit stumped. >> >> >> >> Now as this is my Lab its not exactly the same as the work environment >> (network infrastructure etc) So I will raise a change control Monday so I'll >> see if I can replicate the issue in Production. >> >> Just to be clear the original issue is with running the Restore Wizard and >> not being able to see the backup just taken. >> >> So it's not a cop file mismatch, different versions of the cluster, it's not >> file permissions. >> >> So I suggest that don't take it for granted that if you can backup your >> cluster that you will be able to restore should you need to, you need to >> test it periodically. >> >> Any how I'll update with the outcome. >> >> >> >> Rgds Andy >> >> >> >> >> >> On Sat, 20 Feb 2021 at 14:19, Wes Sisk (wsisk) wrote: >> >> Andy, sounds like a good start: >> >> https://community.cisco.com/t5/ip-telephony-and-phones/disaster-recovery-problem/td-p/2767755 >> >> >> >> I see 2 other situations that might be relevant: >> >> 1. All the same .cop files not installed >> >> 2. Attempting to restore a backup of a different version >> >> >> >> >> >> -Wes >> >> >> >> On Feb 19, 2021, at 6:46 PM, Andy Carse wrote: >> >> >> >> Wes, >> >> I select Restore Wizard then select the backup device >> >> click next >> >> The Ccx then spins the hour glass for 5 mins then says >> >> “Restore request timing out. Either master agent is down or Sftp server is >> inaccessible or too slow to respond” >> >> >> >> It’s the same location all the other UC apps backup to. Could it be that >> there are too many files in the directory? >> >> Even though they would have different names etc? >> >> >> >> It seems to do a couple of hundred new sessions for some reason looking at >> the backup server syslog. >> >> It’s keeping 14 versions of cucm cluster backups is that too many, although >> I’ve not seen anything to say so. >> >> >> >> I’m going to change the file path tomorrow and see what happens with that. >> >> >> >> Andy >> >> >> >> On Fri, 19 Feb 2021 at 19:16, Wes Sisk (wsisk) wrote: >> >> What is the exact error? What do DRS logs show? >> >> >> >> I see one report that after re-install dbreplication is
Re: [cisco-voip] [External] Re: CUCM 12.5 issue with restore
Surely "try again with an empty directory" defeats the purpose if the goal is to restore a backup, no? If the directory has to be empty, it isn't much of a backup - right? -- Hunter Fuller (they) Router Jockey VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering On Tue, Feb 23, 2021 at 9:19 AM Lelio Fulgenzi wrote: > > > > I have found, and I didn’t think of this earlier, that sometimes a clean > directory works much better. It has to do with the XML files that remain > explaining what is supposed to be in there. > > > > I didn’t notice this as much with the core apps as I did with the express > apps, like CUE. IT drove me nuts for weeks. > > > > So, yes, I too have “try a new, empty directory” on my list of things to try > (in my head which I forget all the time). > > > > > > > > From: cisco-voip On Behalf Of Andy Carse > Sent: Tuesday, February 23, 2021 5:10 AM > To: Wes Sisk (wsisk) > Cc: Cisco VoIP List > Subject: Re: [cisco-voip] CUCM 12.5 issue with restore > > > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca > > > > So I’m now confused, by changing the backup directory to a new directory on > our work system I can now backup and restore. > > It still doesn’t like to restore from the original location but will backup > to it. > > The permissions are the same for both. The def logs don’t show any issues. > > So I’ll add it to our list of things to check in the future. > > Case closed > > > > > > On Sun, 21 Feb 2021 at 14:21, Andy Carse wrote: > > So, > > I configured a new location for the backups to be stored (a subdirectory on > the original) > > did a few backups to it from the cluster no problems as usual. > > ran the restore wizard it found the recent backups no issues, I even ran a > backup just to make sure as its my lab environment. > > then I copied the contents of the original backup directory into the new > location. > > Ran the restore wizard expecting it to time out, but no it found the relevant > files. > > So I'm a bit stumped. > > > > Now as this is my Lab its not exactly the same as the work environment > (network infrastructure etc) So I will raise a change control Monday so I'll > see if I can replicate the issue in Production. > > Just to be clear the original issue is with running the Restore Wizard and > not being able to see the backup just taken. > > So it's not a cop file mismatch, different versions of the cluster, it's not > file permissions. > > So I suggest that don't take it for granted that if you can backup your > cluster that you will be able to restore should you need to, you need to test > it periodically. > > Any how I'll update with the outcome. > > > > Rgds Andy > > > > > > On Sat, 20 Feb 2021 at 14:19, Wes Sisk (wsisk) wrote: > > Andy, sounds like a good start: > > https://community.cisco.com/t5/ip-telephony-and-phones/disaster-recovery-problem/td-p/2767755 > > > > I see 2 other situations that might be relevant: > > 1. All the same .cop files not installed > > 2. Attempting to restore a backup of a different version > > > > > > -Wes > > > > On Feb 19, 2021, at 6:46 PM, Andy Carse wrote: > > > > Wes, > > I select Restore Wizard then select the backup device > > click next > > The Ccx then spins the hour glass for 5 mins then says > > “Restore request timing out. Either master agent is down or Sftp server is > inaccessible or too slow to respond” > > > > It’s the same location all the other UC apps backup to. Could it be that > there are too many files in the directory? > > Even though they would have different names etc? > > > > It seems to do a couple of hundred new sessions for some reason looking at > the backup server syslog. > > It’s keeping 14 versions of cucm cluster backups is that too many, although > I’ve not seen anything to say so. > > > > I’m going to change the file path tomorrow and see what happens with that. > > > > Andy > > > > On Fri, 19 Feb 2021 at 19:16, Wes Sisk (wsisk) wrote: > > What is the exact error? What do DRS logs show? > > > > I see one report that after re-install dbreplication is not established > leading to "Unable to send network request to master agent. This may be due > to Master or Local Agent being down” > > > > Resolved by resetting dbrepliaction for all nodes. > > > > Thanks, > > Wes > > > > On Feb 19, 2021, at 1:51 PM, Andy Carse wrote: > > > > So I thought that if a CUCM could backup to and sftp server without issue, > that it would be able to restore. > > But that turns out to be wrong. > > > > The cluster can backup to sftp without issue, but when I try to restore said > backup, the restore seems to make a large amount of ssh connections and times > out saying the DRS maybe down of the sftp server is tacking too long
