BE15 - Backup to dedup, duplicate to dedup then duplicate to Tape

[Mikey98]

I am setting up a new Backup Exec 2015 environment.  I have the following configuration:

Server A, Central Admin Server, Virtual Machine (VM), Primary Data Centre

Server B, MMS, 8TB dedup storage, VM, Primary Data Centre, SAN connected allowing fast backup of all 60 VMs in Primary DC.

Server C, MMS, 8TB dedup storage, VM, Second Data Centre, SAN connected allowing fast backup of all 30 VMs in Secondary DC.

Server D, MMS, Physical Server, 9TB dedup storage, FC directly connected Tape Library, DR site (no live servers at DR site)

I have 10GbE between all these servers so network bandwidth is not an issue.

I have shared the dedup storage across the three MMS and this works as expected.  I can backup a VM on Server B and then duplicate it to Server D.  However, I would like to also duplicate backups onto tape for long term retention, but I cannot achieve this in one job without making Server D do all the work which then doesn’t allow the fast SAN backup (Hot Add method) to be used.  I have seen various threads relating to the same issue (https://www.veritas.com/community/forums/duplicate-secondary-image-cas-private-cloud-server-directly-attached-tape-library) but I don’t understand if it is possible.  How can I achieve my goal without having to do a separate job on server D to backup each VM again and then duplicate to tape, despite server D already have a backup set for the VM already in its storage?  Is it not possible for the tape drive to be shared between the MMS?

The second issue I have is I cannot change the Catalog from centralized to replicated.  It’s fixed (greyed out) and I cannot find any way to change it.

Any help is greatly appreciated before I log a support ticket.

[pkh]

To share the tape drive, it needs to be physically to each media server which is not possible in your case. For Servers B & C, how are the dedup folders attached to the servers?

[Mikey98]

The dedup folders are on separate HP storage connected via FC to our VMware hosts via FC Switches at each datacentre.  All our live servers our on separate IBM storage.

I don't understand why it can't do something which seems so simple.  The MMS (Server C) actually has all the data it needs in the dedup B2D folder so why can't it be intelligent and do a duplication to tape without the need for a second backup job?

[pkh]

Nobody said that you have to do a second backup. The solution of the discussion that you quoted tells you what needs to be done. Read it again carefully

[Mikey98]

I may be missing something but the solution does not work.  If I create a job on CAS and select "Any Backup Exec Server" it automatically uses server D (the one with the tape drive attached) for the initial backup stage resulting in slow backup times for the first job (approx 50% longer) as it can't use the "Hot Add" feature and instead has to do it over the network.

[pkh]

Which dedup folder did you target the backup job to?

[Mikey98]

The one on Server B which is in the same DC as the VM I am backing up.  So it correctly uses the storage on Server B, but server D actually runs the job, and as a result it can't do the Hot Add as it is outwith the VMware environment.  You can see this in the VMware logs as well.  It doesn't reconfigure Server B to add the disk.

[pkh]

One way is to turn off the sharing of Server B's dedup folder.

[Mikey98]

Thank you very much.  That appears to have fixed my issue.

Do you have any ideas on my second issue regarding the Catalogs setting?  I cannot change to replicated.

[pkh]

Try using the BEUtility

[Mikey98]

I've had a look in the BEUtility but I can't see anyway to change it.  You can change the folder location of the catalog and logs, but nothing regarding making it replicated.

[Colin_Weaver]

The reason for greyed out catalog location probably relates to options selected when installing the ESO license on the CAS server.

However if you think that you need replicated catalogs to allow the duplicate to tape on server D, then you might find enabling server D as a Private Cloud Server may solve the issue (and does not care about the catalog location.)

[mgmasterv2]

if server D (DR site server) runs the job then it would be so much slower, correct me if im wrong.

when server D start backup process data move from site a to site b then from site b  again to site a (client data to backup exec D then move to backup exec B or C dedup storage!)

is this correct?