Move backup to different media type repository

[Matts N]

Hello all!
I have to admit I have only done a quick search of the forums, to see if I could find an answer for this. I will refer to what I found, although they don't answer my question.

I have a customer with an EMC DataDomain DD2500. Half is used as a VTL and the other half for CIFS. The VTL part was used by another vendor backup solution that we are now getting rid of. The CIFS part is used by VBR as a backup copy repository. Primary repository is on faster disks, keeping 30 restore points. Backup copy is a GFS rotation to the DD2500.

We want to move the existing GFS rotation from CIFS to VTL while keeping retention! There are yearly backups on there and we want to free up the disk used by CIFS so VTL can use it instead. And since we are redirecting the existing GFS rotation to the VTL (new repository) the cleanup won't happen on the old, now non-used repository. Or am I missing some great existing feature here?

The reasons for moving from CIFS to VTL are two:
1) Performance: moving from 1Gb LAN to 4Gb SAN
2) Security: think crypto viruses...

Why not go DD Boost? Customer doesn't have the money for it and if VTL works, why spend them even if they did have them?

I found one thread here about moving a DD repository from CIFS to DD Boost (veeam-backup-replication-f2/moving-back ... 23978.html), but I can't see this helping us. How would the VTL know which data belongs on which "tape"? And how would VBR know??

There is also the useful KB 1729, if you move from disk to disk. But... no help in this case.

Veeam, I can see this being a problem for a lot of users not too distant in the future. Moving any kind of repository (especially GFS) between disk, tape, HP Catalyst or EMC DD Boost repositories will come to happen and we all want to keep existing retention. Here keeping a yearly backup for 10 years isn't uncommon and even if we stretch the lifetime of the hardware running the repository I would expect to have to move the repository at least once during those 10 years. Yes, VBR isn't an archive solution, but looking back, from my experience a lot of companies use their backup for this purpose as well.

Oh well, feels like I digress somewhat. Back to the original question: How can I move a GFS rotation from a disk repository to a tape repository while keeping retention and awareness in VBR? If needed, I will happily open a case to work with support to solve this, just let me know!

// Matts

[PTide]

Hi,

You can add your VTL into Veeam console as a tape library, setup a Backup to Tape Job and specify your CIFS repository as a source. The job will copy the whole repository to VTL.

Unfortunately you'll need to either manage your retention manually until the oldest backup from your "older" GFS backup set expires, or to configure tape retention so that the whole GFS set stays untouched until it expires. You can reconfigure your Backup to Tape job to use GFS media pool as a target, and primary backup job as a source in order to copy backups from your main repo in a GFS fashion.

Thank you.

[veremin]

Once the data is written to tapes, it might be worth protecting them manuallyso that they don't get overwritten accidentally. (as far as I understood you want to have those backups on tapes for long-term retention purposes)

Those tapes that host the data you no longer need can be unprotected and re-used further. However, as Pavel's mentioned, that would be a manual process.

Thanks.

[Matts N]

Hello Vladimir!
I hear what you say about moving and manually manage retention, Changing the copy job from Backup Copy to Tape Copy while leaving the existing backups where they are (ie on disk) would mean the same thing, I guess, manually manage retention.

I will think about this a couple more laps in my head and see what I end up with. Protecting the tapes until they expire and then automatically making them available for other jobs would probably solve the retention (both protecting the tapes until retention is past as well as giving them back for other jobs). Need to find out if that's possible first.

Thanks for your reply!

[veremin]

I hear what you say about moving and manually manage retention, Changing the copy job from Backup Copy to Tape Copy while leaving the existing backups where they are (ie on disk) would mean the same thing, I guess, manually manage retention.

Correct, though tapes would work more reliably for long-term retention scenario. The price per GB of data would be also cheaper.

I will think about this a couple more laps in my head and see what I end up with. Protecting the tapes until they expire and then automatically making them available for other jobs would probably solve the retention (both protecting the tapes until retention is past as well as giving them back for other jobs). Need to find out if that's possible first.

If I were you, I would probably enumerate the data first, like when a particular tape hosting particular backup should expire and, thus, be erased. Once it's created, it would be just a matter of checking the list and taking actions in accordance.

Thanks.