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

61–70 of 180 posts

Re: Timeshift: System Restore Tool for Linux

#61

Post by Izkata »

umvi wrote: post #23

> Creates filesystem snapshots using rsync+hardlinks Sounds like it works similarly to git fork on GitHub? That is, if no files have changed, the snapshot doesn't take up any extra room?

Directories and hardlinks take up space, just very little.

It would make sense to hardlink a directory if everything in that tree was unchanged, but no filesystem will allow hardlinking a directory due to the risk of creating a loop (hardlinking to a parent directory), so directories are always created new and all files in the tree get their own hardlink.

Apple's Time Machine was given an exception in their filesystem to allow it, since they have control over it and can ensure no such loops are created. So it doesn't have that penalty creating hardlinks for every single individual file every time.

Re: Timeshift: System Restore Tool for Linux

#62

Post by tlavoie »

pixelmonkey wrote: post #46
tlavoie wrote: post #44

Earlier quoted context omitted.

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)…

So you did! Sorry, hadn't read the post beforehand. Oh, and I too mourned the loss of CrashPlan. Being in Canada, I didn't have the option offered to have a restore drive sent if needed, but thought it was a brilliant idea. On the other hand, I think Backblaze might!

Re: Timeshift: System Restore Tool for Linux

#64

Post by Springtime »

jenscow wrote: post #40

I use BackInTime, which works in a similar way but is much more configurable. I have hourly backups of all my code for the past day, then a single daily for the past week, etc. Saved my ass a few times.

Sounds like rsnapshot (rsync with hardlinks and scheduling) but the BackInTime repo doesn't mention any comparison of how it's different, though Timeshift says they're similar. Anyone have experience with BiT vs rsnapshot?

Re: Timeshift: System Restore Tool for Linux

#65

Post by _flux »

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…

You can also use lvm2 and then you get atomic snapshots with any file system (I think it needs to support fsfreeze, I guess all of them do).

Re: Timeshift: System Restore Tool for Linux

#66

Post by [deleted] »

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…

[deleted]

Re: Timeshift: System Restore Tool for Linux

#68

Post by rrix2 »

pmarreck wrote: post #52
OldMatey wrote: post #31

I adore Timeshift. It has made my time on Linux so much more trouble free. I have used Linux for 10+ years but over the I have spent hours, days and weeks trying to undo or fix little issues I introduce by tinkering around with things. Often I seem to break things at the worst times, right as I am starting to work on some new project or something that is time sensitive. Now, I can just roll back to an earlier stable…

While it's not quite average-user-friendly (YET), one of the reasons I switched to NixOS is because it provides this out-of-the-box. I was frustrated with every other Linux for the reasons you cite, but NixOS I can deal with, since 1) screwing up the integrity of a system install is hard to begin with, 2) if you DO manage to do it, you can reboot into any of N previous system updates (where you set N). Linux is simul…

NixOS also has out of the box support for zfs auto snapshots, where you can tell it to keep 3 months, four weeks, 24 hourly, and frequent snapshots evert fifteen minutes so you can time shift your home directory, too

Re: Timeshift: System Restore Tool for Linux

#70

Post by vladvasiliu »

pixelmonkey wrote: post #49
ratorx wrote: post #48

Earlier quoted context omitted.

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 fo…

I run this from a ZFS snapshot. What I want backed up from my home dir lives on the same volume, so I don't have to launch restic multiple times. I have dedicated volumes for what I specifically want excluded from backups and ZFS snapshots (~/tmp, ~/Downloads, ~/.cache, etc).

I've been thinking of somehow triggering restic by zrepl whenever it takes a snapshot, but I haven't figured a way of securely grabbing credentials for it to unlock the repository and to upload to s3 without requiring user intervention.

Post reply on HN