Timeshift (ext4/rsync) - miss(?)-conception, wrong configuration?

Support Software & Applications
1

Wherever I read about Timeshift they’re writing about “snapshots” (except some in this forum).
… and that for backups a separate drive is recommended (obvious).
So I configured Timeshift to put its “snapshots” on the HD in my system, which is just for backing up.
But: It doesn’t act automatically at all (on schedule or on updates) …

Although it saved my ass after some automatic updates (in that I didn’t -again- need days for a new install & configuration from scratch), I meanwhile suspect the conception (and the corresponding configuration) to be wrong.

And if Timeshift’s directory has to reside in the system partition, it might be necessary to change the layout for all disks (to make room for it in the partitions for the /s).

Still in the very basic install of the bare system, the file manager reports the size of 13 Timeshift-“snapshots” (its UI itself calls them “snapshots”) as averaging 10.3 GB, i.e. a total of 134 while “disks” reports a total of 43 and “baobab” just 25. Probably the targets of the hard links are counted multiply in the file manager. But what about the difference between “disks” and “baobab”?

"on demand, only"
"on demand, only"999×473 61.5 KB

active? doubt that
active? doubt that759×633 31.5 KB

current layout
current layout346×774 34.3 KB

… shows also some oddness in disk/partition handling (stricly speaking slightly ot) by the file manager (Nemo):
any idea why most “devices” are called by their part label (as desired) but the 3rd and 4th (on the same “CrucialMemoryExtension1TB”) are not?

2

Hard-links don’t have any targets. They are merely additional filenames for the same file.

Hidden files? :man_shrugging:

Maybe those don’t actually have a PARTLABEL set. PARTLABELS are an optional partition identifier — they are never required by anything.

3

Not sure about Nemo, but in KDE, dolphin shows LABEL, not PARTLABEL.

1 Like
4

And LABELs are optional too. :stuck_out_tongue:

5

You’re absolutely right. And I overlooked the absence of the LABELs because of the homonymic PARTLABELs.
I’m not sure why or how these partitions lost them. (Might be that I failed to reboot immediately after an interfering update, have set them between update and reboot, saw it working, and it didn’t after reboot.)
Actually, I once had indeed seen a loss of such labels for the partitions of my “to become productive”-install and since I used the labels to enhance its fstab’s human readability, the system refused to start. Recovered from the first short shock, it had been easily repaired by booting into another install on the same drive and setting the labels anew. (This time the affected one was the Manjaro-“test & experiment”-install.)

Yes, no thing requires them, I do (for above mentioned human readability).

Anyway - after the solution of my topic’s “slightly ot” appendix’ issue:
Any suggestion how I come to a solid understanding and better configuration of 𝔗imeshift?

6

I’m not sure what you are asking…
Is it the size of the files you question?
You have a bunch of “snapshots” (I agree, the usage of the name “snapshot” with ext4/rsync is confusing). One instance per week is run automatically and save them for 7 weeks (or rather, you keep 7 of those backups).
You seem to have a bunch of snapshots you have done yourself (o).
Not sure what your question is.

Since they are files (and apparently hardlinks) and not btrfs snapshots, I think you can use du to get a more accurate representation of how many files and how much space they occupy.

I have never used timeshift with ext4, only btrfs so do not actually know how they exactly create these “backups”.

7

I did this in the past. After one failure, I found that it was failing to restore the snapshot after parsing (too many files maybe) for 20 minutes or more…

Timeshift states clearly that it isn’t for backups.

Snapshots should exist on your root disk partition - and honestly work much better with BTRFS, but shouldn’t be too bad with RSync.

However, using something like Back-in-Time will create proper incremental rsync backups to your storage disk.

Snapshots are local - with BTRFS they take an instant to create, and a reboot to restore.

1 Like
8

In my configuration (which I suspect wrong) Timeshift doesn’t act on schedule or updates. As my screenshot above shows, I ask it to do one daily and keep 7, but it does manual ones only.
If its backup location has to reside on the system drive instead of the used separate one, size might become an issue into which I don’t want to run. (Rather re-layouting the drive now than after it’s filled with all the to-be-installed applications and their data.)
And in this context the reporting of directory sizes with orders of magnitude differences by various tools becomes confusing. Obviously, the size shown in a directory’s properties by file managers is useless. (While it shows ≳10G for all “snapshots”, baobab shows just a few K for the later ones.) But I don’t understand the differences between baobab and the disks utility.
Have to learn the du-command. Thanks for that hint!

9

? There’s nothing with this name in Manjaro’s repositories or the AUR.

10

Oh, yeah you are correct, I looked to fast.
That is strange.
But again, I have never used timeshift with ext4 AND store on other device. I use btrfs snapshots o the same device to save enormous amounts of space.

Yeah, that is just a df response (I think), can be pretty inaccurate.

Sorry I can not help more. Maybe there are some timeshift logs somewhere you can read and see why it does not run the daily backups.

Edit
Although, if you have made an optional backup (O) one day, I think that counts towards the “daily backup” and it wonät create one more. So try going one day without creating a manual backup and see if the automatic runs.

11

Sorry - backintime

12

Um, no it doesn’t. The only thing the developer states is that it isn’t for backing up your home directories, even though it can do that if you add them. It just doesn’t do that by default, and that’s not its primary purpose either. Its primary purpose is to create a backup of your system.

So does timeshift. On my computer here, timeshift makes rsync copies to a partition on an internal spinning rust drive.

btrfs snapshots are not backups. They are rollback snapshots, so that you can roll back the content of the filesystem to an earlier stage. It’s a bit like version control.

In order to act on updates, you need a special pacman hook, but I have no experience with that.

It does however probably work on schedule, provided that you have cronie running. Most of the Manjaro distribution uses systemd timers, but timeshift requires cronie to be running instead (or alongside of it). You could of course convert the cronie jobs to systemd timers, but that’s going to take quite a bit more work, and then timeshift itself won’t have any control over that anymore.

Just because you don’t get to see the timeshift GUI doesn’t mean that it’s not executing a scheduled job in the background. The GUI is only for convenience, and is not started when timeshift executes a scheduled backup or snapshot.

It doesn’t have to. As the matter of fact, backups should never be stored on the same drive as the original files, because that would be pointless. If anything happens to the drive, you lose your backups.

btrfs snapshots are of course a different thing, although you can also store those on a separate device, if you know how. But then you’ll have to look at the manual, and I’m not sure whether timeshift itself supports storing btrfs snapshots on a separate device.

Either way, btrfs snapshots don’t take up much space, unless you keep a whole lot of them. btrfs is a copy-on-write filesystem, which means that only the modified extents will be copied, and the unmodified ones will be internally linked to.

Likewise, rsync backups also don’t take up as much space as you would think, because unmodified files are simply hard-linked against the initial backup, and only the modified files are copied over.

1 Like
13

Well, I found that I had known (but forgotten) the du-command. And its result are interesting:

du output 4 ts-snapshots
du output 4 ts-snapshots898×549 102 KB

the left side resembles what the file manager shows, the sum on the right is similar to baobab’s output.
Bildschirmfoto vom 2023-11-28 17-25-53
Bildschirmfoto vom 2023-11-28 17-25-53900×534 115 KB

While the fog becomes lighter, it’s not yet absolutely clear.
Minor differences might come from usage of MB/GB by some and MiB/GiB by other apps.

14

Filesystem usage on btrfs is not accurately represented with the normal tools. You need the btrfs-specific tools for that. Read the man page for btrfs and its various tools. :wink:

1 Like
15

If that’s adressed @ me: I use ext4, no btrfs.
I pondered to change that when starting this computer, but found too many posts like “btrfs … broken on update”.

16

Then - using Ext4 - I would suggest using Timeshift to create system ‘snapshots’ as backups on another disk…

It’s a bit sad that you didn’t try BTRFS. For example, deleting 4 unwanted Timeshift snapshots took 1 second (with no grinding noises…).

Creating one takes the same time - the only ‘issue’ is that you have to be more aware at the concept of free space (like the file-system and snapshots) are very different.

When I included my /home directory in Timeshift, using Ext4 and saving snapshots to my HDD, I had a failed restoration - and ended up with a fresh install and manually copying files back. It failed whilst parsing some large number of files, if I remember rightly it was over a million and failed after a half hour of parsing.

The reason I separated the definition of ‘snapshot’ and ‘backup’ is that ‘snapshot’ refers mostly to a System snapshot which allows you to roll back system problems… actually the separation of the two terms is not clearly defined; with BTRFS they definitely work more as the term ‘snapshot’ would suggest, and with ext4 - if you put the ‘snapshot’ system backups on the original system drive, then I’d suggest it’s largely the same thing (but with a lot less ‘snap’).

With BTRFS, this is the entire system and home directory - but the snapshot exists on the physical device being ‘snapshotted’. Failure means you lose all those snapshots - which is why you should also have a ‘backup’ on another device.

Try both

Sure - you can set up your Ext4 system, and set up Timeshift. Create your snapshots on the mounted location, do your backups and set up your system.

Later on, you could just throw in your USB and reinstall (it only takes 5 minutes) but choosing BTRFS and then fire up Timeshift, set to rsync, mount the /backup location and restore.

After restoring your rsync Timeshift, then you can reset Timeshift to work with BTRFS… so your next snapshot wouldn’t be a backup… but the speed would knock you for six.

After that, you’d be aware - no backups off disk, which is where you could set backintime to capture your /home and put that rsynced to the mounted backup location.

17

Then it’s usually not btrfs that’s broken — it’s a pretty robust filesystem, and it’s self-healing — but in many cases, it’s a combination of people installing btrfs on top of LUKS and not knowing what they’re doing or why they’re even doing it. They just happened to have stumbled upon some YouTube video or some post at askubuntu.com or stackoverflow.com, and they’re blindly following what has been said there.

2 Likes
18

You can find good Information about Btrfs in the wiki

and in

:footprints:

Some people manage to break a BTRFS file system. But there is no such thing as an indestructible file system, because fools are clever and every time the developers get used to their latest attempt, they find a new way to destroy it.

1 Like
19

Since my last post here, which feels like a week ago but it’s just 2 days, I got (meanwhile) unexpected news.
According to …

… I tried to get that working (had been installed but obviously not activated with the base sys-install) until too exhausted and apparently with no effect. But - this morning I heard the (almost absolutely silent) HD working for ~ 15 secs without having been activated manually! And: :+1: the first Daily 𝔗-“snapshot” had appeared :clap: !
So the issue which started this topic is solved (and the suspicion dissolved that the corresponding page in 𝔗’s GUI is just decorative).

As for your ardent paroles re. btrfs over ext4:
Once that I’ve got the current system into a productive state¹, I’ll clone that to replace the current ‘reference’ on the notebook and set up a new system based on btrfs.
I’ll look whether I can edit the heading of this topic to reflect its potential for users looking for btrfs info. *
*) Didn’t work (edit seemed ok but saving?) - anyone who wants to point out how that can be done (if it’s possible at all)?

¹) end of '23 or another ½ year to go? The only constant in these estimates is their flipping form ‘few weeks’ to ‘several months’ 2-3 times per week.

1 Like
20

My interpretation of the github page is that it’s a system restore utility.

I’ve never used it but I have seen the interface, it doesn’t seem to allow anything other than system snapshots. Including your data in that is really only useful for testing, so you can have a pristine environment.

Unless I’ve missed something, it’s not what I’d call a backup utility. A backup utility would allow the user to create multiple jobs/backups, ie you could have one for the system, one for /home, etc.