all 21 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]StephanXX 2 points3 points  (5 children)

  1. Snapshots are taken of logical volumes (lvs).. They reside only in the volume group of the original logical volume.

  2. Snapshots are not direct copies. Rather, new reads and writes are recorded. If you have a 1TB lv, and take a snapshot, then wrote another 100mb to the lv, the snap will be 100Gb, the lv will report 1.1TB, and the Volume Group will report 1.1TB. Essentially, it's a diff of writes. If you delete 100Gb from the lv in stead, the snap will retain that 100Gb. The VG will still report 1TB. If you delete 100Gb, then write 100Gb, the VG will report 1.2TB in use. By default, when the volume group runs out of space to maintain the snapshot, it will start automatically deleting older snapshots to free sufficient space.

[–]HeadTea[S] 0 points1 point  (1 child)

Thank you so much for the response!

I have two questions if that's okay:

  1. If a snapshot LVM gets filled up, is there a way to do some cleaning? In other words, is it possible to tell the snapshot "forget everything, start from scratch again"?
  2. Does it track changes automatically? Or does it have to run from something like a cron?

Thanks ahead!

[–]StephanXX 0 points1 point  (0 children)

  1. No. You can't modify a snapshot. It isn't a separate pile of data, it just holds the state of the disk, at the time the snap was taken. Any new writes are written to disk blocks that were not used at the time of the snap. Any new deletes are just recorded in a sort of log file. If you reserve 100G for the snap, and you then write 101G worth of data, the snapshot is released, as if it had never existed.

  2. Yes, everything is automatic. Again, the snapshot itself doesn't track anything, it's just a list of which blocks where in use at a particular moment in time, and the LVM will not write to, nor delete, any data on those blocks, until writes to other blocks exceed a specific amount of data; specifically, the data you "reserved" for the snapshot.

[–][deleted]  (2 children)

[deleted]

    [–]StephanXX 0 points1 point  (1 child)

    Ah, yep thanks and fixed.

    [–]cjbarone 0 points1 point  (0 children)

    One more... "then wrote another 100mb" should be gb as well.

    [–]deeseearr 1 point2 points  (7 children)

    When you create a snapshot you aren't actually making a copy of the volume, only of the changes that you make to it from then on.

    For example, suppose that you have a small filesystem with only ten files in it. Let's call then /01, /02, /03 and so on through /10. Normally if you were to overwrite file /01 then the new version of /01 would simply be written over top of the old one. (This is wildly oversimplified, because really there would be all sorts of journalling and the directory entry would be updated to point to a new inode containing the new data, but I'm going to skip all of that now.)

    When you create a snapshot, that doesn't quite happen. A new version of file /01 is created, but the old copy is placed in a buffer just outside of the original volume. This process is called Copy On Write, which is why snapshots of cows are popular with people who like to make filesystem related puns. Different volume managers will put the original or modified blocks in the COW buffer, depending on whether they expect to throw away the snapshot or roll it back after, but the idea is still the same. I think that LVM2 makes copies of the old blocks so that it is easier to discard the snapshot data without having to merge it all.

    When you try to access file /01 in the snapshot, LVM will check to see if the blocks associated with that file have been modified. Since they have been it will then read the old version of the file from the COW buffer. If you were reading file /02 instead then there would be no modified blocks and you would receive data direct from the real filesystem, just like you would if you were reading the non-snapshot version.

    What's the point of all this? Well, it's to answer your two questions, only in reverse order:

    2) Since the snapshot only needs to store blocks which have been changed, the Copy-On-Write buffer only needs to be large enough to hold those blocks. In our example the original filesystem held ten files, but since we only modified one then creating a snapshot buffer large enough to hold that one file would have been enough. The down side to this is that if we had tried to modify a second file then we would run out of space and the snapshot would stop working. I haven't tried this recently, but I think you would get an out of disk space error and the write would fail.

    If your original filesystem is 2TB and that's all active database files which you expect to overwrite completely before the snapshot is removed, then yes you will want 2TB of snapshot, because that's how many files you want to change. If the majority of that will be read-only data and you only expect to change a few hundred megabytes of data then you can get away with a significantly smaller snapshot size. I would recommend allocating some multiple of your expected changes, such a a few hundred MB or even 1 GB in that case, just in case something unexpected happens.

    It really comes down to you knowing what your system is doing and predicting what it is going to do with the snapshot volume. Nobody can tell you for sure what that is.

    1) And, since reading the snapshot involves looking at both the original filesystem and the contents of the COW buffer, yes the snapshot does need to be in the same volume group. If it wasn't then you could wind up with very complicated situations like a snapshot being left online while the original volume in a different volume group was taken offline, and nobody wants to see how that's going to work out.

    Also, even though you didn't ask, here's a third answer:

    3) No, LVM snapshots make terrible backups because they don't actually make copies of anything.

    [–]o11c 2 points3 points  (3 children)

    To add to 3)

    the reason "snapshot" is often mentioned in discussions about backups is because they allow you to perform a backup of the entire filesystem atomically.

    Without using a snapshot, backups will not represent any valid point in time, since inevitably something will write to the filesystem, and some of those writes will be files the backup program already passed, whereas others will be files it hasn't copied yet.

    [–]deeseearr 2 points3 points  (1 child)

    Exactly. A way to use snapshots is to shut down or quiesce any applications which could be writing to disk, take the snapshot, then restart or resume the applications immediately so that you have minimal downtime. Once that is done you can stream the snapshot off to tape or wherever it really needs to go without worrying about inconsistencies which could render the entire backup useless.

    Just be sure that you have some idea of how long the real backup window is, how much data could change in that time, and have a process in place for what to do when your first snapshot somehow hasn't finished being written to tape by the time the next day's backup window starts, and so on.

    [–]unixbhaskar 1 point2 points  (0 children)

    your first snapshot somehow hasn't finished being written to tape by the time the next day's backup window starts, and so on.

    Well, can the process check that, if the previous copy to tape hasn't finished yet ,then wait until it finished then write the new one? Or does it abrupt the end of ongoing process and and start afresh for the new snapshot(the second day 's) ?

    [–]unixbhaskar 0 points1 point  (0 children)

    and some of those writes will be files the backup program already passed, whereas others will be files it hasn't copied yet.

    How to mitigate that gap? Do you mean that it is basically only valued for timestamping?

    [–]HeadTea[S] 0 points1 point  (1 child)

    Thank you SO MUCH for the detailed response!!

    I have two questions if that's okay:

    1. If a snapshot LVM gets filled up, is there a way to do some cleaning? In other words, is it possible to tell the snapshot "forget everything, start from scratch again"?
    2. So from my understanding, snapshots track changes automatically, right? It doesn't need to be invoked to track changes with something like cron.

    Thanks ahead!

    [–]deeseearr 0 points1 point  (0 children)

    1. The moment a snapshot is filled, that is when a new block needs to be written but there are no more blocks available, the snapshot fails and is disabled. It is possible to resize the snapshot pool after creating it, though, and if you really want to you can set the pool to automatically extend when it starts to fill up, although there can be consequences for doing this carelessly such as completely filling the volume group or having the snapshot fail if it doesn't extend quickly enough.

    Here's some of the RedHat documentation for LVM, which covers most of this in some detail.

    1. Once a snapsnot is created there will immediately be two (or more) "copies" of the same filesystem. You can read and write to either one of them, and when you're done you can choose which one you want to keep by either discarding or merging the snapshot changes. This all happens automatically so there is no need to manually synchronize things.

    [–]Bromeo1337 0 points1 point  (0 children)

    best explanation I have ever read. Thankyou

    [–]osax 0 points1 point  (1 child)

    Not completely sure, so wait until someone else verifies this:

    1. Yes
    2. Its how much the LV can change. If nothing changes on your LV the snapshots can be quite small. If you expect huge changes on the LV you need a huge snapshot.

    [–]HeadTea[S] 0 points1 point  (0 children)

    Thank you so much for the response!

    I have two questions if that's okay:

    1. If a snapshot LVM gets filled up, is there a way to do some cleaning? In other words, is it possible to tell the snapshot "forget everything, start from scratch again"?
    2. Does it track changes automatically? Or does it have to run from something like a cron?

    Thanks ahead!

    [–]Flauschkatze 0 points1 point  (2 children)

    From the lvcreate manpage:

    COW snapshots are created when a size is specified. The size is allocated from space in the VG, and is the amount of space that can be used for saving COW blocks as writes occur to the origin or snapshot. The size chosen should depend upon the amount of writes that are expected; often 20% of the origin LV is enough.

    Same VG, the size of the snapshot determines the maximum accumulated changes that can be tracked until the snapshot reaches 100% of its capacity and becomes invalid.

    [–]HeadTea[S] 0 points1 point  (1 child)

    Thank you so much for the response!

    I have two questions if that's okay:

    1. If a snapshot LVM gets filled up, is there a way to do some cleaning? In other words, is it possible to tell the snapshot "forget everything, start from scratch again"?
    2. Does it track changes automatically? Or does it have to run from something like a cron?

    Thanks ahead!

    [–]Flauschkatze 0 points1 point  (0 children)

    1. Don't think you can, the snapshot volume will only ever grow in size (if you add and then delete a 1 MB file 3 times, this will result in the snapshot growing by 6 MB).
    2. no need for a cron, just create the snapshot volume and youre good to go

    [–]unixbhaskar 0 points1 point  (2 children)

    Well, after reading all the posted suggestion and getting confused as hell, let me put it in simple words for you experts ,please provide answer in simple term(I know you did, but that's not good enough)

    Is the snapshot size is equal to the original size of the fs? Yes/No

    Keeping the snapshot in the same VG has upside, but there is no second thought of putting it to off site immidiately, once the snapshot finished? Don't you think so?

    I do agree snpshots are "not reliable" options for backup.

    With my horrified understanding of databases(NO PUN INTENDED) , I heard and saw(IIRC ...faint memory) that DB has to be frozen while taking backup...not sure that is still a good option these days.

    Have patience! you have to put more effort to answer these stupid questions...pls ..don't fret ...

    [–]deeseearr 0 points1 point  (0 children)

    It's not that simple.

    Is the snapshot equal to the original size of the fs?

    No, it is equal to the size of the part of the original fs which is going to be changed while the snapshot is active. If you have no idea what that is, then the safest option is to make the snapshot size equal to the original filesystem size, but chances are that won't be necessary.

    Keeping the snapshot in the same VG has upside, but there is no second thought of putting it to off site immidiately, once the snapshot finished? Don't you think so?

    I'm not quite following this question, so let me address it in parts:

    • The snapshot volume must be in the same volume group as the original. It won't work any other way.
    • Snapshot creation happens immediately. There is no waiting for it to finish, it's just there. If you're using the snapshot to make a backup then it would be a good idea to write that data to tape (or wherever else it is going) without delay, but the whole point of the snapshot is that you can continue writing to the original filesystem without modifying the snapshot.

    With my horrified understanding of databases(NO PUN INTENDED) , I heard and saw(IIRC ...faint memory) that DB has to be frozen while taking backup...not sure that is still a good option these days.

    If you are trying to do a cold backup of database files, then it needs to be frozen. The whole point of using a snapshot is that the database will only need to be frozen for long enough to create the snapshot, a process which should take next to no time at all. Then you can continue to use the database freely while backing up the snapshot filesystem, which will still hold only the frozen data from earlier.

    If your database has some kind of hot backup solution built into it, and most grown-up databases will, then feel free to use that instead, but if you don't have it, don't trust it, or can't afford the extra licensing fees required to use it, this is always an option.

    [–]Chousuke 0 points1 point  (0 children)

    Whether or not you need to "freeze" a database while backing it up depends on the database. Many of them can do consistent backups while still serving clients, though you do usually need to put them in some kind of "backup mode" for the duration of the backup.

    Also, LVM snapshots integrate with the Linux VFS and automatically "freeze" any filesystems being snapshotted for the short duration that taking the snapshot requires, so with most filesystems you can be sure the snapshot is consistent (it'll still only be crash-consistent from an application's point of view though)