On Wed, 2003-10-08 at 18:07, Markus Oswald wrote: > Am Die, 2003-10-07 um 22.34 schrieb Rich Puhek: > > > Would LVM snapshots work well enough to do the trick? I haven't played > > with LVM, so I don't know how long it takes to perform a snapshot... > > Can LVM do incremental snapshots? You don't want to backup 1TB (for > example) of data when only 100GB have changed since the last backup.
LVM snapshots (or any other sort of "snapshot" storage functionality) are not really backups, so the concept of incremental doesn't really apply. A "snapshot" gives you a image of the filesystem or partition at an instant. Modifications after that instant are applied as normal, but not visible in the snapshot. This works by writing changes to new blocks, and having the snapshot keep a record of the block usage at the time of the snapshot. This means snapshots have a storage overhead, as they need additional space to keep the old block images, and the longer you leave a snapshot the bigger the overhead gets. This kind of functionality can be implemented at the filesystem level. Journaling filesystems in particular have many mechanisms already in place to support this kind of thing. However, LVM does it at the block device level, which means you can use it to snapshot any filesystem. Snapshots mean you can back up a filesystem image as it was at a particular instant. You don't have to worry about changes that happen on a live system between starting the backup, and finally finishing it. Using snapshots to do an incremental backup would be no different to doing any other type of backup using snapshots. It's the same as a normal incremental backup, just with the added guarantee that the filesystem is not changing underneath you as you do it. Note that this guarantee is probably more important for incremental backups, as there might be an increased delay between determining what files to include in the backup, and actually doing it. You are more likely to experience problems with files changing/disappearing after deciding that it does/doesn't need be backed up, and actually backing it up. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]