system state backups vs vm backups

[falcone1]

Hi,

There is plenty of how-to documentation on system state backups but what is the point of system state backups if you're running vm backups using the vstorage api.  I know for AD, a system state backup is better than a vm backup, but other than that, doesn't a vm backup make the system state backup unnecessary ( I was going to say redundant).

I'm trying to build a strategy for which to use.  My preference is to do vm backups (not file level) and sparingly use system state backups.  Doing both adds to a backup schedule when increasingly there is less tolerance for a backup window and more of an expectation of off-host backups.

falcone1

[DSTAVERT]

Since a System State backup only takes a few minutes it should be a regular procedure (even hourly) at least on a Domain Controller. An image type backup is not recommended for a Domain Controller.

[falcone1]

That doesn't seem to be the case with 2008.  I see over 10 GB for 2008 servers. A vm backup is now faster when the vmdk you backup is just the OS and you don't choose file-level backup.

[DSTAVERT]

For a domain controller you must do system state backups. Without them you risk loosing AD. As per Microsoft's recommendations at least twice per day.

[Gostev]

DSTAVERT wrote:

For a domain controller you must do system state backups. Without them you risk loosing AD. As per Microsoft's recommendations at least twice per day.

This is not entirely correct statement. As always, "it depends" - depends on your image-level backup solution. With Veeam, you do not have do that - unless you want to have redundancy over backing up the same data twice.

On the other hand, with image-level backup solutions which are not application-aware and do not treat VMs running certain applications in a special manner on backup and restore, you certainly must do that. Otherwise, in case of DC for example, you will end up with USN rollback upon restore, and this will screw up your AD.

Also, just to cover some other points above:

If you try and restore a domain controller from an image based backup (i.e. a non-AD aware backup) in a multi domain controller environment, you'll almost certainly run into replication sync issues after the restore as the AD database was rolled back in an unsupported fashion.

That is correct, unless you are using image-level backup solution such as Veeam, which performs application-aware backups, and - most importantly - application-aware restores.

Also, image based backups will not purge transaction logs for an Exchange server either, so these will continue to grow until an appropriate backup is taken of the information store.

That is also correct statement for many image-level backup solutions. Most of them will not prune Exchange transaction logs at all. Some will prune them immediately at snapshot creation (before backup completes successfully) - which is actually worse, than not pruning them at all - because you end up without good backup and logs are gone too. And only few image-level backup solutions (such as Veeam) will do it correctly, pruning Exchange logs after successful backup only.

I would definitely recommend testing any backup solution extensively in test lab environment with all applications, before making decisions on backup strategy. There are too much marketing these days. Many image-level backup vendors tend to make big deal of unimportant features and product characteristics, while being silent about not having most basic, core features which are expected from any backup solution - such as above - properly handling the applications on backup and recovery.

Hope this helps. Disclaimer, I work for Veeam.

[PaulusG]

Hello,

imho system state backups (in case of Microsoft Windows) and also file level backups are related to physical servers and existed long before VMs. With VMs came a new approach of creating backups. Because of the concept that a VM is actual a few files it is relatively easy to backup a complete server. Allright, there are a few things to consider as a consistent state etc. Present days backup like Veeam Backup and Replication are fully aware of handling VMs, make consistent backups, restore complete VMs or do a file level restore and are even aware of some applications.

Regards,

Paul

P.S. I do not have Veeam shares :-)

[DSTAVERT]

imho system state backups (in case of Microsoft Windows) and also file level backups are related to physical servers and existed long before VMs. With VMs came a new approach of creating backups. Because of the concept that a VM is actual a few files it is relatively easy to backup a complete server. Allright, there are a few things to consider as a consistent state etc. Present days backup like Veeam Backup and Replication are fully aware of handling VMs, make consistent backups, restore complete VMs or do a file level restore and are even aware of some applications.

Active Directory is a different animal and relying on image backups will get you into trouble. http://support.microsoft.com/kb/888794

Do not rely on any image based backup to always do the right thing. 

I have made lots of money recovering AD gone bad. Let me know when you have a problem. :smileywink:

[PaulusG]

Sorry, I missed the AD part. I agree on your comment.

And never rely on 1 domanin controller :-)

Regards,

Paul

[DSTAVERT]

In a small virtual environment I actually think it is far easier to use a single Domain Controller. Almost all issues with AD relate to synchronization and lack of understanding when it comes to AD recovery. With a clean image and system state backup it is almost trivial to recover and no synchronization to worry about.

[Villag3Idiot]

With respect to VM image based backups, you really need to be careful with applications such as Active Directory Domain Controllers and Exchange Servers. If you try and restore a domain controller from an image based backup (i.e. a non-AD aware backup) in a multi domain controller environment, you'll almost certainly run into replication sync issues after the restore as the AD database was rolled back in an unsupported fashion. Also, image based backups will not purge transaction logs for an Exchange server either, so these will continue to grow until an appropriate backup is taken of the information store.

For most other types of servers, image based backups work well but it all depends on the applications running on the server. I would endeavour to take both system state and image based backups as it gives you an extra layer of flexibility