21

You can do that with the device mapper and its snapshot target. Basically, you'd do the same as what LVM does when you create a writable snapshot. dev=/dev/read-only-device ovl=/path/to/overlay.file newdevname=newdevice size=$(blockdev --getsz "$dev") loop=$(losetup -f --show -- "$ovl") printf '%s\n' "0 $size snapshot $dev $loop P 8" | dmsetup create "$...


19

The ext4 filesystem has no built-in snapshot feature. The generic way to make snapshots under Linux is at the level of the storage volume. Your filesystem must be on an LVM logical volume, which is Linux's own partition system, as opposed to directly on a platform-native disk partition. To create a snapshot of a logical volume, run lvcreate --snapshot. You ...


16

As someone who is using a btrfs filesystem with Arch Linux for almost 2 years now I can safely say that there does not seem to be a practical limit on the number of snapshots that can be easily reached. There are some caveats though. btrfs filesystem can lead to fragmentation. It is therefore advisable to use the online defragmentation feature built into ...


13

Regarding the nodatacow option, Ohad Rodeh's paper titled BTRFS: The Linux B-tree Filesystem states: It cancels copy-on-write for data blocks, unless there is a snapshot. There is no problem with creating a snapshot of a subvolume mounted with nodatacow. But since cow is required to create a snapshot, when you create one on a subvolume with nodatacow it ...


12

If you store the snapshots in files, as opposed to in the file system (e.g. with zfs receive), I'm afraid, this is not possible. ZFS on the receiving side If you use ZFS on the sending and on the receiving side you can avoid having to transfer the whole snapshot and only transfer the differences of the snapshot compared to the previous one: ssh myserver '...


10

I was able to delete these snapshots by first mounting the whole btrfs volume (not the @ subvolume) and then working from there: # mount /dev/mapper/whatever /mnt -o subvol=/ # ls /mnt @ @apt-snapshot-2013-04-17_21:44:30 ... So at this point, all subvolumes (including the funky apt-snapshot ones) are visible in /mnt, so we can delete them: # btrfs subvol ...


8

You can use the bedup utility to de-duplicate the identical files. Once you've installed it, usage is fairly simple: # bedup dedup /path/to/btrfs You may need to set your snapshots writable (btrfs property set -ts /path/to/snapshot ro false) so it can de-duplicate them. You can change them back afterwards. Note that depending on how many files you have, ...


8

I would keep it simple and clone it. Boot a live system from USB (easiest is Ubuntu from a USB thumb drive, I find), then dump your hard disk to a different partition (or external hard drive etc.), e.g. dd if=/dev/sda1 bs=64M of=/mnt/my_mounted_backup_drive/backup-sda1 where you need to replace /dev/sda1 with your root (/) partition. Do the same with ...


7

That's how hardlinks work. But, there are ways around it: A couple of options come to mind: Use a filesystem with support for copy-on-write files, like btrfs. Of course, were you using btrfs, you'd just use its native snapshots... If your filesystem supports it, you can use cp --reflink=always. Unfortunately, ext4 doesn't support this. Only share hardlinks ...


7

Snapshotting can be seen as a special case of, but distinct from, copying. I'm not really familiar with the specifics of Btrfs, but the following applies to ZFS, from which Btrfs draws much inspiration. Apparently Btrfs snapshots are actually read/write, making them more similar to ZFS file system clones, but that does not change their relationship to file ...


7

There is an error in your libvirt config file: <driver name='qemu' type='raw'/> This line must be: <driver name='qemu' type='qcow2'/> I just tested this conflict. If you create a qcow2 image file (which can be tested with qemu-img info /home/$USER/kvm/domain.name.img) and configure the libvirt domain for raw then I had expected to get an ...


6

Yes, you can snapshot a live system. You don't need to do anything special. With enough effort, you could then sort of boot a system off the snapshot without shutting down (say, using a container or virtualization). Of course, you'd likely have conflicts (e.g., same IP address, host name, etc.). Or you could copy the snapshot elsewhere, and boot it there. ...


5

Yes. Do cp --reflink=auto /src/dir /dest/dir. For all practical purposes it behaves like read & write snapshot of the given directory. (If you use this command across independent btrfs partitions or outside the btrfs it will perform an ordinary copy)


5

The cost of a snapshot cannot possibly be zero bytes. When a block is changed in the source volume, and you have a snapshot, a copy of the original block prior to modification must be made - the original data must be available somehwere so that it's accessible from the snapshot. That's what the snapshot size is (plus some metadata): original copies of ...


5

While technically there is no limit on the number of snapshots, I asked on the BTRFS mailing list: The (practical) answer depends to some extent on how you use btrfs. Btrfs does have scaling issues due to too many snapshots (or actually the reflinks snapshots use, dedup using reflinks can trigger the same scaling issues), and single to low ...


5

A user can not delete readonly snapshots directly, but he can make them writeable first and then delete them. For this you need to use the btrfs property command: btrfs property set -ts /path/to/snapshot ro false If the user is the owner of the snapshot, this should make it writeable and therefore deletable.


5

You can use rsync to backup the entire system. rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /* /path/to/backup/folder There's a awesome article at Arch Linux Wiki about it


5

I will just add to Gilles' answer by saying that although you may use “cp, rsync, etc.” to transfer your read-only subvolumes / snapshots, you may also send and store the subvolumes as btrfs streams using the btrfs send command. The btrfs Wiki mentions the following use: # btrfs subvolume snapshot -r / /my/snapshot-YYYY-MM-DD && sync # btrfs send /...


5

According to this bug report comments snapd is failing if you install core and any snap at the same time. To avoid the error you have to purge and reinstall snapd: # apt purge snapd # apt install snapd Install the core snap: # snap install --edge core Install the snap you want, in this case krita: # snap install krita


5

Actually for the snapshot you use different LV. There is quite reasonable howto: https://www.tecmint.com/take-snapshot-of-logical-volume-and-restore-in-lvm/


4

Have a look at rsnapshot, which is a perl wrapper around the rsync command-line utility. Rsnapshot adds an extra config layer to rsync that makes incremental backups easy. (Older versions of a file are hard linked to the current version when they're unchanged. So each incremental version of your backed-up filesystem looks like a full copy.) Another similar ...


4

Yes rsync has options to preserve ACLs, extended attribute, ext2 attributes, hard links, numerical userids, sparseness... I used to have a system that rsynced filesystems onto a backup server with a btrfs file system (to do snapshots on the backup server), and due to stability issues, moved to zfs-on-linux (which unfortunately doesn't support POSIX ACLs yet,...


4

No, there will be no fragmentation on the original filesystem because of the snapshot. Snapshots basically work this way: you start your snapshot by giving it some disk space to keep track of changes, one block on your original volume gets modified, before the new block is actually written on the original volume, the (old) block content is copied ...


4

What you're looking for is a form of copy-on-write, where multiple files that have the same content use the same space on the disk until one of them is modified. Hard links only implement copy-on-write if the application that does the writing deletes the file and creates a new file by the same name (which is usually done by creating a new file by a different ...


4

Snapshots don't do backups. Think of them as fancy set of copy-on-write hardlinks (that are consequently limited to the same btrfs partition) that you will be able to mount as a seemingly separate filesystem (in future you will be able to use different mount options for each subvolume (=snapshot) ). Only with rsync you actually copy the data. In BTRFS, ...


4

You can have a combined total of 264 snapshots and subvolumes. The btrfs design wiki page says (empahsis mine): Subvolumes are basically a named btree that holds files and directories. They have inodes inside the tree of tree roots and can have non-root owners and groups. Subvolumes can be given a quota of blocks, and once this quota is reached no new ...


4

The general idea is to go to the snapshot site and enter the source or binary package name in the search fields on the left-hand side. For tomcat6 this will lead to http://snapshot.debian.org/package/tomcat6/ which lists the available snapshots of the tomcat6 source package. You'll find version 6.0.16-1 on http://snapshot.debian.org/package/tomcat6/6.0.16-1/...


4

"normal" LVM snapshots are rather slow for writing - see e.g. https://johnleach.co.uk/words/613/lvm-snapshot-performance. It can drop up to 10%. Making the snapshot ro helps a bit. In yor case thin provisioning should help quite a bit (https://github.com/jthornber/linux-2.6/blob/thin-stable/Documentation/device-mapper/thin-provisioning.txt) - or use btrfs ...


4

The Windows 'Shadow Copy' aka 'Volume Shadow Copy Servce' does filesystem snapshotting. The Linux equivalent requires changing your filesystem/partitions, or possibly using 3rd party tools. Options LVM - you must leave free space on your volume group, and has a pretty high performance cost. All though not super fast it is available, stable, and pretty ...


4

Yes, you can. # mark snapshot to destroy after 1 hour (3600 seconds) zfs set :destroy-after=3600 tank@mysnap # result of get operation will be just the value 3600 zfs get -Hpo value :destroy-after tank@mysnap


Only top voted, non community-wiki answers of a minimum length are eligible