I'm managing a server and have 2 pieces of backup software installed. I have StorageCraft ShadowProtect and since signing up for a cloud backup provider we have Peaceguard software also. After having them both running for a few days I've come across a problem regarding exchange. It seems that SP is doing its daily (local!) incremental backups and then deleting the log files after. When the Peaceguard online backup kicks in after 6PM (the time when bandwidth stops being expensive!) it cannot properly do an incremental backup of the exchange, as most of the log files are missing.
What I'd like to know, is a way round this without rescheduling SP to only do once a day after the PG backup has completed. This seems like a bit of a step backwards as the reason I've got this setup is so consistent incremental backups can be completed. Is there a flag I can set in the exchange VSS writer to stop it purging the logs? Perhaps if this was the case, I could get it to leave logs then have a batch file or alternative to clear the logs every 24/48 hours? I can't find an option in SP to disable the deletion of the files. Does anyone have any experience with a similar setup, and a potential solution perhaps?
Any help with this would be much appreciated :)
I spoke to shadowprotect support, and they said the deleting of the logs is managed by the Exch VSS writer, so as a consequence I've decided to try disabling the VSS Exchange writer for shadowprotect. I don't know if there is an option somewhere to say to the VSS not to delete the logs. Fortunately, SP has an option to name VSS' that it shouldn't use. I know this will compromise the integrity of the database, but I'm hoping it will still be restorable without too much difficulty. If the worst does happen, I can recover pretty much everything from the latest off-site image and get the exchange database from our cloud provider. I think this is a good compromise as the image will still be restorable (meaning easy recovery from a system crash) and the data will still be avaliable in an un-corrupted state (the exchange!) from the cloud source. Usefully our cloud provider is 20 minutes down the road so practically sneakernet distance ;)
I will be trying a virtual machine restore from the SP backup to see how potentially damaged the database might be when I restore it.
Thanks for all your help, and I wish I could have found a more elegant solution.
I've now disabled the VSS Exchange writer in SP specifically. I am going to attempt a virtual machine restore to check the integrity of the database on the SP backup. Both backup programs seem to be acting as they should. I'm currently in the process of bringing the cloud backup 'up to date' but once its there, I will ask them to check the integrity of the database. Seems this is now solved. I will update with any results.