🤓🤞 On Tue, 23 Feb 2021 at 15:19, 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 > -- Rgds Andy
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
