[cisco-voip] CUCM 12.5 issue with restore

[Andy Carse]

🤓🤞

On Tue, 23 Feb 2021 at 15:19, Lelio Fulgenzi <lelio at 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-bounces at puck.nether.net> *On Behalf Of *Andy
> Carse
> *Sent:* Tuesday, February 23, 2021 5:10 AM
> *To:* Wes Sisk (wsisk) <wsisk at cisco.com>
> *Cc:* Cisco VoIP List <cisco-voip at 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 IThelp at 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.carse at 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) <wsisk at 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.carse at 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) <wsisk at 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.carse at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> --
>
> Rgds Andy
>
>
>
> --
>
> Rgds Andy
>
-- 
Rgds Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210223/6e1573aa/attachment.htm>