change request list for DR

[larry]

First I think Veeam is a great program.

Yet I do have a change request list.

1) Chain jobs within UI.
See below –
A) Job Success do job X
b) First retry do job x
c) last retry do job x
d) last fail do job X
This would also allow each VM to be placed in its own drive/folder. I have some VMs I don’t want stored with their backup VM. Restoring from tape would allow me to only restore the VM not and other VMs with it. I know I can do this with power scripts now, just that the UI would make it perfect. With this I could have each VM have its own job if I wanted. With each VM in its own folder I then know how much space each VM is taking up. Some VMs I want a month of backups some only a week. When I need to do a DR restore I have a order that VM's are to be restored depending on priorty. My DR tape restores takes over 6 hours but the VM's are writen in the right order to restore.

2) Allow each VM in a job to be stored by it self in its own drive / folder. With item one I don’t need this request.

3) write a log file in standard SQL format that I can just run the log from tape and update what ever Veeam server I am restoring the backup to. This way all the information about the backup goes with the backup. For each backup file you would have a sql log that went with it. When I click import backup, it would do what it does now and then run the sql log updating the Veeam database, I would have a complete import with the job information as well. This would make DR much easier if a job had a warning or error. Example. If a file got skipped I could take it for the day before or at least I would know it got skipped. Restoring files from a year before would be self contained. If I restore the SQL production Veeam database to the DR Veeam server then I lose the information that was on the DR Veeam server. If this is too hard then a utility that can combine two Veeam databases would also work.

I been doing a new DR plan all week and these are the things I have found with Veeam. If I am just missing some way of doing any of these things please let me know, I am still new to Veeam.

for my setup see http://www.veeam.com/forums/viewtopic.php?f=2&t=3703
Highlights : Don't know our time to restore yet but it looks like it will take just a few minutes plus window boot times when tapes are not involved, 99% of the time we will not be using tapes. Tapes will only be used with data corruption and with the Veeam servers remove from AD and isolated, a virus should not be able to spread to them. My old DR procedures took a day or more to get going with 4 tech’s. Now one tech should be able to bring up the whole DR site and run the tests or bring live, while the rest of us sleep 

[Gostev]

Hello Larry,

1. Couple of questions:
a) If (2) is resolved, how high the importance of this functionality remains?
b) Are bullets (b), (c), (d) really important and why? While (a) was requested before, this is the first time these bullets are requested.

2. The upcoming v5 release will allow to present any backup file as an NFS share with all VMs placed in their own folders, so this should allow you to easily perform tape exports of individual VMs in an uncompressed form.

3. I don't think I am getting your description here. What do you want to update Veeam server with when restoring backup from tape and importing it into Veeam server for recovery? Are you possibly talking about backing up and restoring Veeam server jobs and configuration?

Thanks!

[larry]

If 2 places each VM in own folders then most of the others a can work around.

1) You would need at least a and D. If a job fails you need to then keep the chain going. You cant do on every fail or the chain would branch to a new chain on each fail. B and C you could drop.

2) I dont mind the files in compressed form just want each VM in its own folder. With the nice import backup it was very easy to restore to the DR veeam server.

3) When a job runs you update the veeam database with all the job resuts and file names. If when you wrote to the DB you also wrote to a sql re-enter file then when you import the backup you would run the re-enter file and have all the information about the backup you just restored. In my testing I had a error on a VM, doing the restore at the remote site I had no way of knowing this, without the veeam job log I couldn't tell what went wrong. If the reenter file was there and it imported to the DR veeam database I would of just looked at the log and been done withit. By the way my error was caused by me doing a replication and a backup at the same time to the same vm, this is why I need that chain function.


Right now it looks like some VMs will be backed up to three spots and replicated once. I would not of dreamed this protection before but with Veeam we can. I am backing up to both sites and backing up to a copy that keeps 32 days worth but no tape. The other local copy we do a full once a week and write to tape nightly. We were doing just 2 copies but with keeping 32 days worth and full backups weelky, tapes got too big. We still might use 2 and just backup the newest file to tape.

Thanks for you quick replys, everyday. I am just about done with my setup so you won't hear as much from me now, you can now help others

[Gostev]

1. Agree, A and D make perfect sense.

2. Sounds good. Producing one backup file per VM is not our strategic direction, instead we are investing in deduplication to reduce the disk space used by backups. And for deduplication to be useful, you need to have multiple VMs in the same file. If you organize your jobs in dedupe-friendly way (put VMs made from the same template together), then you will get backup files equal to size of one VM, but containing multiple VMs. For instance, we recently did some v5 improved dedupe testing with 12 10GB Windows 2003 servers with different data, some were made from the same template, other were installed manually. The backup file was just 18GB (for 120GB of original data). Yes, it is a little more than one separate uncompressed VM, but imagine how many tapes, and how much time and traffic you save having 10x less backup data to copy to tape or to remote site across WAN.

3. OK, thanks for explanation, I understand your thinking now. I have to correct you though: with backup, you do not need to tell new Veeam server the history of this backup (that previous run was bad). Veeam server will understand this while importing your backup file, and will not provide you with option to restore from those failed passes.

[larry]

2) I didn’t realized why you were combining all the VMs into one large file. I would agree then doing it my way does not make as much since. I saw the size of the files and thought it was just the compression you were using and not dedupe. We will be doing lots of window servers and the smaller files would be better. I will just need to redo my tape jobs to backup only things less than a week old.
It would be nice to be able to replicate the combined backup file between Veeam servers. I find it quicker to do two backups than to Rsync. The only problem I have with two backups is one will fail if the other one is still going. The way would be if one Veeam server could start a job on a second Veeam server. I know you are close to this because I can start a job using the enterprise manager. If the chaining of jobs could go between VM servers would fix this also. I could use my SAN to replicate the file but I am using Veeam to backup my SAN.

3) You don't need to tell Veeam but when you are holding the tape and one VM is missing a restore point for the day and you don't know why the log would be nice. What happened during our DR test was that a VM didn't restore, No restore point for our test date, we didn't kow why, looking at the production veeam server we found out why but remotly we had no ay of knowing. This is the reason I wanted each VM in their own folder and own file. Now with your reply to #2 I see that is not what I want to do, I want the job details for that backup file. Maybe the quick fix would be to have the HTML report automaticly stored with the backup files. Would be nice if when a old backup is deleted the log gets deleted with it.