BEXEC 2014 CASO / MMS - Dedup Disaster Recovery planning

[Metatron5196]

Hi all,

We currently have a working BEXEC backup strategy and have recently had a critical hardware failure of an old Exchange 2003 server that required SDR disaster recovery onto a Virtual machine. Few snags on the way and now I need to take a better look at our disaster recovery planning.

We have:

BEXEC 2014 capacity edition (4TB)

Single CASO server with a iScsi attached Dedup storage. (mapped volume on a HP MSA P2000)

Single MMS server with an LTO V tape drive. (only reason for this is its an HP server with correct controller for tape drive) the dedup store was originally on the MMS before installing the CASO but caused performance issues negatively affecting the HyperV services on the same server. Moved dedup to CASO as I had to find a way of getting the backup sets duplicated to tape.

Backups of all servers (8 physical and 8 VM's) are run as Full on friday night, and diff every weekday. Both full and diff sets are immediately duplicated to tape, and tape goes offsite next day. CASO is set for central catalogue. Backups are managed by the CASO but set to run on the MMS so that tape duplication runs. MMS and CASO both has direct access to dedup and tape. All servers / VM guests being backed up with client side dedup, clients have correct direct access to dedup store.

Dedup Full and Diff sets retained for 2 weeks. Tapes retained for 4 weeks.

Total backup set volume approx. 3 TB

The above is working well as the network load is distributed especially when running multiple backup sets at the same time.

Past few weeks's disaster recovery processes and the complications we had has me thinking of the BEXEC setup itself.

Question 1:

In the event of the loss of the MMS server, which is also a Hyper V host, SDR should be easy, as catalogues and Dedup store will be available on the CASO. SDR server first then restore VM's with restore Job from CASO server, etc, etc. However, if i lose the CASO? It is an older server and I am paranoid ... I am considering changing catalogue to replicated. that way the MMS will have catalogues saved, but if the CASO fails so does the dedup store. (all backup sets duplicated to tape) Can the CASO be restored using SDR -EDIT: from tape, of course, after re-cataloging if needed...- (assuming same hardware) and if so will the iScsi connector and the setting for the dedup store be retained?

Question 2:

Might be easier and safer to install a new HP server as standalone BEXEC server and completely remove BEXEC Caso and MMS and start from scratch with a new dedup drive and tape drive for duplication directly attached. Suggestions?

[Metatron5196]

Now that I read my post above i feel a bit sheepish. Should definitely enable replicated catalogue ...

Question 1 needs clarification. Basically, If MMS fails, can i restore (including HyperV services) using SDR from the caso (dedup) - (hopefully SDR will recreate the iScsi intiated drives on the HyperV host and i would not need to restore VM's, but that is for another discussion)

AND

Should the CASO fail, can I restore using SDR from tape easily using the MMS, and will the restored CASO have the iScsi drive and the Dedup store back by default or will I lose my dedup store and have to re-create?

As for question 2:

Single server with single catalogue will mean DR might get complicated. In the event of BEXEC server failure, will have to then rebuild from scratch anyway and Dedup store will be lost. Two servers with replicated catalogues just seem to be a better idea. . . Maybe install a dedicated new MMS with tape drive and keep current CASO so that MMS restore is less complicated (no hyperV or other production services to worry about)

[pkh · Accepted solution]

I think using CASO the way you are using it is an over-kill. Suppose you are not using the capacity edition and you have to pay for the ESO licence. Would you still want to implement CASO to solve your problem? It is easier to recover a dedicated media server using SDR. In this case, you should not backup the media server to the dedup folder because you cannot do a SDR recovery from a dedup folder. Backup to disk or tape is O.k. As for your dedup folder, you can back it up to tape by backing up the shadow copy component of the volume that it resides on

[Metatron5196]

Thanks for the reply pkh.

my full backup set is around 3TB. But retaining data for 2 weeks, and including the odd adhoc backup set, i have an average of 12 TB backup data written to dedup at any time. Only have 1 LTO V tape drive, that is used to duplicate de-dup backup sets. What would the size of the shadow copy component be? Just config and shadow copy file info and save data? Or equal to the full data set size (i.e 12TB) of the backup sets?  

But i see your point. Simpler may be better.

So then a single media server hosting the dedup folder and tape drive. All backup sets running to dedup and still duplicating to tape, and the media server itself backing up direct to tape after the last dedup to tape set has completed. Would you suggest including the shadow copy component for dedup backup at this point or as a seperate backup job?

I can then SDR the bexec media server from tape if I have to and, if the SAN and network is intact, it should (assuming same hardware server) restore the iScsi volume so that dedup folder is available after SDR restore is complete, right? If not I can either create a new dedup folder and modify backup jobs accordingly or restore dedup from the shadow copy component backup from tape...

The production servers will be restorable either way.

If major disaster and SAN is not salvageable, will have to revert to alternative hardware and use tape anyway.

[pkh]

You should backup the dedup folder (shadow copy component) using a separate job.

For recovery, you should recover everything excluding the dedup folder using SDR.  After that, recover the dedup folder.

[Metatron5196]

Thanks.

Still unsure of one thing. Seeing as the dedup folder is on an iScsi volume, if the media server is recovered using SDR, and the iScsi connector is re-connected as part of SDR using the original drive letter, will the dedup folder be available again? assuming the SAN was not affected by the failure of the MMS server? Or will we be forced to either restore dedup from shadow copy or create new?

Dedup currently has 15.2TB backup data written. Used capacity is 5.42TB and dedup ratio 2.81:1. Folder has 1.8TB available... I assume the shadow copy backup will use 5.42TB as it backs up the dedup actual saved data, correct?

I dont think I have enough time to schedule a backup of the dedup shadow copy components... data set simply too big... Will have to be a full, once a week. If dedup needs to be restored it might be as much as a week behind.

[pkh]

If the device on which the dedup folder resides is not affected by the crash then you should be able to connect the dedup folder to the media server after recovery. The disk space that is occupied by the dedup folder is what you have to back up

[Metatron5196]

Thanks for the advice. Much appreciated.