Restore backup SBS2011 AD failes #warning

[Shane Vandewalle]

I've tried this a few times and it's possible to reproduce this every time. Take a snapshot backup from a SBS2011 (or other 2008R2 with AD) VM and restore it. When the machine boots, Active Directory is able to detect it's been restored and sets a FLAG (

define DSA_WRITABLE_USNROLLBCK 4) ​

in the registry. This renders any DC inactive. The only way to fix this, is to demote the server, remove, clean metadata and reinstall AD OR restore systemstate via the windows backup application / possible other backup apps).

In my case, I couldn't demote the server cause the SBS2011 has to be the main DC and it's possibly not supported anyway. Lucky I take a full system backup via the windows backup app and have been able to restore my VM.

So if you run a DC a VM and need to restore a snapshot/backup made by proxmox, it's probably going to be broken.

Also see: http://support.microsoft.com/kb/2023007 (registery flag) and http://support.microsoft.com/kb/875495 (detect and recovery USN rollback)

 

[snowman66]

AFAIK you need to lock the AD database before making any LVM snapshots.

 

[Shane Vandewalle]

AFAIK you need to lock the AD database before making any LVM snapshots.

Is this noted anywhere in the proxmox documentation? Since the snapshot runs via cronjob, this would require that I also run a script in the vm it self automatically, just before the snapshot starts and also unlocks it when done.

 

[Shane Vandewalle]

No one?

 

[tom]

Read the MS documentation regarding ADS backups. A disk-image backup or snapshot backup is not a suitable method, you need a ADS aware backup tool, working with an agent inside windows.

 

[Kaya]

Is this noted anywhere in the proxmox documentation? Since the snapshot runs via cronjob, this would require that I also run a script in the vm it self automatically, just before the snapshot starts and also unlocks it when done.

This is not documented like an "AD database problem" cause it's related to snapshot concept.
This may occur for every type of subsystem, like database (thinks about to take an instant copy of a database in the middle of a big transaction, in most case you can have an inconsistent one).
I think it's better to get backup job inside VM (or use tools like bacula) and still take snapshot (and maybe copy it on another storage system)

 

[dietmar]

This is not documented like an "AD database problem" cause it's related to snapshot concept.

This is a well known AD problem, so there is no need to document that.

This may occur for every type of subsystem, like database (thinks about to take an instant copy of a database in the middle of a big transaction, in most case you can have an inconsistent one).

Any system with transaction properly implemented should be able to recover cleanly (that is the purpose of transactions).

 

[Kaya]

Any system with transaction properly implemented should be able to recover cleanly (that is the purpose of transactions).

I'm not sure if it work with snapshot. For Database maybe, but think about a big file copy with a snapshot in the middle: at 99% that file will be corrupted.

 

[dietmar]

I'm not sure if it work with snapshot. For Database maybe, but think about a big file copy with a snapshot in the middle: at 99% that file will be corrupted.

No, the file will have the contents from the time you took the snapshot. I would not call that corrupted. How do you think other backup tools handle that situation? IMHO, an application which writes files continuously without any transaction mechanism is broken. That is why even a simple file copy first writes to a temporary file, and the does an atomic file rename.

 

[Kaya]

No, the file will have the contents from the time you took the snapshot. I would not call that corrupted. How do you think other backup tools handle that situation? IMHO, an application which writes files continuously without any transaction mechanism is broken. That is why even a simple file copy first writes to a temporary file, and the does an atomic file rename.

I guess that other backup tool work in filesystem host level, e.g. Microsoft Volume Shadow Copy system with ntbackup.
Host filesystem doesn't know nothing about upper file system status and structure.
BTW I'm curious about that and as soon as I can I will do a test on our w2k3 just "for fun"...

 

[snowman66]

http://blogs.technet.com/b/sbs/arch...server-2008-running-as-a-virtual-machine.aspx

 

[dietmar]

I guess that other backup tool work in filesystem host level, e.g. Microsoft Volume Shadow Copy system with ntbackup.

That simply does not help if the application has an open file handle and writes to that file.