Re: Experience / Best Practices with long time VM snaps for huge VMFS stores?
My .02 cent
>offering more flexibility to app owners when doing patches and alike.
First thing to do is to define clearly the offering here. And then use the best technology to address the offering.
Here is an idea of the offering. Thinking out loud here so I'm positively missing things
and don't forget that the journey is more important than the destination
1- the offering should allow a point in time (PIT) recovery state
2- the offering should allow rollback to a previous point in time (PIT) recovery state
1- PIT recovery should be easy and quick to enable (manageability)
2- PIT recovery should should have the minimum impact on VM performance
3- In case of consolidation process, it should have the minimum impact on VM performance as well
4- PIT recovery, rollback and eventually consolidate functions should take a minimum of time to process
Let create some abbreviations:
1- TTE = Time To Enable
2- TTR = Time To Rollback
3- TTC = Time To Consolidate
Here is a table to summarise my point
|VMW Snapshot||VMW aware Backup|
|TTE||Snapshot is fast|
Backup takes longer
than a snapshot
Restore takes longer
than roll back of a snapshot
Variable. It depends on
the size of the delta which usually is high since it captured the many changes.
There is no consolidation per se here
and thus TTC=0. Note: snapshots are being used and consolidated during backup process. Though the goal is not the same.
PIT recovery should be
easy and quick to enable
PIT recovery should should have
the minimum impact on VM performance
Snapshot hinders VM performance
as soon it is turned on
Once the backup is done, there
is no impact on the VM performance
In case of consolidation process, it should
have the minimum impact on VM performance
Consolidation of snapshot puts a great
stress on the storage and thus hinders VM performance
|There is no consolidation here|
You can of course add non-functional qualities, such disk space requirement, security and cost to further add granularity to this table.
Feedback are welcome of course