Skip to main content
  • EN

I’m just learning this software and I was wondering what were to happen if my backup server computer was destroyed or something went wrong and how I would be able to access the backup from a new computers server?

I saw this article:  https://helpcenter.veeam.com/docs/backup/vsphere/importing_backups.html?ver=120

But it mentions:

  • The server from which you plan to import backups must be added to the backup infrastructure. Otherwise, you will not be able to access backup files.

So I am wondering - how can I add that server to a new computers server if the original server is gone?  Would this mean those backups are never able to be recovered?  

Normaly i recommend to have a configuration backup of your server. It's very small and easy. This is the fastest way for DR of your Backup Server. 

If not dont worry. All Backup files are self describing and survive without anything from your backup Infrastructure. Just Import it and your able to restore.

Just as Matthias said be sure to have a configuration backup or at least the job configurations written down somewhere.  Then when you deploy the new VBR server just add the server which is the repository and rescan it to import backups to the console.  You can then if you need to recreate jobs map the backups or start new.

Configuration backup information - Creating Configuration Backups - User Guide for VMware vSphere (veeam.com)

Fully agree with Matthias and Chris. Please also keep in mind to document your used encryption passwords. If you are also using Enterprise Manager, this would be easier to recover them.

Also a good idea to keep the configuration database backup somewhere accessible to the new server.  In my case, it is in a DFS replica set so that it’s replicated among file servers.  Others have used file copy jobs to copy it to a secondary location.  If you have a VCC provider that you use, you can keep it there.  That said, wherever you put it, make sure you have your config database is encrypted (so that it saves all your passwords and such) and that you have the encryption password well documented.  If you do keep it in a VCC space, you’re going to want to keep your information for that repository accessible as well.  In my case, I had a client that went full down and the VBR server was a VM, so I had to build a new server, install VBR, then connect to the VCC repo, then import the database from there and supply the encryption password.  Then connect to new infrastructure that I put in place and THEN I was finally able to begin restoring VM’s.  It was a long path to get there, but it was successful.  

Also a good idea to keep the configuration database backup somewhere accessible to the new server.  In my case, it is in a DFS replica set so that it’s replicated among file servers.  Others have used file copy jobs to copy it to a secondary location.  If you have a VCC provider that you use, you can keep it there.  That said, wherever you put it, make sure you have your config database is encrypted (so that it saves all your passwords and such) and that you have the encryption password well documented.  If you do keep it in a VCC space, you’re going to want to keep your information for that repository accessible as well.  In my case, I had a client that went full down and the VBR server was a VM, so I had to build a new server, install VBR, then connect to the VCC repo, then import the database from there and supply the encryption password.  Then connect to new infrastructure that I put in place and THEN I was finally able to begin restoring VM’s.  It was a long path to get there, but it was successful.  

Good call out there Derek.  We keep ours in S3 (HCP Cloud Scale) in one of our DCs.  All VBR servers send there and it is Immutable too.

Comment


Terms & Conditions