That's the point of the "hot clone" (I'm stealing that). It's an exact image
of the running server including any changes such as you describe current up
to the last transmitted packet. There is no restore.
-----Original Message-----
From: Ben Scott
Sent: Thursday, September 12, 2013 9:38 AM
To: [email protected]
Subject: Re: [NTSysADM] In defense of image-based VM backups
On Wed, Sep 11, 2013 at 10:53 PM, Richard Stovall <[email protected]> wrote:
There was a discussion here a few weeks ago that centered on image-based
backups for entire VMs vs data-based backups of applications only. My
recollection is that most of us smaller guys prefer (or at least lean
toward) the image-based variety, and the bigger, more mature orgs prefer
data backups.
As I understand it, image backups are actually not a problem at all.
It's restores that cause issues.
A program may use things like serial numbers, Update Sequence
Numbers, etc., to track activity internally. Say your SQL database is
at USN 1002, and you take a snapshot of the SQL host. Then you update
a record to have a new phone number, and that change gets assigned USN
1003. Then something bad happens, so you restore, and now we're back
at USN 1002. Someone else submits a delete of a different record, and
now *that* gets USN 1003 again. Meanwhile, some other part of the
system/network that wasn't restored thinks USN 1003 was an update.
Weird behavior ensues.
Long story short, having the ability to (almost) immediately spin up a
brand
new, sandboxed copy of the CRM server allowed me to experiment and figure
out how to resolve the problem without touching the one the devs actually
use.
In a sandbox scenario, the restore issue described above is not an
issue. What you describe here is a tried and true technique. Just
make sure your sandbox is good. :)
-- Ben
