[cisco-voip] [External] Re: CUCM 12.5 issue with restore

Tue Feb 23 16:13:58 EST 2021

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 at 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 <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
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20210223/d3c61fc8/attachment.htm>