Timeshift in multiboot computer?

I have read lots of articles on Timeshift, including its github site, and I can not find any information on using timeshift in a multiboot computer with more than one linux.

The docs say that timeshift can restore either the running linux or a linux on another partition… but they do not say if timeshift can do a snapshot of anything other than the live linux partition.

Does anyone know?

If not, is there any other snapshot utility that will do what I require?

1 Like

Hi Neville, :wave:

Hmm, that one is a real puzzler. :thinking:
Off the top of my head I cannot say anything specific. Sorry.

I´m guessing you just want to have a snapshot of the root-partitions.
Well, I´m by no means sure of that but wouldn´t it be possible to add the root partition of the 2nd system (provided it is on the same disk) in the settings (“filters”):question:

Of course I may be wrong in my assumption.

There´s always clonezilla, I guess.
But making a disk-backup with clonezilla live would make a backup of everything on the disk which is certainly not what you want to achieve… :thinking:
Besides your productive system would not be running during the backup process…

Sorry I cannot be of much help there. :frowning_face:

Many greetings from Rosika :slightly_smiling_face:


Perhaps you could ask your question here (for further help)

1 Like

Thank you Rosika,
Yes I just want root partitions
I guess I have to try your suggestion.
There are 2 disks. Might need one timeshift install on each disk?

Clonezilla. … It will do partitions or whole disks. That is what I do for proper backup . Snapshots are sort of different, I want that for on the fly safety with rolling release distros… so I can wind it back if something goes wrong in an upgrade… like in your recent case

Thanks, will install and try


1 Like

Hi Neville, :wave:

O.K. I was guessing that…

Well, I´m not sure whether my suggestion would work as the tab “Include/Exclude Patterns” seems to indicate “patterns”.
But at the bottom of the window there are switches for adding files and/or folders.
I guess trial-and-error is the only way to go.
Sorry. :slightly_frowning_face:

Yes, you´re right of course.

Hmm :thinking:
just a thought:

As timeshift makes use of rsync: why not leave the timeshift settings as they are right now (i.e. for one OS) …
… and for the other OS : use a dedicated rsync-command which takes care of the root partition of that one.
One could certainly define a cronjob for it. :thinking:

Well, as I said, just a thought…

Many greetings from Rosika :slightly_smiling_face:

1 Like

Yes it uses rsync, but I think it does more than that. It has the ability to wind back to a previous rsync. I dont think I could do that just using rsync command?

Let me do a trial with timeshift. We shall soon find out.


Hi Neville, :wave:

Yes, you´re right. I was just focusing on the backup process itself. Sorry :blush:.

I´ll keep my fingers crossed for your trial. :smiley:

Many greetings.
Rosika :slightly_smiling_face:

No no. Actually you made me think.
One could probably do a primitive timeshift emulation by hand with rsync. Just need to keep track of sync dates… for every file. Fair bit of bookkeeping.

1 Like

Hi Neville :wave:

You´re too kind. Thanks so much. :heart:

Actually there seem to be restore capabilities provided by (or used together with) rsync.

I haven´t read them through though…

Many greetings
Rosika :slightly_smiling_face:

1 Like

Data is safest when offline

At the risk of stating the obvious, when a particular Linux installation is not booted, nothing is changing on it. There is no activity to snapshot. Oh, sure, maybe the last few changes before you booted into a different install, but that’s all.

No matter how much time passes until the next time you boot up that install, the amount of data to snapshot isn’t getting any larger or any more vulnerable. A non-booted partition is its own best protection, if we accept that the primary vulnerability for most system files is activity on the system that causes them to be compromised. (Disk failures do happen, sure, but honestly if you’re snapshotting your system data as insurance against a catastrophic storage hardware failure then you are really playing a long game.)

To snapshot a non-booted partition, though, at the very least Timeshift would have to mount that partition, thus exposing it to possible data loss. That seems like a really bad tradeoff, even if it were otherwise advisable. (However, even ignoring that fact, it’s actually not advisable, so ultimately the point’s moot.)

Non-primary non-booted OS filesystems

Including the OS partition from installs other than the booted one into a Timeshift snapshot would be a terrifically bad idea. As I said, you’d have to mount those filesystems into the current install. (Timeshift — and rsync itself — are online-only data archival solutions, they operate only at the filesystem level, and cannot work with raw blocks or read from unmounted partitions.) And when a system partition from given Linux install is mounted into a foreign one, several very significant things are missing.

  • The user and group database; the UIDs on the foreign filesystem will not match up with the ones on the live system, meaning your files will all be owned by the wrong system users.
  • The SELinux contexts, if you’re using a distro that enables SELinux. All those tables of default contexts, role mappings, process domains, and customizations that apply to the filesystem in question are locked away in it /etc/selinux/ directory, and are probably completely different from what’s stored in the /etc/selinux/ of the current OS. Your contexts will be a mess if you snapshot anything in that state.
  • All of the symlinks on the foreign OS partition that point to places like /usr/lib, /usr/share/, /var/db/, etc. are going to point to your files and directories from the primary booted OS, instead. Unless Timeshift is very meticulous about never following symlinks, and only snapshotting the state of the link itself, never the target… well, that’s actually really hard to get right, so I can guarantee it’s not perfectly careful about that.

To be honest, reading over the past two years of open Issues in the Timeshift repo would give me pause in general about using it. And that’s not meant to knock the developer or insult the obvious hard work and dedication they’ve put into the project — honestly! But this is a hard problem to solve, with questionable real-world benefits even if it works perfectly, but PLENTY of chances to cause a lot of problems should anything go wrong. Backup is one of those things… if you can’t be 150% confident it won’t let you down right when you need it, then there’s just no point in bothering really.

What does Linux need with a System Restore?

Timeshift wears its motivations on its sleeve, and honestly that’s kind of where it loses me right up front:

Timeshift for Linux is an application that provides functionality similar to the System Restore feature in Windows and the Time Machine tool in Mac OS. Timeshift protects your system by taking incremental snapshots of the file system at regular intervals. These snapshots can be restored at a later date to undo all changes to the system.

Um… OK. And I’d want that why?

I’ve always felt that one of the biggest benefits of running a Linux system is that the system isn’t a precious snowflake, fragile and in need of protection.

Linux systems aren’t loaded with complex applications that took hours to install and get working, with tons of irreplaceable metadata squirreled away in the murky abyss in which dwell the Files of Program. The system partition is overwhelmingly laden with files managed by the distro’s package-management system, all freely downloadable and readily replaced at at any time. I’ve never had one of those Windows hell moments on Linux — those, “OMFG, I just spent three hours trying to install this massive application that wanted to take over my entire system, and now it won’t even boot!” horror-shows. Doesn’t. Happen! But even if it did, so what? I can reconstruct any of my Linux machines’ system partitions just by doing a fresh install, then sudo dnf install <all_the_same_packages_as_before> right from the distro. Heck, I have done it, and it’s the work of like an afternoon. Probably quicker than dealing with Timeshift’s apparently-nebulous and somewhat fraught restore process.

Mind you, I do cheat a bit. All of my systems rely on the very excellent etckeeper, which stores all changes to their /etc/ directories in a Git repo. So I always have a complete history of all configs, and can trace the complete lifetime of every configuration change backwards and forwards through its entire history.

Armed with a clone of that repo and access to the net, the rest of the files on any of my system partitions are basically disposable.


Thank you @FeRDNYC
That is a really valuable assessment of the situation.
I think for most purposes, I would be happy with the protection Clonezilla provides.

The case that is of some concern to me is where I have a new linux install that is being developed rapidly. It is easy to make a mistake when working on an OS, so I need frequent backups . Timeshift seemed attractive for that. So I was asking if I could just have one timeshift install in one of my Linux partitions, and use it to snapshot other partitions. You answer is no, that is a bad idea. Timeshift is meant to be used on a live filesystem.

So what I do currently seems best. If a particular partition with linux on it is very active, just do lots of clonezilla single partition backups.
I dont want to go to the trouble of having to install a Timeshift in every Linux install, just in case I want a snapshot.
I could use rsync directly, I suppose. I have actually tried that… rsync can copy a live linux filesystem… you just exclude some directories like /sys , /proc, …ie the ones that are populated at boot time.

In general you are right. Linux is so stable and simple to install that OS backups are rarely needed… Only when one is doing major upgrades. User data protection is much more important because it cant be put back if lost… unless you have backups.

So thank you @FeRDNYC for that well thought out reply. You have helped to get my thinking straight, and I am sure others will find your work valuable reading