Which filesystems offer snapshot functionality for users to recover data?

Question

I'm working on a project that will teach linux to youth. Knowing they will have a tendency to delete or corrupt items in their home directories we are looking for a good snapshot option. We will not have access to fancy tools available from major storage vendors and are hoping to find a solution at the file system level.

I've read a lot about btrfs but have little experience. I have some experience with LVM but I'm unfamiliar with its snapshoting feature. Do either filesystem or another have the option to create snapshots either on demand or scheduled? Then make these snapshot always available without root in like a .snapshot folder in each home folder?

Idealy this solutions allows a user to self-restore backups on demand within say a 24 to 48 hour window. We will have another backup process for the system and more global backups. But we do not want this process to be used by students who just make 'mistakes'.

Solution 1

On Linux, btrfs is your main option for snapshots within a filesystem, but is not yet stable, though it does have some fsck and repair tools.

ZFS is another option, from Solaris. While you could in theory use this under Linux, it's mostly implemented in userland only (though there is some work on a kernel-based implementation) and is not in standard Linux distributions.

This LVM answer has some details on the pro's and con's of using LVM snapshots, and some btrfs/ZFS links. With some filesystems (ext3 and XFS), LVM will take care of freezing the FS before it takes the snapshot, but LVM snapshots can have performance problems and still have some bugs.

I don't think LVM is a great solution for your 'quick snapshot of user data' application, and btrfs/ZFS are not yet suitable [as of 2011].

Instead, you might want to look at rsnapshot, which is a user-space tool that efficiently creates snapshots using any filesystem, without using LVM. Because it uses rsync and stores the snapshots under successive directories, using hard links between different snapshots if a file has not changed, it can run surprisingly quickly even on reasonably large sets of files. It is used a lot for backups but can also be used for this sort of user-data snapshot requirement, and with a little setup can enable anyone to restore their snapshotted files, by using read-only NFS or Samba - see this HOWTO section on restoring files. Files can be restored with standard Linux tools as rsnapshot mirrors the source directory into each snapshot directory.

rsnapshot is quite flexible using its standard features, and since it's written in Perl it's quite easy to customise it, e.g. if you want to provide on-demand snapshots. The main drawbacks compared to filesystem snapshots are speed and disk space - each file that changes results in a new copy in the snapshot, whereas filesystem snapshots only copy new blocks in the file.

Solution 2

Just spotted THIS page on wikipedia, there's a snapshot capabilities column - just wanted people to be aware of this in the future.

Solution 3

As of 2022, btrfs is considered stable for non-RAID setups, and it offers transparent and stable snapshots.

The top answer is from 2011 and mentions that both btrfs and ZFS are considered unstable. 11 years later, that is no longer the case for btrfs or ZFS on Linux.

Solution 4

You should not use LVM snapshots for this purpose because they impose a big performance penalty (especially if you have multiple "rolling" snapshots active at the same time). Unfortunately Linux simply does not have any mature file systems with support for snapshots.

Therefore I recommend to use FreeBSD on your file server. The default UFS2 file system format supports snapshots. FreeBSD also includes proper ZFS implementation (unlike the ugly kludge found in Linux) with snapshots and many other very advanced features. When coupled with a simple tool such as this it is quite similar to what high-end storage vendors such as NetApp offer.

If you have one server dedicated to function as a file server, you might want to look at FreeNAS which packages FreeBSD and ZFS nicely into an appliance-like system.

View more solutions

Comments

[HUB]

LVM creates a block device snapshot. The filesystem (most of modern ones) on the partition is being synced just before thw snapshot is created. To recover some data from the snapshot, you have to mount it. But be aware that any snapshot has size. The space is used to store differences between the snapshot state and current state, that's why storing the snapshot as a backup is not a good idea.

[Gray Race]

@Hub Thank you for the feedback. Perhaps 'backup' is the wrong word. As this will not be a primary form of backup or storage. We recognize that space will be required for diffs or whatever mechnicsm the filesystem/volume manger uses. The goal though is to provide a temporary snapshot so students who make mistakes can quickly revert and retrieve previous information. They will not do best practices of saving their own backups before making changes despite our training and therefore want to help them overcome this.

[HUB]

I don't have experience of this kind but I think you need something like this: en.wikipedia.org/wiki/Versioning_file_system LVM doesn't suit because you will have to mount and copy every file (or keep track of changed files) to restore. LVM has no internal "restore".

[Gray Race]

Thank you very much for the follow-up. I'm going to look closer at rsnapshot on Monday.

[RichVel]

Good point, and clearly UFS2 or ZFS are usable on FreeBSD whereas they aren't (ZFS) on Linux. However, the original question mentions 'teaching Linux to youth', so a separate FreeBSD NAS would be required. Also, I don't know if the FreeBSD snapshot commands linked can be used by non-root users. Since the students would be learning Linux it's best if the snapshots can be created and used by non-root users. rsnapshot makes this reasonably straightforward, and with some setup work each user could have their own snapshot tree owned by themselves.

[snap]

I am assuming that the youth does not have access to the file server, but that it is mounted with NFS or similar to the Linux workstations where they learn Linux. They do not need to know about the architecture of the file server. The linked snapshot utility has the functionality which allows making the snapshots available to users, almost the same as on NetApp. There is no need to run rsnapshot to manually create snapshot imitations when you can use a better OS (for this purpose) which implements snapshots in the file system code. Proper snapshots are atomic.

[Gray Race]

This is a viable option to consider. I'm concerned about the filesystem & network overhead with NFS. As part of 'learning linux' students will be compiling code, running databases, and other I/O intensive processes. They will be doing all of this work in their home directories. If this is networked over NFS I'm concerned about a performance penalty. This is especially concerning in a homebrew system as our production NAS is unavailable for various political reasons. Snapshot functionality is secondary to base performance as we do have a global backup systems but want self-service snapshots.

[RichVel]

Databases over NFS sound a bit hairy, though apparently it can work if the load is not too high and you use a recent DBMS version: serverfault.com/questions/30525/mysql-5-1-34-on-nfs-w-netapp‌​. You would also have to run both FreeBSD and Linux in your lab, which could be good if you have the more able students help (something new to learn) or bad if you do it all yourself and are short of time.

[user122302]

With regards to the statement "ugly kludge found in Linux" I assume this refers to zfs-fuse.net (which indeed sounds like a sub-optimal way of implementing it). Note however that ZFS is also available in a "normal" implementation, zfsonlinux.org (although not directly included in the kernel due to licensing issues).

[pcworld]

rsnapshot does not create atomic snapshots. A big point for block device / file system level snapshots (LVM, ZFS, …) is that they are atomic, i.e. represent the data in a consistent state at a specific point in time.