Home | News | Download | Packages | Forum | Wiki | Github

Void system cloning/snapshot


In Arch (being a pseudo-Archer having used an installation script [Evolution] rather than following the Arch way) I’ve been using these steps to clone my Arch and I’m able to use my clone without seemingly any issue in case my main installation are messed up:

(First have to remove lvm2 package as I don’t use it and it messep up the procedure, then)

sudo mount /dev/sdb1 /mnt/Arch

sudo rsync -aAXPu --info=progress2 --delete-after --exclude="/boot/grub/" --exclude="/boot/initramfs-linux.img" --exclude="/boot/initramfs-linux-fallback.img" --exclude="/etc/fstab" --exclude="/etc/machine-id" --exclude="/dev/" --exclude="/proc/" --exclude="/sys/" --exclude="/tmp/" --exclude="/run/" --exclude="/mnt/" --exclude="/media/" --exclude="/lost+found" --exclude="/home//.thumbnails/" --exclude="/home//.cache/" --exclude="/home//.local/share/Trash/" --exclude="/home//.gvfs/" / /mnt/Arch/

(After the first run of the above (that is, the first cloning/snapshot) I’ve created /etc/fstab for the target and populated it like the source, but replaced the UUID with the target partition’s UUID.)

sudo arch-chroot /mnt/Arch /usr/bin/mkinitcpio -p linux

sudo arch-chroot /mnt/Arch grub-install --target=i386-pc --debug --boot-directory=/boot /dev/sdb

(My Arch installation is BIOS/MBR, but Void is BIOS/GPT, so I guess I only need to remove the boot-directory=/boot part above.)

sudo arch-chroot /mnt/Arch grub-mkconfig -o /boot/grub/grub.cfg

sudo umount /mnt/Arch

How can I adapt this to Void if it’s possible?


Fulll Live Working Clone of Your (MBR-BIOS) Void System

This is to have (even without an internet connection) a live working clone of your existing Void system on another storage (or partition) to be used, for instance, when the currently used storage dies which is certain to happen sooner or later or if you’ve managed to completely mess up your current Void system.

We’ll follow an incremental backup strategy using rsync, that is, after the first backup only the changes will be applied to have a complete clone.

Below are two classes of commands, the commands/instructions (in italics) to be used only at the begining for our first cloning and the commands (in normal style) to be used continuously for every (incremental) cloning. So you may automate your cloning after the first one with a bash alias or function. To make this automation reliable we’ll use persistent names (WWID and UUID) rather than /dev/sdX ect. for target devices and partitions, though bear in mind that any re-partitioning of those targets changes the persistent names as well requiring you to start again from the begining.

sudo mkdir /mnt/VoidClone
sudo lsblk -f

Choose your target partition (say sdb1) from the second command and take note of its UUID.

ls -al /dev/disk/by-id/

Take note of your target device’s (say sdb’s) id, the one not starting with “wwn-…” from the above command.

sudo mount -U <TARGET_PARTITION_UUID> /mnt/VoidClone
sudo rsync -aAXPu --info=progress2 --delete-after --exclude="/boot/grub/*" --exclude="/etc/fstab" --exclude="/dev/*" --exclude="/proc/*" --exclude="/sys/*" --exclude="/tmp/*" --exclude="/run/*" --exclude="/mnt/*" --exclude="/media/*" --exclude="/lost+found" --exclude="/home/*/.thumbnails/" --exclude="/home/*/.cache/" --exclude="/home/*/.local/share/Trash/" --exclude="/home/*/.gvfs/" / /mnt/VoidClone/
sudo mount -t proc proc /mnt/VoidClone/proc/
sudo mount -o bind /sys /mnt/VoidClone/sys/
sudo mount -o bind /dev /mnt/VoidClone/dev/
sudo chroot /mnt/VoidClone grub-install /dev/disk/by-id/<TARGET_DEVICE_ID>
sudo chroot /mnt/VoidClone grub-mkconfig -o /boot/grub/grub.cfg

sudo cp /etc/fstab /mnt/VoidClone/etc/fstab
sudo nano /mnt/VoidClone/etc/fstab

Replace the UUID with the target partition’s UUID obtained above and close the fstab.

sudo umount /mnt/VoidClone/proc
sudo umount /mnt/VoidClone/sys
sudo umount /mnt/VoidClone/dev
sudo umount /mnt/VoidClone

Once you’ve followed the above steps you can automate it afterwards by putting this in your ~/.bashrc.

voidclone() {
    sudo mount -U <TARGET_PARTITION_UUID> /mnt/VoidClone
    sudo rsync -aAXPu --info=progress2 --delete-after --exclude="/boot/grub/*" --exclude="/etc/fstab" --exclude="/dev/*" --exclude="/proc/*" --exclude="/sys/*" --exclude="/tmp/*" --exclude="/run/*" --exclude="/mnt/*" --exclude="/media/*" --exclude="/lost+found" --exclude="/home/*/.thumbnails/" --exclude="/home/*/.cache/" --exclude="/home/*/.local/share/Trash/" --exclude="/home/*/.gvfs/" / /mnt/VoidClone/
    sudo mount -t proc proc /mnt/VoidClone/proc/
    sudo mount -o bind /sys /mnt/VoidClone/sys/
    sudo mount -o bind /dev /mnt/VoidClone/dev/
    sudo chroot /mnt/VoidClone grub-install /dev/disk/by-id/<TARGET_DEVICE_ID>
    sudo chroot /mnt/VoidClone grub-mkconfig -o /boot/grub/grub.cfg
    sudo umount /mnt/VoidClone/proc
    sudo umount /mnt/VoidClone/sys
    sudo umount /mnt/VoidClone/dev
    sudo umount /mnt/VoidClone

Don’t forget to activate it by

source ~/.bashrc

From now on you just need to enter


in terminal whenever you want to backup/clone your stable Void system (say once a week).

How to keep a backup of the whole system?
(Nashat) #3

Hi @fluxboxer. Thank you for the guide. Would the restore need to be done via a LiveCD environment? Or would you need to install Void on the system before running these steps? I’m intending to clone my system on a different computer altogether (same architecture).


In that case first you need to clone it to a usb disk or stick and than clone the usb to your other computer. You don’t need to install Void on it.

(Nashat) #5

Thank you so much @fluxboxer. I really appreciate it.


You’re wellcome. Have just improved the main part a bit, now easier to put in a bash alias or bash function and not outputing “device busy” at the end while unmounting.


Thanks for this guide just what i have been looking for.

Is there anyway to skip large files like over 300 mb or so ?, i use rsync for large files like iso’s or movie files to a portable usb drive to back those up so i keep my system clean of these, but just thinking of making it quicker if i forget to rsync those files. I suppose its catch 22, if i forget then i lose those files if i ever need to restore the backup, but its one i can live with.


You’re welcome.

To make sure I understand you correctly, you have those large files in your main (OS) partition/drive and you’ve already been backing up those files to a USB drive, so you don’t want to copy those again to your system clone, right? Sure, easy.

So let’s say you keep those large files in the LARGE_FILES directory in your home and your user name is laurie.

Just add this to the other excludes in the rsync command above



Backup-specific software, such as ‘dar’ and ‘borg’, have several options to skip certain file types/sizes or even selectively compress them. They have the advantage of being able to do incremental backups. And fuse-mounting borg archives to browse whatever backup you need.

The ‘find’ command can also be used in conjunction with a number of commands to generate file lists that filter based on a number of attributes.

Fortunately, this isn’t really void-specific for 99% of it, so tutorials available for the tools will apply just fine.


a typo perhaps?


Thankyou fluxboxer.


Well, why not?! Sorry.


Im not sure im convinced on backup software such as borg and dar. Maybe im not advanced enough or know enough about it, but when you factor in how simple and effective rsync is with correct commands it seems as if dar and borg are just an extra layer of abstraction.

(rakor) #14

I don’t want to bring the discussion apart… But there are some advantages. You get not just “one” backup, but can also restore an older snapshop (if you find out you have corrupted a file 3 days ago, you can restore the files from 4 days ago). Backups can be (or are always) encrypted. You can have checksums telling you if your backupfiles are still healthy. Using deduplication you can have a lot backups without the need of that much diskspace. It is really easy to handle.

I can recommend “restic” as backup-solution


There. Now you are advanced enough.

(rakor) #16

:laughing: thats great


Not sure about the rest, but this is certainly available with rsync.


The right tool for the right job.

rsync - a fast, versatile, remote (and local) file-copying tool
borg - deduplicating and encrypting backup tool
dar - creates, tests, lists, extracts, compares, merges, isolates dar archives. dar is a full featured backup tool
restic - a backup program that is fast, efficient and secure

I don’t mean to discourage you from using it, but there are arguments supporting each for their unique strong points. Rsync is not a backup tool, for good reason.


rsync seems to cover this as well, no?

-c, --checksum
This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a lqquick checkrq that (by default) checks if each file’s size and time of last modification match between the sender and receiver. This option changes this to compare a 128-bit checksum for each file that has a matching size. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer (and this is prior to any reading that will be done to transfer changed files), so this can slow things down significantly.

The sending side generates its checksums while it is doing the file-system scan that builds the list of the available files. The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as the corresponding sender’s file: files with either a changed size or a changed checksum are selected for transfer.

Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option’s before-the-transfer lqDoes this file need to be updated?rq check.


Unfortunately, that verifies the transfered files at the time of the transfer. Doesn’t have a function to verify your 6 months old backup.

File copy tools get the files from point A to point B. They don’t hold history.

If you insist of having historical copies, you will waste a lot of space.

That’s where incremental and deduplication functions come in.

And you need to have integrity checks, either with a tool like par2, with a raid array, or with their built-in functionalities - sometimes they know bit rot is going to occur and they minimize the risk in the way they store the data.

Rsync will not save you from an accidentaly deleted file that got ‘backed-up’ after deletion. (that doesn’t make sense, does it?).

But if you’ve never had problems with rsync, don’t let anyone tell you otherwise.

Just please, please, please, don’t promote it as a backup tool.