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 <le...@uoguelph.ca> 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 <cisco-voip-boun...@puck.nether.net> On Behalf Of Andy > Carse > > Sent: Tuesday, February 23, 2021 5:10 AM > > To: Wes Sisk (wsisk) <ws...@cisco.com> > > Cc: Cisco VoIP List <cisco-voip@puck.nether.net> > > 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 <andy.ca...@gmail.com> 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) <ws...@cisco.com> 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 <andy.ca...@gmail.com> 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) <ws...@cisco.com> 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 <andy.ca...@gmail.com> 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 > > cisco-voip@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > > > > > -- > > > > Rgds Andy > > > > > > > > -- > > > > Rgds Andy > > > > _______________________________________________ > > cisco-voip mailing list > > cisco-voip@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
