Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Timeshift: System Restore Tool for Linux

github.com

Post reply on HN
Print view View original

41–50 of 180 posts

Re: Timeshift: System Restore Tool for Linux

#41

Post by Spunkie »

Arnavion wrote: post #36
LorenDB wrote: post #33

I prefer using openSUSE, which is tightly integrated with snapper[0], making it simple to recover from a botched update. I've only ever had to use it when an update broke my graphics drivers, but when you need it, it's invaluable. Snapper on openSUSE is integrated with both zypper (package manager) and YaST (system configuration tool) [1], so you get automatic snapshots before and after destructive actions. Also, ope…

And it's also integrated into the bootloader (if you use one of the supported ones). The bootloader shows you one boot entry per snapshot so you can boot an old snapshot directly.

This is a feature I've really been missing since switching from grub to systemd-boot.

Has anyone figured out an easy way to get this back with systemd-boot?

Re: Timeshift: System Restore Tool for Linux

#42

Post by magicalhippo »

dmitrygr wrote: post #9

> similar to the System Restore feature in Windows and the Time Machine tool in Mac OS This makes no sense! System Restore is a useless wart that just wastes time making "restore points" at every app/driver install and can rarely (if ever) produce a working system when used to "restore" anything. It does not back up user data at all. Time Machine is a whole-system backup solution that seems to work quite well and doe…

They're talking about the Volume Shadow Copy Service[1], which effectively provides snapshots[2] of the filesystem.

Which files are part of a shadow copy is determined by the one creating a shadow copy, so it could include user data.

You can view and access the files in a shadow copy using ShadowExplorer[3] if you don't have the pro versions.

[1]: https://learn.microsoft.com/en-us/windows-server/storage/fil...

[2]: https://learn.microsoft.com/en-us/windows/win32/vss/the-vss-...

[3]: https://www.shadowexplorer.com/

Re: Timeshift: System Restore Tool for Linux

#43

Post by gchamonlive »

I use a series of scripts to make daily Borg backups to a local repository: https://github.com/gchamon/borg-automated-backups

Currently the local folder is a samba mount so it's off-site.

The only tip I'd have for people using Borg is to verify your backups frequently. It can get corrupted without much warning. Also if you want quick and somewhat easy monitoring of backups being created you can use webmin to watch for the modifications in the backup folder and send an email if there isn't a backup being sent in a while. Similarly, you can regularly scan the Borg repo and send email in case of failures for manual investigation.

This is low tech, at least lower tech than elastic stack or promstack, but it gets the job done.

Re: Timeshift: System Restore Tool for Linux

#44

Post by tlavoie »

pixelmonkey wrote: post #38

I've probably spent way too much time thinking about Linux backup over the years. But thankfully, I found a setup that works really well for me in 2018 or so, used it for the last few years, and I wrote up a detailed blog post about it just a month ago: https://amontalenti.com/2024/06/19/backups-restic-rclone The tools I use on Linux for backup are restic + rclone, storing my restic repo on a speedy USB3 SSD. For off…

One question, why use rclone for the Backblaze B2 part? I use restic as well, configured with autorestic. One command backs up to the local SSD, local NAS, and B2.

Re: Timeshift: System Restore Tool for Linux

#45

Post by atlintots »

alfalfasprout wrote: post #32
choward wrote: post #8

Earlier quoted context omitted.

I can't tell you the number of times I see a project and think to myself "NixOS already solves that problem but better."

The problem, unfortunately, is that Nix often finds itself in a chicken and egg scenario where nixpkgs fails to provide a lot of important packages or has versions that are old(er). But for there to be more investment in adding more packages, etc. you need more people using the ecosystem.

Luckily Nix is also an excellent build system, and does provide escape hatches here and there when you really need them (e.g nix-ld).

Re: Timeshift: System Restore Tool for Linux

#46

Post by pixelmonkey »

tlavoie wrote: post #44
pixelmonkey wrote: post #38

I've probably spent way too much time thinking about Linux backup over the years. But thankfully, I found a setup that works really well for me in 2018 or so, used it for the last few years, and I wrote up a detailed blog post about it just a month ago: https://amontalenti.com/2024/06/19/backups-restic-rclone The tools I use on Linux for backup are restic + rclone, storing my restic repo on a speedy USB3 SSD. For off…

One question, why use rclone for the Backblaze B2 part? I use restic as well, configured with autorestic. One command backs up to the local SSD, local NAS, and B2.

I explain in the post. Here's a copypasta of the relevant paragraph:

"My reasoning for splitting these two processes — restic backup and rclone sync — is that I run the local restic backup procedure more frequently than my offsite rclone sync cloud upload. So I’m OK with them being separate processes, and, what’s more, rclone offers a different set of handy options for either optimizing (or intentionally throttling) the cloud-based uploads to Backblaze B2."

Re: Timeshift: System Restore Tool for Linux

#47

Post by Arnavion »

Spunkie wrote: post #41
Arnavion wrote: post #36

Earlier quoted context omitted.

And it's also integrated into the bootloader (if you use one of the supported ones). The bootloader shows you one boot entry per snapshot so you can boot an old snapshot directly.

This is a feature I've really been missing since switching from grub to systemd-boot. Has anyone figured out an easy way to get this back with systemd-boot?

Some time ago they did add systemd-boot as a supported option and apparently it also generates one entry per snapshot.

https://news.opensuse.org/2024/03/05/systemd-boot-integratio...

https://en.opensuse.org/Systemd-boot#Installation_with_full_...

https://github.com/openSUSE/sdbootutil

I haven't tried it though so I don't know for sure. (I have my own custom systemd-boot setup that predates theirs, and since my setup uses signed UKIs and theirs doesn't, I don't care to switch to theirs. I can still switch snapshots manually with `btrfs subvol` anyway; it just might require a live CD in case the default snapshot doesn't boot.)

Re: Timeshift: System Restore Tool for Linux

#48

Post by ratorx »

pixelmonkey wrote: post #38

I've probably spent way too much time thinking about Linux backup over the years. But thankfully, I found a setup that works really well for me in 2018 or so, used it for the last few years, and I wrote up a detailed blog post about it just a month ago: https://amontalenti.com/2024/06/19/backups-restic-rclone The tools I use on Linux for backup are restic + rclone, storing my restic repo on a speedy USB3 SSD. For off…

One problem with file based backups is that they are not atomic across the filesystem. If you ever back up a database (or really any application that expects atomicity while it’s running), then you might corrupt the database and lose data. This might not seem like a big problem, but can affect e.g. SQLite, which is quite popular as a file format.

Then again, the likelihood that the backup will be inconsistent is fairly low for a desktop, so it’s probably fine.

I think the optimal solution is:

1) file system level atomic snapshot (ZFS, BTRFS etc)

2) Backup the snapshot at a file level (restic, borg etc)

This way you get atomicity as well as a file-based backup which is redundant against filesystem-level corruption.

Re: Timeshift: System Restore Tool for Linux

#49

Post by pixelmonkey »

ratorx wrote: post #48
pixelmonkey wrote: post #38

I've probably spent way too much time thinking about Linux backup over the years. But thankfully, I found a setup that works really well for me in 2018 or so, used it for the last few years, and I wrote up a detailed blog post about it just a month ago: https://amontalenti.com/2024/06/19/backups-restic-rclone The tools I use on Linux for backup are restic + rclone, storing my restic repo on a speedy USB3 SSD. For off…

One problem with file based backups is that they are not atomic across the filesystem. If you ever back up a database (or really any application that expects atomicity while it’s running), then you might corrupt the database and lose data. This might not seem like a big problem, but can affect e.g. SQLite, which is quite popular as a file format. Then again, the likelihood that the backup will be inconsistent is fair…

I agree with you, of course. On macOS, Arq uses APFS snapshots, and on Windows, it uses VSS. It'd be nice to use something similar on Linux with restic.

In my linked post above, I wrote about this:

"You might think btrfs and zfs snapshots would let you create a snapshot of your filesystem and then backup that rather than your current live filesystem state. That’s a good idea, but it’s still an open issue on restic for something like this to be built-in (link). There’s a proposal about how you could script it with ZFS in this nice article (link) on the snapshotting problem for backups."

The post contains the links with further information.

My imperfect personal workaround is to run the restic backup script from a virtual console (TTY) occasionally with my display server / login manager service stopped.

Re: Timeshift: System Restore Tool for Linux

#50

Post by boomboomsubban »

Spunkie wrote: post #41
Arnavion wrote: post #36

Earlier quoted context omitted.

And it's also integrated into the bootloader (if you use one of the supported ones). The bootloader shows you one boot entry per snapshot so you can boot an old snapshot directly.

This is a feature I've really been missing since switching from grub to systemd-boot. Has anyone figured out an easy way to get this back with systemd-boot?

systemd-boot has relatively recently added support for loading filesystems, https://github.com/systemd/systemd/blob/71e5a35a5be99a1f244d... meaning you should be able to set up something similar. I wouldn't describe it as "easy" yet.
Post reply on HN