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 <[email protected]> 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 <[email protected]> On Behalf Of Andy Carse > Sent: Tuesday, February 23, 2021 5:10 AM > To: Wes Sisk (wsisk) <[email protected]> > Cc: Cisco VoIP List <[email protected]> > 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 > [email protected] > > > > 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 <[email protected]> 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) <[email protected]> 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 <[email protected]> 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) <[email protected]> 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 <[email protected]> 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 to > respond. > > > > this is the sftp server syslog output. > > Feb 19 18:29:49 sukucmbkup systemd[1]: Started Session 226 of user support. > > Feb 19 18:29:49 sukucmbkup systemd[1]: Started Session 227 of user support. > > Feb 19 18:29:50 sukucmbkup systemd[1]: Started Session 228 of user support. > > Feb 19 18:29:51 sukucmbkup systemd[1]: Started Session 229 of user support. > > Feb 19 18:29:52 sukucmbkup systemd[1]: Started Session 230 of user support. > > Feb 19 18:29:53 sukucmbkup systemd[1]: Started Session 231 of user support. > > > > any pointers grateful > > > > Rgds Andy > > > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > -- > > Rgds Andy > > > > -- > > Rgds Andy > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
