Track my Veeam Restore Point

When using Veeam Backup & Replication, you will see that backup files are created at job level. The good thing is that this introduces job level dedup. However when you look at the backup files, it is hard to identify which file includes which VM. It's not really a problem as the Veeam DB will keep track of this.

But what if you want to copy restore points with another tool? Some companies are still running 2 backup products, one for  physical, one for Veeam. Typically the first application also has the tape library connected. Or what if you just want to copy your backups to the cloud. How are you supposed to know which VM is stored in which files if it is no longer being tracked by backup and replication?

Well this pet project might help a bit. First of all, I just wrote it and it is not tested. The reason is simply not to waste too much time developing something nobody uses. For me the goal was rather to learn some more about PowerShell (I am planning to do some Powershell webinars soon, so need to practice and get some cool examples made). So remember:
  • It's not tested, be careful with it
  • It potentially can generate a lot of data because it is not optimized
  • It won't truncate any data :)
  • Enjoy!
You can find it here

In essence, this powershell script will just query the restore points that are currently active on the Veeam Backup Server. Then it will understand which files are linked to it and insert that data in a SQL db.

So first thing you need to do is to create a database in your SQL server instance.  The default settings will be
  • instance: localhost
  • db : rpdb
  • user : rpdbuser
  • password : rpdbpass
In my test setup I made the rpdbuser db owner of the rpdb. You can change the parameters in the script:
Make sure you have the database setup. Then you can run the script with the -createdb flag. It should create all the tables:
From that moment you can start collecting restore point meta data. If you run the script without filter, all the restore points at that point will be inserted in the db. If you would do this daily, you will see duplicates popping up. This is certainly the case for forward incremental. However if you are using reverse incremental, it makes sense to have duplicate restore points as they have shifted probably from filename.

To get more control over what should be stored and what not, I would recommend using filters to only store the restore points data that you are shipping off site. Then running the collect script as part of a post job or after your copy is done by your third party application.

Collecting data will be done with the -collect switch. However I added a -dry switch so that you can test before you let the powershell script insert data in db. Here are some examples of filtering:

No filter:

-Collectfiles "file1.vbk,file2.vib" which will only store those restore points related to backup files you might have shipped

-Collectonlyfull switch which will only store info about full vbk
-Collectjob "jobname" which makes sense if you run as a postscript on a job
Or just a combination of collectjob and collectonlyfull
If you are happy with the result, remove the dry command and let it run whenever you want to track the state of restore points:

Then you can use the -vm paramter and the -begin and -end parameter (f.e  -vm sharepoint -begin "2013-01-01" -end "2014-02-01") to find a restore point for a certain VM. Remember the date will not be when you tracked it but rather the date when the restore point is created. Then if you find the restore point you like, you can use the -id parameter to understand which file you need to get back to the repository to do a restore for a certain file.

Finally, could you use this functionality in combination with files to tape instead of backup to tape? You could but it still requires you to do a lot manual setup and manual querying and restoring. So if you can, let Veeam track everything and you will have nothing to do and not the worry about setting up anything!

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.