I’m looking for a method (preferably GUI) to back up the entire drive Ubuntu is on from within a user session, without unmounting the host drive.
I’d also like the backup to be recoverable from the Ubuntu installer.
(This is a convenience I’ve enjoyed in Windows, and I’d like to have it in Ubuntu if possible)
The main issue with imaging a mounted drive in Linux is data integrity.
Unlike Windows (which uses VSS for hot imaging), Linux generally avoids full disk imaging while the filesystem is active because it can lead to inconsistent snapshots.
Here are the best practical solutions:
1. Timeshift (RSYNC mode)
This is the closest GUI solution to what you want.
It creates system snapshots while you’re logged in and running Ubuntu.
To recover, boot from an Ubuntu Live USB, install Timeshift in the live session, and restore the snapshot.
This works well for system recovery but it’s technically a system snapshot, not a full disk image.
2. Btrfs snapshots
If Ubuntu was installed on Btrfs, you can create atomic snapshots instantly without unmounting anything.
This is the most reliable “hot snapshot” solution because it is filesystem-native and guarantees consistency.
3. Rescuezilla (full system image)
If you want a complete disk/partition image (.img style backup), Rescuezilla is the best GUI tool.
It requires booting from USB (cold backup), but this is the only way to guarantee a 100% consistent clone of the entire drive.
Well, I certainly do value data integrity.
What’s your opinion of using the Gnome Disks utility for making and restoring images?
GNOME Disks is a good and simple GUI tool, but it has an important limitation.
It basically creates a raw disk/partition image (similar to dd with a GUI).
This means it does not use filesystem snapshots like Btrfs or system snapshot logic like Timeshift, and it does not have a mechanism similar to Windows VSS.
So technically:
GNOME Disks can create and restore images
it works well for non-active drives or data partitions
GNOME Disks typically requires the filesystem to be unmounted, so it is safer to use it from a Live USB session for system imaging.
For maximum data integrity, it is still recommended to use GNOME Disks from a Live USB session.
In short:
So GNOME Disks is usable, but not ideal for hot imaging the running system.
Thank you very much for your input.
I’ve used Clonezilla successfully in the past, and Rescuezilla seems to be a GUI for that program.
May I ask what the purpose of said image will be? I’m assuming, since you want to be able to recover it from the installer, that it’s about backing up user data, while also having a complete OS? I think there are better options than simply cloning the disc.
But if you must, you should make sure to remount the filesystem read-only to prevent it from changing while the copy process is ongoing. This shouldn’t be a problem for /usr, if it lives on a separate partition. But if /home is involved, you will get a lot of warnings/errors, because many tools want to save state information on a regular basis. For instance, Bash saves the last command in the history file after it finishes.
It’s also kind of pointless to make a backup of /usr, except /usr/local, maybe. Everything that lives there can be reinstalled. And to help with that one can take a snapshot of the state of all installed packages.
That and a bog standard backup of everything that is irreplaceable, e.g. /home, /etc, some /var, maybe. Should be the cleaner and more efficient approach, to get you back up and running after a reinstallation.
I like to make a weekly image of my PC’s drive, so I can recover from a hardware failure or other data loss event without having to reinstall or configure anything older than that week.
Well, you can do that, but you must make sure that no changes to the filesystem(s) are happening while that cloning process is running. I am skeptical that it works from a live Windows, BTW, because there could be inconsistencies in your clones. Have you every tried to restore one of those clones? Backups are worthless unless they can reliably restored.
I strongly advise to do that offline! Reboot into the Ubuntu installer, for instance. Make sure, no filesystems are mounted, other than your target (and the installer of course) and use something like this:
ddrescue /dev/disk/by-id/<id of whole disc> /mnt/<backup target>/backup."$(date)".{bin,map}
ddrescue might not be installed in the live installer, so you may need to install it, which works if you have internet access:
sudo apt install gddrescue
The benefit of cloning the whole drive, including the partition table, is that you just need to do the reverse on a new drive, which must be at least the same size. Also ddrescue can deal with read errors better. It will try to salvage as much data as possible as fast as possible by skipping problem areas, to come back to later and try them again, once the end of the device is reached.
Do NOT try this on a disk that has mounted partitions, not even read-only mounted ones!!!
I think there are two camps when it comes to backup+recovery:
OR
If you prefer to perform [A], then Clonezilla/Rescuezilla would be the tools that best mesh with your habits/preferences.
On the other hand, that “weekly” image is just what it is intended: old data, not latest data.
Latest data, with minimal data replication, is best achieved using an rsync-based approach.
(I don’t do live, ongoing rsync; I only use nightly, per partition)
To help get your mind wrapped around what is happening, think of rsync as a far more intelligent and complex version of
( cd ${source} ; tar cf - . ) | ( cd ${mirror} ; tar xvpf - )
Using rsync, you have the “least-transfer” approach because it only copies what has been changed. Consequently, creating those backups imply minimal time, on a daily basis, or even multiple times a day, to keep your backup “mirror” up-to-date. I underline that because you seem to emphasize the hardware failure like it happens frequently.
For the rsync approach, recovery from catastrophic failure requires
You can probably write a script to perform the first 2 steps, in all their complexity, from the Live ISO or bootable USB. After that, restoring each data partition is a straightforward rsync task.
Things to remember with rsync:
[FULL] if the target partition is empty, rsync performs a full mirror of the source/master data copy
[PARTIAL] if the target partition has an earlier copy of the mirrored data, regardless of how that was transferred, rsync will only transfer what is deemed new or modified from the previous snapshot, which is where the strengths of rsync shine!
When restoring a lost partition, applying the rsync process in the reverse direction behaves just like the above-mentionned [FULL], to restore that partition in its entirety. If your disk is a single partition, then you have restored the full disk … but … you need … to recreate that layout on that disk before restoring the data.
So, while block imaging (aka Clonezilla, Rescuezilla, dd) is more straightforward and can at first glance simplify the recovery process, it doesn’t give you the flexibility that having “portable data” (i.e. data in a directory tree) offers, potentially as migrating to a subset of a replacement disk, rather than requiring temporary use of a second disk before performing a second copying task to be able to do that.
If you wish to pursue the rsync approach, I will recommend you have a glance at this earlier posting, starting from where the paragraph open with
If you don’t want to get into adapting mine or customizing your own rsync, you can always use the GUI-based Grsync. 