Timeshift & Similar Solutions - Safeguard & Recover Your Linux

G'day all :)

First up is short and sweet, while I am still finalising material that addresses your concerns and statements above. Takes a little time, I am 5,000 years old.

For the sake if this post I installed Timeshift and used it (I don't need a tutorial for that - no offense) only to prove my point.

It appears you do (need a Tutorial), you have the wrong settings checked to take a full snapshot. :oops:

Take this as an exercise in 3 parts, and report back, while I am finishing my submissions.


  • Launch your Timeshift, and go to Settings, then click the Users button
  • Currently, you have a box or two at the left checked, or not at all. Change those to the right, that is (include everything). If there is one for User and one for Root, check both.
  • Look at your Filters tab - this may now show something like /home/rado/** and /root/** and have radio buttons under the + sign filled
  • Under Schedule, check there is nothing scheduled, if there is, unschedule it
  • Close and you will be returned to your large pane, where you have your current snapshot taken


  • Delete the current snapshot
  • Wait 30 to 60 seconds after that has completed
  • Note the number of GB you have available, bottom right corner, write it down
  • Choose Create under the new settings to generate a new, On Demand Snapshot
  • When that process is completed, the Available Space figure will reset, note the new figure
  • Subtract the lower figure from the higher figure and note the results, which will tell you the space the Snapshot has consumed.

  • Close down Timeshift and launch GParted
  • Navigate to the drive and partition/s where you have your Linux Mint 18.3 'Sylvia' Cinnamon running.
  • Note the space consumed and write it down
  • If you have created a separate partition for your Timeshift experiments, navigate to it, note the space consumed and write it down.
  • Exit GParted
Report the results back here.

I may ask your for some screenshots, but the figures you report back may do.



Did it just as you said - step by step.

GParted report of my system. I put some English labels on this image to help you understand what is what bc my interface is in Bulgarian.

Size of snapshot:

There are a few files outside of "localhost" but they're a few megabytes and I don't think they would contribute so much to the total size, which is why I didn't make a screenshot of them.
Which only proves my point you can't have a full system backup while the system is running.
Even if there is some difference between GiB and GB, it's minor and there's still too big difference of nearly 6 GB between the snapshot and the actual size.
there's still too big difference of nearly 6 GB between the snapshot and the actual size.

That is so, but we are making progress, aren't we? We have gone from 2.7 GB to 7.8 GB, nearly 3 times what you thought initially?

We can find the rest, I have every confidence. This is all about how your computer is configured, and how you use the Settings in Timeshift.

You mentioned earlier about the

14.5 GB (which includes nearly 2 GB of mods for American Truck Simulator).

1. Are they captured in the screenshot?

If you are not sure whether they were, you might know whether the mods are saved in eg ~/.config

In that case, you can track it through the Timeshift snapshot storage hierarchy.

Let us know if any probs.

2. Are you using a /Home partition, or a /home folder?

3. I am curious about the /media/root/Drive_E path, I take it Drive_E is a label, but the root?


Which only proves my point you can't have a full system backup while the system is running.

Not at all, sorry :)

See my subsequent Post (might be after one of yours)

Nearly 6 GB is not left out by Timeshift without a reason.

As you will see, if you are patient.


Edit - added BTW

BTW Rado, also tell us whether you are on MBR or UEFI, so I can respond to the Grub issues in time (which Timeshift handles fine)

Last edited:
2. Are you using a /Home partition, or a /home folder?
3. I am curious about the /media/root/Drive_E path, I take it Drive_E is a label, but the root?
BTW Rado, also tell us whether you are on MBR or UEFI, so I can respond to the Grub issues in time (which Timeshift handles fine)
I don't like separate partitions for home, so there's only one partition for the whole system - in root there's /home and there's /boot (grub). No swap either (with 32GB RAM there's no need for that).
/media/root/Drive_E is another storage device (there's also Drive_D). I labeled it Drive_E in order to recognize it easier. There was a reason for these labels and names and it was Windows, whereas now they're just labels for easier recognition. That "root" in the path appeared after I formatted that device with ext4 file system, so that I can save the snapshot (which is one more reason to prefer Clonezilla - it can work with all file systems, NTFS included, not just ext4). Before I formatted it, the path was /media/rado/Drive_E. Gotta say this creation of additional ext4 device created a lot of troubles for me with fstab, so after I posted the screenshots, I had to reformat it back to NTFS and delete that root folder from the path.
My motherboard uses UEFI instead of BIOS, if that answers your question. And while the bootable software I use does support UEFI, I prefer to use the traditional way for installation. As for GRUB - there are absolutely no issues because Mint 18.3 (Ubuntu 16 and/or older) uses legacy grub which allows it to be installed inside / , instead of on the MBR. This also allows more control over GRUB and I for one like to be the one in control over GRUB, not GRUB over me. So, with Mint 18.3 I don't write on MBR at all. But even if there were an MBR problem, I have an easy way to fix it using a Live environment:

sudo apt-get install lilo
sudo lilo -M /dev/sdX mbr

* replace X with the storage device letter
May need to go no further than this.

From Tony George's writings here https://github.com/teejee2008/timeshift

Supported System Configurations
  • Normal - OS installed on non-encrypted partitions

  • LUKS Encrypted - OS installed on LUKS-encrypted partitions

  • LVM2 - OS installed on LVM2 volumes (with or without LUKS)

  • BTRFS - OS installed on BTRFS volumes (with or without LUKS)
    • Only Ubuntu-type layouts with @ and @home subvolumes are supported
    • @ and @home subvolumes may be on same or different BTRFS volumes
    • @ may be on BTRFS volume and /home may be mounted on non-BTRFS partition
    • Other layouts are not supported
  • GRUB2 - Bootloader must be GRUB2. GRUB legacy and other bootloaders are not supported.

  • EFI - EFI systems are supported. Make sure that /boot/efi partition is selected for mounting before restoring snapshots (application will do it automatically).

  • Encrypted Home - For users with encrypted home, files in /home/.ecryptfs/$USER will be backed-up and restored. The decrypted contents in $HOME will be excluded. This avoids the security risk of decrypted contents becoming available outside the user's home directory.

  • Encrypted Private Directory - For users with encrypted Private directory, the encrypted files in $HOME/.Private, as well as the decrypted files in $HOME/Private, will be excluded (as it contains user data). Filters added by user to include files from $HOME/.Private or $HOME/Private will be ignored.

  • Docker & Containers - Docker and containerized systems are not supported. Running Timeshift on such systems will have unpredictable results.

My highlighting in red.

Can you do us a favour and report back on the output of

grub-install --version


As for GRUB - there are absolutely no issues because Mint 18.3 (Ubuntu 16 and/or older) uses legacy grub which allows it to be installed inside / , instead of on the MBR.

That applies to Grub2 as well.


That applies to Grub2 as well.

It doesn't. I've tried to install GRUB2 inside the file system many times (Mint 19, Ubuntu 18, Manjaro, Arch and a few lesser others) and in all of these cases when I try to do that, I either get an error while the installer is trying to install GRUB2 inside the file system, or the system simply doesn't show the GRUB2 menu and the OS wouldn't run.

Here's the output you requested.
grub-install.real (GRUB) 2.02~beta2-36ubuntu3.14+linuxmint1
Rado, you are running Grub2. As the output shows. I believe you are confused between the two Grub versions. Legacy Grub, or Old Grub, as it is now known, was versions of Grub prior to v1.98. With v1.98 onwards, it became Grub2, which nowadays is simply referred to as Grub.

As evidence, if you check your File System in your File Manager (Nemo), you won't find a file /boot/grub/menu.lst (which belonged to old Grub), but you will find a file /boot/grub/grub.cfg, which came in with Grub2.

Running a computer in Legacy mode, however, describes a computer that is UEFI-enabled, and choosing (or being forced) to run it as Legacy.*

Here, Legacy refers to BIOS-MBR, as opposed to UEFI-GPT, which is the more efficient combination. So Legacy, BIOS, and CSM (Compatibility Support Module) are interchangeable here.

I wondered with that on some of your previous references (eg Linux Mint 18.3 having Legacy Grub), and now we know. Ubuntu have had Grub2 since 11.04 'Natty Narwhal', and LTS since 12.04 'Precise Pangolin'. Linux Mint has used it ever since that time.

So rather than argue with me and derailing this Thread, please do a bit of reading, or start a Thread elsewhere and I will be happy to provide input.

So for now, I will get back to working on the basis that your settings in Timeshift need further tweaking which will enable effectively, a 14.5 GB usage to generate a 14.5 GB snapshot, which is what I and other users get whenever we do a full snapshot using Timeshift. My further Posts will show this.


* An example of this is Linux Lite, by Jerry Bezencon, whereby Jerry will not support UEFI, so you have to install it under Legacy mode. However, once installed, it can be run in either mode. With Linux Lite, I do my Timeshift snapshots within Legacy mode, so that I do not confuse the issue and get an accurate snapshot.
This is a holding Post before I exit for my evening, but to assure all Users and potential users of Timeshift how to save all files and folders to restore to full functionality.

Today I installed Linux Mint 19.1 'Tessa' Cinnamon, in order to help a Member with disappearing icons.

I have my Timeshift settings as follows, under Settings - Users (using current version 19.1 of TS)



The size of the new install is shown below. I have not yet run updates, only installed GParted (2MB or so), so close to stock standard.


New Install - /dev/sdb13 - 6.47 GiB

I take the full snapshot with Timeshift.

BEFORE I take the snap, my Timeshift main window looks like this, with 37.9 GB remaining space on my Timeshift dedicated partition



Then I take the snapshot and we see the outcome below



The difference is 37.9 - 31.2 = 6.7 GB.

GParted size revealed was 6.47 GiB - (different measuring standards)

Point being that all of my Distro has been screenshotted, less some incidental files open.

So if Rado has 14.5 GB of space used, he should get 14.5 GB screenshot resulting.

To not have that, something needs tweaking :D

These results carry across all my 37 Distros from 4 Linux Families - Debian-based, RPM, Gentoo and Arch-based. The dedicated partition is 400 GiB. That is an average of about 10 GB/GiB per Distro, quite appropriate as my "home" is storage on a 4 TB external drive.

Cheers, and more later

Last edited:
Getting close to my signoff time for my evening.

Questions have been raised about whether, when you run a Timeshift Restore, Grub, whether it is set up on your drive, or your / (root) partition, will be safeguarded, whether Timeshift will capture in it screenshot all that is needed to restore your system to its previous functionality.

It can, it does, as we will see.

For other purposes, I had converted my 2 TB HDD on the Dell to BIOS-MBR in order to help others using MBR-based Distros, and also for those Distros that do not use UEFI. Its GParted appearance is as follows.

Initially I had a Linux Mint 18.3 'Sylvia' MATE or Cinnamon (32-bit) on here for another Member, who is waiting on a new SSD to resume activity, so I have put on a 64-bit version for now.



For this exercise, and to cover the Users who may be installing Linux "the traditional" way, I have used four (4) partitions -
  • /dev/sda5 is the /boot partition, 1 GiB in size, 118.15 MiB "consumed" (I will come back to this)
  • /dev/sda6 is the "root" / partition, where the main system is housed - 20 GiB, 5.96 GiB consumed. I have only added to the base install - GParted (about 2 MiB from the Repository) and Aptik (also by Timeshift's Tony George, about 5 MiB), I have not performed updates yet.
  • /dev/sda7 is 4 GiB Swap (I do not use swap, this is just for the exercise)
  • /dev/sda8 is Home, not /home, separate to the OS itself, and we are often advised to make this large enough to cater to all our data and growth demands.
Into this melting pot, I have thrown 2 files into Home -



Chakra Linux and KaOS Linux .isos have been added. These might be regarded as being similar to the

...(which includes nearly 2 GB of mods for American Truck Simulator).

...Rado mentioned earlier. They might have a presence in his .config folder, or have their own dedicated eg .ATS folder, he can say.

Now given the version of Timeshift that shipped with 18.3 was likely v17.11, nevertheless for doing the following, I am using



19.01, the latest.

This is likely because I have installed Aptik to save settings on my Mint safeguarded, then blew it away and restored. Updates may have been run. I won't get sidetracked.

So I run my Timeshift once again, with the Settings - Users set to include all.

Before shot on Timeshift



And after a minute or two



94.8 GB left, that is the snapshot has consumed 10.3 GB or thereabouts.

Next step is then for me to "blow away" LM 18.3 and restore it, but that will have to wait for my tomorrow.


So we're back after 2 weeks (regrets :() and a couple of things have changed, as I am helping someone else with the very same Linux Mint 18.3 'Sylvia' Cinnamon.

So screenshot 1 looks like this, as I prepare to blow Sylvia away.



At this point in time, I decided to NOT blow away the Swap on /dev/sda7. Although it is empty/unused, doing so can cause a complication or two on restore, to do with file /etc/fstab, and a small file called "resume" not many know about, but that is a story for elsewhere.

So I took /dev/sda7 off that list, and reformatted /devs 5, 6, and 8.

Sylvia is effectively blown away, including my two files in Home, which might represent Rado's American Truck Simulator files.

My /dev/sda now looks like this


SCREENSHOT 6 - Sylvia Gone

Where my cursor is, is a change. After blowing Sylvia away, and then realising I wanted it back (hypothetically speaking) because it had my blessed American Truck Simulator files in its Home (as represented by Chakra .iso and friend)

...I am preparing to use ever-trusty Timeshift to restore. To that effect, I have used GParted's Manage Flags facility to note that the small, 1GB partition /dev/sda5, is for boot files.

Let's see how GParted goes, in fixing my imaginary dilemma.
Do you know something, I don't know, Brian? ;)

I have faith :p

So we're back after 2 weeks (regrets :() and a couple of things have changed, as I am helping someone else with the very same Linux Mint 18.3 'Sylvia' Cinnamon.

So screenshot 1 looks like this, as I prepare to blow Sylvia away.
Let's see how GParted goes, in fixing my imaginary dilemma.

What a cliffhanger! :)
Will have to tune-in tomorrow to see how it went.
It's like a made for TV drama :D
It's like a made for TV drama :D

Normal service has been resumed, and I am penning this from the restored LInux MInt 18.3 'Sylvia' Cinnamon on the SATA HDD in my Dell rig.

Figures to compare against are Screenshots 1 and 5 in #90, above, and you will see that in the interim 2 weeks I did some work on Sylvia and it increased in size a little, and took a completely new Timeshift snapshot before I blew away and restored.

New GParted looks as below



... And the Timeshift snapshot used to restore looked as follows



If you are a keen observer, you will note that I ran updates including updating the Kernel.

During the Timeshift Restore, I was prompted to choose where to restore -
  • /boot
  • / (the OS partition) and
  • /home
and I answered appropriately.

So, success, it would seem.

But wait, what about those GBs of files in Home, that represent Rado's American Truck Simulator mods? Are they OK?

Well, they are there, but are they any good?

You'll remember I used two (2) .isos, one for Chakra and one for KaOS.

The sha256sum for my version of Chakra is


Found at DistroWatch, near bottom in Torrent Corner - https://distrowatch.com/weekly.php?issue=20171009

The sha256sum for my KaOS is


Again, DistroWatch - https://distrowatch.com/weekly-mobile.php?issue=20180702

...How do these stack up?

If you prefer GUI, you can use GtkHash, as I often do - see my Thread https://www.linux.org/posts/45629/

or just good ol' Terminal

chris@SylviaCinn-HDD ~ $ sha256sum chakra-2017.10-goedel-x86_64.iso
13a877d2640793e885aa2bd44f6393f92973b6ee9bd2657f3da5bc13c378ee09  chakra-2017.10-goedel-x86_64.iso


chris@SylviaCinn-HDD ~ $ sha256sum KaOS-2018.06-x86_64.iso
765448e3af2a962ebd6b834896280d7b3605d04fbfaa33a19612604bfaa35239  KaOS-2018.06-x86_64.iso

So looking good :)

A lot of people who come to Linux from Windows and Mac OS had never heard of checksums before they got here. Even though they are applicable to those OSes, for checking integrity and security of downloads.

What is even less well known is that each and every file, under Linux, and elsewhere, has a unique checksum.

So prior to undertaking an exercise such as I have demonstrated above, if you wanted to be extra cautious, you could generate and record the checksums for, say the 2 GB of simulator "mods" files, store them elsewhere or in the Distro itself, and after a restore, compare them, before incorporating them into your favourite game or app?

Enjoy your Linux, folks, and your Timeshift :D:D


Just a heads up for Clonezilla Users (Yes, the title here does say "...& similar solutions :))

Steven Shiau from University of Taiwan has a new release of his cross-platform solution. v2.6.1-25.

At DistroWatch.com, the following

Steven Shiau has announced a new release of Clonezilla Live. Clonezilla Live is a Debian-based distribution which can be used to create disk and partition images, transfer those images and clone them to a different device. The project's release announcement mentions the following improvements available in Clonezilla Live 2.6.1-25: "Enhancements and changes from 2.6.0-37: The underlying GNU/Linux operating system has been upgraded. This release is based on the Debian Sid repository as of 2019-04-20. From this release the amd64 edition works for UEFI Secure Boot. The Linux kernel has been updated to 4.19.28. Partclone has been updated to 0.3.12+git00e0212. Package ezio-static has been updated to 1.1.8. Package vbetool has been added. Package mbmon has been added. Add USB NIC modules in initramfs of live system. A new mode for Clonezilla lite server has been added - massive deployment from raw device using the BitTorrent mechanism. For Clonezilla 'lite' sever, change ezio_seeder_extra_opt as ezio_seeder_opt. Add two more options - ezio_leecher_opt and ezio_common_opt in drbl-ocs.conf."

Cheers all, and more on Timeshift soon

Enjoy your Linux

One thing you can do for me is to let me know the version of Timeshift you have on Serena.

Hey Wiz ( @wizardfromoz ) ,
Quick question if I may - don't intend to hijack this thread.
Is the version of Timeshift more relevant as regards the functionality of Timeshift in this scenario or more relevant as regards the troubleshooting steps you will take?
I ask because I recently installed Timeshift from the teejee2008 Github page as opposed to the version in the Mint repos because it was 5 or 6 version upgrades newer. Seems to be working but I haven't tried a 'Restore' operation yet :confused:

Members online