What About A File System That Uses Snapshots?

equitir asks: "The file system scene for Linux is now all about journaling. While this is good and necessary, I'd like to ask if anyone is working on snapshot capabilities for any of the file systems available. Is it possible? Should it be done? Is there someone already working on something like this?" (Read More)

"I'm referring to what Network-Appliances are doing: at set times the top-level inodes are replicated but kept pointing to the hierarchy (i.e. the file system gets a new entry point). New inodes and blocks are only allocated and pointed-to for changes. This keeps a large number of entry points within the file system, representing the state of the file system at the times the snapshots where taken. This is used for backups and allows easy retrieval of deleted or overwritten files. This is done by the regular users and from every time a snapshot was taken - this is just like undelete, only better...

This is very useful. With the cost of backups being as high as it is and with restorations from tape being admin level work (and slow at that) - I know from experience that this ability is extremely useful. I have also asked myself why this isn't implemented in any of the file systems available for Linux (in fact, I only know of its existence in Network-Appliances file servers)."

Comments

LVM has snapshots

[Anonymous Coward]

LVM (logical volume manager) has snapshot support. LVM is included in 2.3.47 and later.

http://linux.msede.com/lvm/

-- caudle

This would be *very* cool.

[Colm@TCD]

Although I don't actually know whether anyone's working on this for Linux, I'd just like to chip in and say that it would be an extremely useful feature.

The Snapshot feature on the NetApp filer boxes (which are highly recommended, btw) is described here - for a simple idea, it's extraordinarily useful, and it's saved my hide a couple of times.

Other FSes do this

[LinuxParanoid]

I'm fairly sure that Tru64 UNIX's AdvFS (from Compaq/Digital) provides such snapshotting.

--LP

Fake solution

[Anonymous Coward]

Just played around with this problem.
I think the following "rdist" script works
and can be placed in a cron job:

rdist -f snapshot.rdist

#------------------snapshot.rdist--------------- -
~ -> localhost
install -oremove ~/.snapshot/.current ;
except ~/.snapshot ;
cmdspecial ~ "DATE=`/bin/date +\"\%%Y-%%m-%%d.%%T\"` ; cp -al ~/.snapshot/.current ~/.snapshot/snapshot.$DATE" ;
#----------------------------------------------- --

The first time this is run, it has the overhead of creating a full duplicate of the user's home directory. It then creates a second (visible) copy that is nothing but hard links to the first copy. (Minimal space requirements).
This copy is named with a date-stamp.
On subsequent runs, only changed files will be replaced, but the hard links in the date-stamped directories will preserve the older files in their archives. The only additional space required is the files that have changed plus a whole mess of hard links.
Because of all the stat comparisons, this method isn't suitably efficient for entire systems, as a specialized filesystem would be, and it also preserves entire files, rather than just the blocks that have changed. I suppose something like xdelta could be incorporated to further reduce the space overhead.

Modes and ownership are preserved, so the user must be careful not to modify the files in the snapshot directory.
One nice thing about using rdist is that the destination "backup" directory can be on a different machine, hidden from the user if desired.