Planning for

[fred3]

I've been using VEEAM Backup & Replication Community Edition for years. Well, the pace of events is pretty low key so I can't say that I've learned all that much in that time.

Recently, I had a bad experience and I'm trying to figure out why?
My own main workstation crashed and I went to restore on a new drive. It didn't work.
Now, I have to say that VEEAM BnR had been signalling backup failures now and then. But, since it also reported OK backups, I felt the issue must have been some interference with other backup software or .... ?
In the end, it turned out that the SSD main drive was corrupted beyond saving.
So, I have to ask, what does that necessarily have to do with VEEAM and how would one know?
Anyway, my safety valve was of no help.
And, it wasn't the first time that the recovery software wasn't able to reliably find the backup file(s).
There are lessons to be learned from this but I'm too inexperienced with it to know what all they might be.

So, I'm reviewing the entire approach in moving forward.

Here's what I've been doing:
1) Install VEEAM BnR CE.
2) Generate recovery media.
3) Configure the backup on the target system and GO!
5) Introduce a new HDD to be the recovery target for the test - thus preserving the perfectly good production HDD.
6) Restore with the VEEAM recovery media.
7) Confirm the process, the steps and the results.

Here are some questions that I can think of:
1) How often might the backup be re-generated from scratch?
2) What if the recovery involves new hardware? Then how does the process change? With what tools?
(There are no VMs)

I'm looking for some dialog here and would appreciate links for good things to read, etc.

Thanks!

fred3

[Egor Yakovlev]

Hi Fred!
1. you don't really need to start fresh backup chain from the scratch, as Veeam has given a lot of effort to maximize backup chain reliability - first of all, with Forever forward incremental chain new restore points replace old ones with your set Retention Policy, that is, oldest parts of a chain are rebuilt with every new incoming backup. Secondly, there are periodic Health Checks and optional Defragmentation.
2. recovery on a different hardware is no different than original, however you must think of hardware drivers in advance - if new machine does not contain new devices that are vital to recovery process(say, new RAID controller?) you can just pass recovery wizard with all default drivers included from original machine. If new hardware is found - Recovery media shall be provided with correct drivers to proceed. You can include optional drivers in advance(like when you know on which new hardware you will do the recovery), during Recovery Media creation wizard.
/Cheers!

[fred3]

Egor,
Thank you!
Re: new hardware: I guess one way is to install VEEAM BRCE onto the new machine and generate Recovery Media from there. But that requires Windows first. Not impossible at all - but inconvenient.
Somewhere in the dim past I had a very nice driver backup program. Still would require Windows though.
Seems a little like a Catch 22.
Is there a way to update the recovery media by adding drivers to it? I guess just recreate it on *any* machine and add the particular (new) drivers would be the most direct way?

Also, is it normal to NOT find the backup files when running the recovery media? I'm updating my version right now so maybe it will behave better.
Anyway, the real question is: if this is still a bit of an issue, is there a workaround/procedure for making it easier?

Also, is it normal for the .vbk file to be larger than the contents of the system it represents? (That's what I had the other day). I guess that may have been a clue...

Thanks again!

[Egor Yakovlev]

For recovery media to work in rescue you need just a base set of drivers (storage, network) - so if your new server has different controller/nic - just download drivers and add them to Recovery Media wizard - you don't have to install Windows on new machine and run Recovery Media creation wizard from it. And yes, easiest way is to run it from any existing machine.
It is abnormal to miss recovery points and surely backup shall be less in size than it's original data due to plain compression used in the job - both cases are worth investigating. Feel free to open cases for each.
/Thanks!

[fred3]

Egor .. Thank you!