Renaming Rotated Drives Backup Job & Related Backup Directory

[engit]

Support Case: 04137440

We've followed the article here: https://www.veeam.com/kb2174

But this does not seem to apply/work for jobs that use Rotated drives.

So far we've:
- Renamed the backup Job
- Removed backup disk from configuration
- Renamed backup directory
- Tried to re-add/discover backup directory using 'Rescan'

The last step doesn't find the renamed directory and the "Rescan" option when right clicking on the Backup Repository isn't available like it is for other backup repositories.

Is there a way to get Veeam to re-discover the renamed backup directory or to manually enter the path to a backup location?

[Dima P.]

Hello engit,

What is you Veeam B&R version? How many rotated drives you have? Can you import previously created backup to Veeam B&R console via import functionality? Cheer!

[engit]

Hi Dima,

Sorry for the slow response.

Our Veeam B&R version is: 10.0.0.4461 P1
We have 8 rotated drives (All 4TB Seagate)

I believe we can import but the issue we are having is backing up to new drives. The drive shows up in the HyperV host and is set to the same drive letter. We actually use these same rotated drives with another VM backup job which works fine. The job that fails is a 'File Share' job.

[foggy]

Not sure I understand the setup as repositories with rotated drives are not supported for NAS backup (File Share jobs).

[engit]

Thanks foggy, that was our issue. We've switched to a non-rotated repository now and things are working as expected.

[selva]

I see that veeam (B&R 10) errors the first time after a drive letter change (its still looking at the old drive letter) but then succeeds on stopping and restarting the job. For me this happens also with copy backup jobs of VMs, not just file share jobs: logs show drive letter changed to K: (was E:) but then it errors saying could not create E:\veeam-repo which was the original target directory name. On the next run it succeeds.

The difference between the failing and succeeding runs is that the first one started and went idle before the drive letter change (waiting for usage period). But it still notices the drive letter change but not fully, it seems.

Has anyone else seen this?

[foggy]

I recommend asking our support engineers to review this closer to see if it is expected or not.

[selva]

Okay, thatnks: case #04182841

[selva]

I got the following response to my case:

"With backup to rotated drives , the idea is that the device can change without the drive letter changing. If multiple devices are used, they all have to be represented by the same drive."

Go figure!

[foggy]

That doesn't sound right - after being introduced for the first time, a device can change the letter, Veeam B&R will 'follow' the known device. I've seen your comment to the engineer along the same lines, please continue working with him.

[selva]

Still working with support, but here is a follow up as I had to switch the disk yesterday.

Changed to a new disk keeping the drive letter same as required in this case. When triggered on reaching allowed time-frame the job failed -- it was looking for old backups on the disk. During the next run the job succeeded.

In summary this is what I see: when the copy job is in "Idle" state waiting for restore points or allowed time frame, if the disk is swapped in a rotated disk repo, the change is not fully recognized and jobs fails when triggered. As the job restarts for the next cycle it does recognize a new disk on same drive letter or old disk on any drive letter, and works as expected.

I am unable to avoid one failure and associated error notification. My copy jobs are "periodic copy" type, not "immediate copy" and are not allowed to run at all times, so the job stays in "Idle" state most of the time waiting for either restore points or time-frame to run.

[foggy]

Just to check - are you using the ForceCreateMissingVBK registry value by any chance (found an old issue with similar behavior when this value was used)?

[selva]

I haven't set any custom registry values and I don't find that reg value set by the installer either.

[selva]

Finally I have given up on this. More warnings after changing to a new disk -- after an initial error most jobs succeeded on second try starting a new backup chain as expected. But jobs for which new restore points are available only once a week, but copy job still set to look for restore points once a day, I now get daily warnings saying job failed to complete. Probably caused by no backup chain on the new rotated drive as yet, and no new restore points available to trigger a new chain. Will hopefully clear when one becomes available.

Anyway, long story short, I have given up on using rotated drive repos. Instead replaced it by multiple repos one for each disk, a script that detects which disk is available and disables all jobs targeted at disks not online. In my quick tests this seem to work well. Not ideal as the disk(s) are not local to the B&R server so scripts need remote access, adding new disks takes some work, but workable in a small shop like mine. Use of some form of "rotated disks" is critical for us as we swap those disks with those in an offsite storage and is the only air-gapped and offsite backup we have. Cloud storage is not an option as our upload bandwidth is limited and for other reasons. Used to be a backupexec setup which is not a pleasure to use unlike veeam.

Thanks for all the help.

[foggy]

Ok, but if you decide to investigate this further, feel free to involve our engineers - they will be able to track this down. Another guess in this direction is to check if the new drive becomes online in the system after the switch.

[selva]

Yes the drive is online and Copy Backup of VMs that are backed up regularly and copied once a day does work with the new drive (though it errors out in the first run and succeeds next run onwards as I reported).

Support finally wanted a webex session but I've already edited the jobs to use my scripting solution. Also it seems the support engineer I got is new to veeam -- took a few back and forth with a wrong initial response, then claiming logs expired without looking at the logs I uploaded etc.. No complaints, as I'm sure I'l get stellar support if/when we move to a paid version, and hopefully & ideally we'll never need any support.

I'm surprised why no one has reported any of the issues I see with rotated drives. So, it has to be just me and my setup .. hmm..

[foggy]

Could be some environmental specifics, indeed. But a thorough investigation is required to tell for sure.