Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 856
  • Last Modified:

Xenserver 5.5 snapshot deletion

Hi

I ran a scripted backup from a Xenserver 5.5 with 3 VMs which creates a snapshot and then copies an .xva file to a network storage device and then deletes the snapshots.

Due to a permission issue the backups were not stored and the snapshots were not deleted.

I fixed the permissions and ran the script again and this time it snapshotted and created the backup .xvas on the network storage.

However, it has left the original snapshots in place.

My question is:

Can I manually delete these snapshots without causing my running VMs any data loss problems?

Brian
0
3D2K
Asked:
3D2K
  • 2
  • 2
1 Solution
 
ToxicPigCommented:
Yes, you may delete snaps at any time.  The SR will simply roll up the changes into the main VBD and keep chugging along.  Note that 5.5 did have a bug and was not the best about freeing up snapshot space.  Doesn't affect your data, just makes you scratch your head in trying to figure out why you don't have all the free space you think you should.
0
 
3D2KAuthor Commented:
ToxicPig

That's my point. The snapshot in question was created before another snapshot was done by the backup script (Andy Burton) that was subsequently deleted by the script.

What I'm concerned about is that any roll up from the snapshot I want to delete may compromise the later snapshot and the current state of the VM.

I'm aware of the "bug" in 5.5 etc..., but Citrix are saying it is by design.  I've seen solutions to reclaim the disk space but haven't tried them yet as it isn't causing me a problem....yet!

Thanks

Brian
0
 
ToxicPigCommented:
Snaps roll up in sequence.  If you remove one from the sequence, those changes just roll into the next snap.  It's honestly Storage Voodoo that takes a while to get one's head wrapped around, but the same methodology has worked for vendors like Netapp for years.  Doing this a bit more visually:

Original Disk (locked read only) -> Snap 1 (locked read only) -> Snap 2 (unlocked read write)

and so forth.  Only that last snap is in a writeable state, as writing to anything previous would compromise the state of the data.  As you say, you have deleted Snap 1.  That's fine.  Any diffs have been rolled into Snap 2 to maintain both the integrity of the running VM and of the locked Original Disk.  Should you delete Snap 2, changes would be rolled back into the Original Disk as there is no further integrity to maintain from a historical standpoint.  The VM keeps running as if nothing happened.  All of this occurs at the block level within the SR.  Hence the weird loss of disk space, "by design".  Blocks are just remapped within the SR.  Snaps are really nice that way.  I do my own backups in a similar fashion, but also take a manual snap before a major system upgrade.  Very handy for rolling things back if needed.
0
 
3D2KAuthor Commented:
ToxicPig

Great.

Many thanks for taking the time to deliver a full and detailed response.

Brian
0

Featured Post

Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now