This process works really well! Another thought, move the *bak files to a different drive than Unity or your OS if possible (especially if Unity and OS on C drive). This past Sunday, I had a backed up mirror that failed to power up after application of a failed security update. Lost my OS due to critical files missing. I was able to recover the C drive from an earlier mirrored backup drive from August 5th. The OS and Unity came up OK, just was out of date by about 3 weeks! I was able to work with TAC to restore my UnityDb to current because I had the UnityDb.bak available on a different mirror set taken at 3:00 AM that morning. Went into SQL Enterprise Manager and restored the Unity database from the *bak file. The only other folder I needed to restore, which we did from our Veritas backup, was the Stream Files folder. Ran a DbWalker following this recovery with no errors. So having the UnityDb.bak file on a different drive saved my bacon big time.
Thanks Ginger, this is quite an old server that will be replaces shortly. Unfortunatley Unity & OS are on the the C drive and I do not have another drive to change the location to on the server itself, hence the question if there would be any complications using a network drive on another server?
I would be hesitant to use a networked drive. Just a thought - have you already taken steps to clean up your C drive disk files? For example, you can typically delete:
1. All $ntUninstall* and $NtServicePackUninstall* files older than the current month (these are OS and security update uninstall files) from the C:\Windows directory or C:\WinNT if running Windows 2000.
2. From the same directory, all KB*.log files
3. Check for any minidump files and delete if not needed (or copy these to networked drive and delete from C)
Thanks, there were a couple of the $ntUninstall files and I managed to reclaim around 200MB.
The problem is the ReportDb.bak grows to around 300MB and the UnityDb.bak to around 600MB by the end of the week, so I have scheduled the sql weekly backup to run on Wednesday as well as Sunday as it does a full backup and seems to get rid of the daily differential backups hence saving space.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...