YunoHost's backup tool only backs up useful files and relies on restore scripts to reinstall the dependencies of your applications. In other words, YunoHost's mechanism amounts to reinstalling and then reincorporating the data.
Making full system images can be a complementary or alternative way to backup your machine. The advantage is that your system can be restored to the exact state it was in at the time of the backup.
Depending on your type of installation, you can either create a snapshot or clone the storage medium by removing it from your server (turned off).
A snapshot allows you to freeze an image of the file system. Snapshots are very useful when doing an update or testing, because they allow you to easily go back in case of a glitch. On the other hand, apart from some very high availability clusters, snapshots do not really protect you against hardware failures or disasters (cf. OVH fire in Strasbourg in 2021).
In general, snapshots are quite disk space saving, the principle is that your file system will store the differences that occurred since your snapshot. Thus, only the modifications consume space.
Remember to delete the old snapshots to avoid wasting your storage space by storing all the differences since that date!
You can use this method with most VPS (often paying), virtual machine managers or if you have installed YunoHost with an advanced filesystem like btrfs, ceph or ZFS, you can also create snapshots via the command line
Below, some documentation for the most known suppliers:
Select the virtual machine and click Snapshots
, then specify the snapshot name and click OK
.
To restore, select the virtual machine, click on Snapshots
then Restore Snapshot option
.
Then click on Restore Snapshot
.
Backup
tabBackup now
.Snapshot
modeBelow we consider that /pool/volume
is the volume to snapshot.
Create a read-only snapshot
btrfs subvolume snapshot /pool/volume /pool/volume/$(date +"%Y-%m-%d_%H:%M")
List snapshots
btrfs subvolume show /pool/volume
Restore a snapshot
btrfs sub del /pool/volume
btrfs sub snap /pool/volume/2021-07-22_16:12 /pool/volume
btrfs sub del /pool/volume/2021-07-22_16:12
Delete a snapshot
btrfs subvolume delete /pool/volume/2021-07-22_16:12
Be careful not to delete the original volume
See this tutorial for more info
Below we consider that pool/volume
is the volume to snapshot.
Create a snapshot
rbd snap create pool/volume@$(date +"%Y-%m-%d_%H:%M")
List snapshots
rbd snap ls pool/volume
Restore a snapshot
rbd snap rollback pool/volume@2021-07-22_16:22
Delete a snapshot
rbd snap rm pool/volume@2021-07-22_16:12
Below we consider that pool/volume
is the volume to snapshot.
Create a snapshot
zfs snapshot pool/volume@$(date +"%Y-%m-%d_%H:%M")
List snapshots
zfs list -t snapshot -o name,creation
Restore a snapshot
zfs rollback pool/volume@2021-07-22_16:22
Delete a snapshot
zfs destroy pool/volume@2021-07-22_16:12
You can clone your media (SD card, ssd disk, VPS volume...) to create a disk image. This image before compression will be the exact size of your media, that's why this method applies rather to machines of less than 64GB.
Unless you can read a snapshot, this method requires you to stop the server while you create the image. With a VPS, you have to restart in rescue mode from your provider's interface.
This can be done with USBimager (Note: make sure you download the 'Read-write' version! Not the 'Write-only' version!). The process then consists of the "reverse" of the SD card flashing process:
More details in USBimager documentation
It is possible to achieve the same thing with dd
if you are comfortable with the command line:
dd if=/dev/mmcblk0 | gzip > ./my_snapshot.gz
(replace /dev/mmcblk0
with the real name of your SD card or hard drive)
Found errors? Think you can improve this documentation? Simply click the Edit link at the top of the page, and then the icon on Github to suggest changes.
Powered by Grav + with by Trilby Media. • Terms of Service