Hello @AlexeyGoncharov,
you will need the Veeam database to get your backups back from tape.
So, do a - at least - daily configuration backup and store this backup somewhere else where it is safe. The repository on your tape server is not immutable - at least with V11, because it has to be a Windows server. So, either use a immutable repository for your configuration backup or copy it somewhere offline on a USB device or something else.

With this you can recreate your VBR Server and access the backups on tape. Your thought is correct for this one.

As you have your VBR server on a virtual machine, you can create a new windows machine, install VBR on it and restore the configuration backup.

If you ever lost your Veeam server and had to deploy fresh you could import those tapes and restore VMs from it:

https://helpcenter.veeam.com/docs/backup/vsphere/import_tapes_another_server.html?zoom_highlight=import+tape&ver=110
 

Unless you restored your configuration database as @JMeixner has suggested you’d be deploying a new instance hence the article I’ve linked there.

Just some food for thought, you mention all SANs down etc, what would you be restoring to if they’re all gone?

Depending on the size of the environment (and the amount of tapes) the cataloging of the tapes on a new instance will take a lot of time….

And we had some tapes with a lot of small backup sessions on it which we could not catalog at all on a new instance. The catalog process used this much memory that every server we had had not enough RAM to finish this process….

Hi Jochen,

Appreciated for the quick reply. What's from your point of view will be the fastest/optimal way to rebuild VBR Server? vCenter still down, so no templates. ESXi host configuration restore is 10 seconds job, so lets assume we can connect to healthy ESXi. And as you mentioned we have configuration backup + Tape Server with fresh backups on it.

Cheers,

Alexey.

Thank you Michael. Under SANs down I meant data is not available, including the snapshots, etc. Hardware itself is healthy and I have access to it. We have other HA/DR/network techniques in place, but I am building DR plan and want to start with worst case scenario where everything what is accessible on the network is hit by ransomware. 

That is very useful details, I’ll need to measure full cataloging time. Our environment is not big btw so hopefully not so bad.

So to summarize the steps. 

Quarterly I am going to backup physical Tape Server and export VBR Server as OVF to the USB HDD connected to Tape Server. I’ll keep ESXi backups and required scripts on the same drive. 

In case of disaster, I am going to restore Tape Server using the bootable USB HDD. Second step - restore ESXi config using the script on the drive and import VBR Server (in the worst case scenario - 3 months old). VBR server is not AD connected so no DC required at this stage. Connecting to VBR server itself now. If Linux based Immutable repository is available - scan the repository to find the latest backups and proceed with restore. If not - running a cataloging job on the Tapes and restore from Tapes.

Any comments on the steps?

Cheers

I am missing the daily configuration backup. With this you can restore the Veeam database to the date of the last configuration backup on your recovered VBR server.

Thank you once more Jochen.

I was going to do a configuration backup to the repository located on the Tape Server but after your last comment I realized Immutable repository is a right place for it. So after restoring the VBR server (with outdated config) and re-gaining access to the Immutable repository (in case it is available) - I can restore up-to date config from it.

By chance anyone heard about any improvements on storing Configuration Backups in multiple repositories in v12? =)

Unfortunately it is not possible to select multiple locations for the configuration backup in V12 BETA3. So, I am afraid that it will not be possible.

You will have to distribute the configuration backups with a batch script or powershell script.

Thank you for the helpful link!

you can create job copy files on different servers :)

Ok… how do you do it? With a script that executes different configured configuration backups?

I create a job copy file that copies all configuration backups. 
Unfortunately, the feature does not allow deletion of files older than x days. A feature could be proposed for this drawback.

Need to schedule a task with a script in PS that deletes files older than x days.
Usually if I don't have space problems, I keep them all in a compressed dir without scheduling scripts. 

Create 3 or 4 jobs with different destinations example: File server\share\NAS\blob file share etc.

best regards

Ah ok… yes, I did this once, too. And stopped doing this because the old files are not deleted.

I copy the configuration backup files now with a scripted robocopy command.

I still support the feature request to expand the configuration backup dialog with multiple targets. It was given a while ago.

@JMeixner I use file copy too to copy the configuration bck on my xfs repo, i process the retention on the same script used by managing immutable attribute on it. Scheduled by internal crontab management ansible :)

Yes, these a re all valid solutions, but you need some external help for each of them.
So, I would prefer if you could simply configure multiple destinations for the configuration backups.

Unfortunately it is not possible to select multiple locations for the configuration backup in V12 BETA3. So, I am afraid that it will not be possible.

You will have to distribute the configuration backups with a batch script or powershell script.

you can create job copy files on different servers :)

Ok… how do you do it? With a script that executes different configured configuration backups?

 

I create a job copy file that copies all configuration backups. 
Unfortunately, the feature does not allow deletion of files older than x days. A feature could be proposed for this drawback.

Need to schedule a task with a script in PS that deletes files older than x days.
Usually if I don't have space problems, I keep them all in a compressed dir without scheduling scripts. 

Create 3 or 4 jobs with different destinations example: File server\share\NAS\blob file share etc.

best regards

 

 

I use that also in the same way @Link State , the only issue indeed is that it has no feature to delete the target, so the number of .BCO files at the target is getting bigger and bigger. That would be a great feature so we have a functioning workarround.

You can read and import the tapes on a new Veeam server.

Keep your config if possible. You will have to fully configure a new Veeam server, Repo, Tape server, then scan and read EVERY tape in your library. I have a good amount of LTO8 Drives and it took me about 4 days to do that a while ago.  Not great in an outage to tell everyone it’s going to take 4 days to get started on the restores which will most likely take a while too.