Rotated hard drives support in v8

[cladmonitor]

I was under the impression these settings were migrated into the UI for v8, though I can't find them, can we safely assume that the reg keys still work? Also, when do you plan on moving these settings into a per-job attribute?

[GOSTEV] Rotated drives support in previous versions

[Shestakov]

Rotated drives functionality can now be enabled with a checkbox in the advanced backup repository settings, as opposed to being controlled by registry settings (which are still supported for upgrade compatibility reasons).

[VladV]

Does ForceDeleteBackupFiles reg key work in v8 or was it integrated in the UI like ForceCreateMissingVBK has.

[foggy]

The key works as in previous version not to change the product behavior after v8 upgrade, however it was not integrated into UI.

[Gostev]

As of B&R 8.0, rotated drives functionality can now be enabled with a check box in the advanced backup repository settings, as opposed to being controlled by ForceCreateMissingVBK registry settings (which, however, is still supported for upgrade compatibility reasons).

ForceDeleteBackupFiles reg key also works as before, not to change the product behavior after v8 upgrade. However, we strongly recommend deleting this key, because backup files clean up is now integrated, and is done automatically for all Veeam backup files which are no longer under retention policy (see v8 What's New document).

Additionally, v8 backup jobs now track known external hard drives, and "follow" them transparently in case drive letter changes, instead of failing.

[robg]

"This repository is backed by rotated hard drives"

is a new option I assume for v8, meaning the registry change is no longer necessary. Would this mean that if I were to use RDX removable media for offsite backup storage, I need to turn this option on and pretty much that's it?

[Shestakov]

Hello Rob,
Correct, rotated drives functionality can now be enabled with a checkbox in the advanced backup repository settings.
Please review the topic where your post has been merged and ask additional questions if you have any. Thanks.

[Roberto]

We see this funtionality on "veeam backup 8 whats new". This is very useful. But what about reinserting media on weekly basis ? example: we have set of RDX media for week1 and set of RDX media for week2. When we insert set for week1 (first run = clean media) B&R with Backup Copy Job do a full backup on these media and incremental from start to end of week. Next week we insert set for week2 (first run = clean media), again B&R with some Backup Copy Job do a full backup on these media, and incremental from start to end of week. on week 3 we insert again week1. How new retated hard drives support manage this scenario ? can read from repository not present for a week and continue from that point, doing incremental instead of deleting or creating new full backup from scratch and losing restore points history on disk section on Veeam B&R interface ? namely, can manage RDX device somehow intelligent or advanced ?

[veremin]

How new retated hard drives support manage this scenario?

Since some increments are missing, a new full backup will be created. Thanks.

[Roberto]

So if we create n jobs: one for each RDX set with correct schedule, jobs find its chain and continue without doing a full backup ?
ex:
job1 for week1 (starting at next week and so only every 2 weeks)
job2 for week2 (starting after week1 and so only every 2 weeks)

Cannot Veeam B&R add a feature doing this automatically as complete and independent backup chain are always present on RDX. So doing incremental from last full and incremental chain present on RDX ?

[foggy]

So if we create n jobs: one for each RDX set with correct schedule, jobs find its chain and continue without doing a full backup ?

Correct. That's another approach of using rotated drives.

[Roberto]

We done a new test. Veeam B&R v8 does not create a full backup at alternate week RDX set insertion as supposed. At least today, we leave on RDX directories in place containing BCJ files from week 24-30/11/2014 and BCJ with new Rotated Hard Drives management done a incremental backup starting from last incremental found, probably reading from .vbm file. We have also done working Instant Recovery test on new restore point (10/12/2014) and old restore point (at 29/11/2014).

Below restore point file list showing this new restore point on 10/12/2014, also on Veeam B&R console we see all restore point on Backup -> Disk section.

10/12/2014 02:33 269.614 bcj.prod.web.vbm
10/12/2014 02:33 188.043.751.424 bcj.prod.web2014-11-25T220000.vbk
26/11/2014 22:26 14.649.216.512 bcj.prod.web2014-11-26T220000.vib
27/11/2014 22:21 12.630.751.232 bcj.prod.web2014-11-27T220000.vib
28/11/2014 22:30 33.737.952.256 bcj.prod.web2014-11-28T220000.vib
29/11/2014 22:20 9.001.859.584 bcj.prod.web2014-11-29T220000.vib
01/12/2014 04:07 4.884.016.128 bcj.prod.web2014-11-30T220000.vib


Is this assumption correct ? Can some Veeam B&R support person confirm that this is new and correct behavior of Veeam B&R v8 and we can use this without problem ?

[foggy]

Just to confirm, is it the same job that was backing up to the previous RDX set or you have implemented the "one job per RDX set" approach?

[Roberto]

Same job that was backing up to the previous RDX set ! Only one job for all weekly set. Changing RDX sets every week alternating job recognize last backup present on RDX inserted and continue from that.

[veremin]

Actually, If any incremental backups are missing from the drive that is currently attached, backup server should start a backup chain anew, creating a full backup first. Were the results of Instant VM Recovery from this newly-created increment successful? Thanks.

[mark_firestone]

Hello...

I have had a 3 drive rotation for 2 backup jobs for years now, using a script. I upgraded to veeam 8 and apparently the way the jobs work has changed, and the job was killing the script that copied the vbk files to the rdx carts.

I've tried to set up two backup jobs, one for each job (which run on alternate days) to copy them to an rdx cart, one for each job.

Because I only have three rdx carts (so one can be stored off site every night) I tried setting up a script to erase the backup copied to the rdx cart before the backup job being copied runs. I set the repositories as "rotated hard drives".

Veeam doesn't seem to like that, but if I don't do that, it will (I assume) attempt to leave the other job on the cart.

What is the solution? Buy another rdx cart and have two carts per job, or ? All I want is to keep a copy off site. This shouldn't be this hard, should it?

[veremin]

Hi, Mark,

In order to make backup copy job work with rotated media, you have to delete previously created regkey, assign repository role to the said drive, using "Rotated hard drives" option, create a backup copy job and point it to the newly created repository. Are you positive that all required steps have been followed?

Thanks.

[Roberto]

for what we can see... Yes. We tested "Instant VM Recovery" on new (after hole of one week for RDX set) and old (restore point present before ejecting RDX on end of set week) Incremental, without error.

[veremin]

Can you open a ticket with our support team and provide its number here, so that, we can take a look at the described behaviour more thoroughly? Thanks.

[Roberto]

Ticket Reference: 00706341 "New Rotated Hard Drive Support"

[foggy]

Backup copy job is able to continue incremental chain existing on each of the rotated drives. There are several issues, however, that could cause the increment size to be equal to the full backup, they will be addressed in the next patch most likely.

[Roberto]

As we can see, for the most bcj on RDX left off for a week and so inserted back, we have first incremental file about doubled in size in respect of previous incremental files. As now no full size incremental was observed, but it is good to know this behavior is supported and improved in the future.

[meeyou]

Currently I've got a couple of clients set up with a primary backup target and then two little QNAP nas's that they rotate offsite.

I'm using backup copy jobs to replicate to restore points to the QNAPs, but it tends to get behind or just break fairly often, requiring lots of manual intervention.

Is there a better way to do this? Does anyone have any suggestions for achieving a physically carried offsite backup with Veeam?

[veremin]

If you're on version 8 already, then, the recommended approach would be to enable rotated drive option in the settings of repositories backup copy jobs are pointed to and let backup server orchestrate everything in automatic fashion.

Also, I'm wondering what particular errors you come across while dealing with rotated media.

Thanks.

[pawel]

Can this option be used if the external drives have different drive letters? I would like to have 2 external drives with different drive letters that can be used to store some backups off-site. However, when I add the repository I have to specify one path, so there is no way to rotate the drives if they have different drive letters.

Any work around for this?

Thanks.

[Gostev]

v8 will follow known drives regardless of the drive letter.

[pawel]

Do I add this under the repositories or somewhere else?

If I go to create a new repository I have to select a path to a folder. When creating a backup I have to pick a repository. If I have 2 different drives how can I set it up so that the job is targeted to those 2 drives and will automatically pick the one that is plugged in? In backup exec I could create storage pools which backup jobs could target, but a similar option doesn't seem to be available in Veeam (unless I'm mistaken)?

[Gostev]

It just works. Plug-in one drive, backup there. Then plug-in another drive, backup there. They will both become known to B&R, and from this point on it does not matter if their drive letter changes in future.

[foggy]

So the trick is to "introduce" both drives using the same drive letter during the first job runs.

[pawel]

Ok, thanks. So I'll do the following:

- Drive 1 - Assign Drive letter F:
- Add Drive 1 to repository using F:\Backups as the path, select the removable drive option
- Create a new backup job "Test Backup", target to the new repository
- Unplug Drive 1 once job is done and plug in Drive 2
- Assign Drive 2 the letter F:
- Start "Test Backup" job for the second time.

I assume Veeam will create the folder "Backups" or do I need to create it? Am I understanding correctly that if I change Drive 2 to have a drive letter of G:\ once the first backup finishes to it Veeam will automatically switch it over to that drive letter and back again when Drive 1 is plugged in?

I'll try this once the drives are available.