Restore points on rotated USB drives

[mdg]

I'm running Veeam Backup & Replication 9.0.0.1715 for Hyper-V on Windows Server 2012. I have a backup repository that is two rotated USB drives. The type of the repository is "Microsoft Windows server," and the setting for "This repository is backed by rotated hard drives" is selected. The backups run as expected.

If I try to do a restore and the drive has been swapped, but the backup hasn't yet run, Veeam doesn't yet know it's a different drive, so it only shows me restore points on the drive that is no longer attached. After a backup has run, it does show the correct restore points.

In order to get the restore points on the attached drive before a backup has run, I would think I could go to "Backup Infrastructure," then "Backup Repositories," right-click on the repository, and choose "Rescan repository." But the "Rescan repository" menu item is grayed out, as is the corresponding button in the ribbon above. I found this same problem mentioned here. That post said the grayed-out menu item was by design, to avoid problems with restore points, but I didn't find any workaround mentioned there.

I've also tried going through the properties of the existing backup repository, just clicking "Next" all the way through, and letting it go through the various stages of discovery, registration and configuration at the end, and it still showed the restore points of the drive that was not currently attached.

Finally, I've tried selecting "Import backup," browsing to the .vbm file on the currently attached USB drive, and importing that. After that the current restore points do show up and I can restore from them, but it seems possibly to mess up future backups (maybe the same problem as mentioned in the above forum post). When I tried this, the next scheduled backup turned out to be incremental, not full, even though the drive had been swapped so there was a missing backup in between. I didn't trust that backup so I ran an Active Full one after it was finished.

This post mentions unchecking the "rotated hard drives" option in the settings, rescanning, and then checking the option again, but wouldn't that just lead to the same problems with restore points?

I opened a support case for the incorrect restore point problem (#01974328), but was told there is no workaround as of now. It was recommended that I make a post to the forums with this as a feature request.

So: I would like to request a way to get Veeam to update the restore points after a drive has been rotated but before a backup has run. It doesn't have to happen automatically; a manual way to rescan/update the restore points would be fine. The current situation makes restores especially difficult if the drives are rotated daily, because then the restore points are out of date most of the time every day.

[PTide]

Hi,

Finally, I've tried selecting "Import backup", browsing to the .vbm file on the currently attached USB drive, and importing that.<...> the next scheduled backup turned out to be incremental, not full, even though the drive had been swapped so there was a missing backup in between<...>

It's totally fine. "Import Backup" feature works differently than "Rotated Drives".

This post mentions unchecking the "rotated hard drives" option in the settings, rescanning, and then checking the option again, but wouldn't that just lead to the same problems with restore points?

No, it won't lead to the same problem because there is actually no problem Have you tried the suggested approach?

Thanks


[MODERATOR UPDATE]: The information above is wrong as the mentioned rescan workaround might cause the same problem as Import from rotated media.

[mdg]

No, it won't lead to the same problem because there is actually no problem Have you tried the suggested approach?

I just tried unchecking the "rotated hard drives" option, rescanning the repository, and rechecking that option, and yes, it did work. But if there's no problem, then why is "Rescan repository" grayed out in the first place?

[PTide]

A colleague of mine has notified me that was not fine, so I have to admit that importing a backup from a rotated media can mess up records in db, and the same applies to rescans. I apologise for the misleading information. Should you contact support team in future regarding the backup job to rotated media please refer to case #01959565

[mdg]

My backups run at night and the USB drives are rotated first thing every morning. That means during the day, the restore points that Veeam shows don't match what's on the drive. To do a restore I have to update them somehow. So how is it possible to perform any kind of restore during the day without corrupting Veeam's database?

[foggy]

You could quickly fire up a separate Veeam B&R instance, exclusively for restore, and import the backups there. Not ideal, but still a workaround.

[mdg]

Since I rescanned the repository with the "backed by rotated hard drives" option temporarily unchecked on Nov. 14 (see my post above), older restore points no longer appear even though they are present on the USB drives. All the restore points after Nov. 14 appear. It was mentioned that records might get messed up in the database. Can you clarify exactly what might be messed up? Is it just the list of restore points, or is it anything that might affect the backups themselves (e.g. keeping track of changed blocks incorrectly so that future incremental backups are invalid, or anything like that)?

As suggested, I have installed Veeam on a separate computer for restore only, and successfully imported and restored from various backups (both older and newer than Nov. 14) there. On this restore computer I am using a repository of type "CIFS," mapped to the USB drive attached to the original backup server, with the "backed by rotated hard drives" option not checked. When the drives are rotated on the original backup server and I import new backups on the restore computer, will this cause any database problems on the restore computer?

Finally, are there plans to fix this problem? It seems like a pretty serious bug.

[PTide]

The bug affects only the database while the backup files stay healthy and intact. Importing the backups won't do any harm to the recipient. The problem has been fixed in v9.5.

Thanks