Storage Snapshotting

Basher · 16 Mar 2009 at 15:36

Hi,

I'm currently looking into storage systems, in particular SAN technologies. I've come across snapshotting and I'm not completely sure I understand it.

From what I can gather, the aim of a snapshot is to capture the structure of a file system - so where files currently are and the structure they're in. This ensures that when I conduct a backup I capture all data (i.e. I don't miss data if it's moved from folder-folder during backup)

So a snapshot isn't actually data - just a description of how the data looks on the system.

Sound about right?

Cheers,
J

iaind · 16 Mar 2009 at 15:40

I think the implementations will vary, but if you've worked with VMWare snapshots, I understand it's much the same as this.

It means you can roll back the file system to an earlier point in time, some will actually allow you to access the snapshot data and work with it separately, effectively allowing "branches" of the data

Basher · 16 Mar 2009 at 16:11

iaind said:
I think the implementations will vary, but if you've worked with VMWare snapshots, I understand it's much the same as this.

It means you can roll back the file system to an earlier point in time, some will actually allow you to access the snapshot data and work with it separately, effectively allowing "branches" of the data

But isn't the snapshot data just details on structure?

iaind · 16 Mar 2009 at 16:25

Basher said:
But isn't the snapshot data just details on structure?

I think it's a bit more complicated than that, and probably different depending on the vendor.

This goes into a fair bit of detail about he Microsoft shadow copy service

http://technet.microsoft.com/en-us/library/cc785914.aspx

Vanilla · 16 Mar 2009 at 20:21

Basher said:
Hi,

I'm currently looking into storage systems, in particular SAN technologies. I've come across snapshotting and I'm not completely sure I understand it.

From what I can gather, the aim of a snapshot is to capture the structure of a file system - so where files currently are and the structure they're in. This ensures that when I conduct a backup I capture all data (i.e. I don't miss data if it's moved from folder-folder during backup)

So a snapshot isn't actually data - just a description of how the data looks on the system.

Sound about right?

Cheers,
J

It depends on the Vendor. A snapshot is not used for what you suggest - ensuring when you conduct a backup you capture all the data - that's the job of the backup application and they have their own ways of capturing all the data. The array doesn't care, think of a snap as a freeze-framed version of a volume.

A snapshot is fully mountable volume - it's just that the majority of it (or all of it) is pointing back to the original volume. A snapshot, a pointer based volume. Once you make it you can present it to a server just as another volume. So you can:

* Provide Development teams with a 'copy' of data
* Provide numerous point in time copies so you can roll back to an earlier version of the data (in the event of corruption for example)
* Provide a copy of the data for backup

How snapshots are done depends on the vendor.

Basher · 17 Mar 2009 at 07:36

Vanilla said:
It depends on the Vendor. A snapshot is not used for what you suggest - ensuring when you conduct a backup you capture all the data - that's the job of the backup application and they have their own ways of capturing all the data. The array doesn't care, think of a snap as a freeze-framed version of a volume.

Surely you can use snapshotting to avoid version skew? For example, if a user moves a file from a directory that has not yet been backed up into a directory that has already been backed up, then that file would be completely missing on the backup media.

iaind · 17 Mar 2009 at 07:46

You probably could but I doubt it's widespread. Most backup software can employ snapshotting technologies within the OS to get around this (Backup Exec can use VSS or it's own driver)

Vanilla · 17 Mar 2009 at 13:41

Basher said:
Surely you can use snapshotting to avoid version skew? For example, if a user moves a file from a directory that has not yet been backed up into a directory that has already been backed up, then that file would be completely missing on the backup media.

It's not going too help you.

If a file system is being backed up and someone moves a file as you described it likely wont be backed up that night. I'm not a backup expert but maybe the backup software has a tidy up process to prevent this? Check the file system size if the same as it was when it was backed up?

Anyway - if you backup the snapshot you're backing up a version of a LUN at a point in time. The user can still move the file and you'd still have the same issue.

Feel free to make a snapshot for backup purposes, but not for the event you describe.

It's rare for this to happen, in the grand scheme of things, due to the fact that backups kick off in the evening / middle of the night when most users are not online.

Basher · 26 Mar 2009 at 16:52

Vanilla said:
Anyway - if you backup the snapshot you're backing up a version of a LUN at a point in time. The user can still move the file and you'd still have the same issue.

But the snapshot is instant (is it not) so you wouldn't have the same issue.

Vanilla · 26 Mar 2009 at 17:07

Sorry I ran myself in circles around where the write goes and just went back to RTFM.

You're right, perfect for doing what you want, I misinterpreted what we were discussing.

Sorry if I added confusion

Basher · 26 Mar 2009 at 17:13

Vanilla said:
Why not? What about if the user edits the file while you're backing up the snapshot?

It's just a LUN where most of the 'data' is just pointing back to the original LUN. You would have the same issue of a user editing a file while you backup.

Yup fair enough. So what are the benefits of snapshotting and then backing up off the snapshot? It's what a lot of people seems to advise

Vanilla · 26 Mar 2009 at 17:27

Basher said:
Yup fair enough. So what are the benefits of snapshotting and then backing up off the snapshot? It's what a lot of people seems to advise

Read above, I was wrong! I just got myself confused about where the writes go and was thinking you wanted to catch the change rather than just get a copy of it before.

Basher · 26 Mar 2009 at 17:30

Ahhhh good all makes a bit more sense now so to summarise

- The snapshot take a picture of what the volume looks like and fills itself with pointers back to the original
- When a user goes to update/move/delete a file/folder (on the original volume), just before the operation is executed, the relevant blocks (i.e. those that represent unchanged files/folders) are transfered over to the snapshot so the snapshot remains as a representation of a point in time (before changes) and the active one updates in-line with changes.

Sound about right?

J

Vanilla · 26 Mar 2009 at 17:49

Sounds about right.

If performance is an issue (i.e users on 24/7 around the world) consider making a full volume copy of a source volume, rather than a snap, and then backing it up.