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

81–90 of 180 posts

Re: Timeshift: System Restore Tool for Linux

#81

Post by mdavidn »

lmz wrote: post #77
hashworks wrote: post #76

Earlier quoted context omitted.

While I do that, is that really the case? I can imagine database snapshots are consistent most of the time, but it can't be guaranteed, right? In the end it's like a server crash, the database suddenly stops.

Your DB is supposed to guarantee consistency even in server crashes. (The Consistency, Durability part of ACID).

That consistency is built on assumptions about the filesystem that may not hold true of a copy made concurrently by a backup tool.

e.g. The database might append to write-ahead logs in a different order than the order in which the backup tool reads them.

Re: Timeshift: System Restore Tool for Linux

#82

Post by sulandor »

croniev wrote: post #79

Timeshift does not work for me because I encrypted my ssd, decrypt on boot, but linux sees every file twice, once encrypted and once decrypted, thinking that my storage is full, and thus timeshift refuses to make backups due to no storage. At least thats as far as I'm understanding it atm

> linux sees every file twice, once encrypted and once decrypted

fixing this should prove profitable

Re: Timeshift: System Restore Tool for Linux

#83

Post by exe34 »

nijave wrote: post #18
exe34 wrote: post #7

oh this brings back memories, i found a script that did this about 15 years ago. it kept three versions of backups using rsync and hard-links to avoid duplication.

https://rsnapshot.org/ ?

> rsnapshot was originally based on an article called Easy Automated Snapshot-Style Backups with Linux and Rsync, by Mike Rubel.

must have been this one :-D thanks for finding it!

Re: Timeshift: System Restore Tool for Linux

#84

Post by dsissitka »

bongobingo1 wrote: post #73
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…

Do you have much of an opinion on why you went with Restic over Borg? The single Go binary is an obvious one, perhaps that alone is enough. I remember some people having un-bound memory usage with Restic but that might have been a very old version.

The big one for me was https://borgbackup.readthedocs.io/en/stable/faq.html#can-i-b....

Re: Timeshift: System Restore Tool for Linux

#85

Post by kmarc »

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…

For home backup, I have a similar setup with dedup, local+remote backups.

Borgbackup + rclone (or aws) [1]

It works so well, I even use this same script on my work laptop(s). rclone enables me to use whatever quirky file sharing solution the current workplace has.

[1]: https://github.com/kmARC/dotfiles/blob/master/bin/backup.sh

Re: Timeshift: System Restore Tool for Linux

#87

Post by grumbelbart2 »

mdavidn wrote: post #81
lmz wrote: post #77

Earlier quoted context omitted.

Your DB is supposed to guarantee consistency even in server crashes. (The Consistency, Durability part of ACID).

That consistency is built on assumptions about the filesystem that may not hold true of a copy made concurrently by a backup tool. e.g. The database might append to write-ahead logs in a different order than the order in which the backup tool reads them.

That's why you do a filesystem snapshot before the backup, something supported by all systems. The snapshot is constant to the backup tool, and read order or subsequent writes don't matter.

The main difference is that Windows and MacOS have a mechanism that communicates with applications that a snapshot is about to be taken, allowing the applications (such as databases) to build a more "consistent" version of their files.

In theory, of course, database files should always be in a logically consistent state (what if power goes out?).

Re: Timeshift: System Restore Tool for Linux

#88

Post by bayindirh »

Springtime wrote: post #64
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?

BackInTime works similar to Apple TimeMachine. It uses hardlinks + new files. Plus, it keeps settings for that backup inside the repository itself, so you can install the tool, show the folder, and start restoring.

On top of that BiT supports network backups and multiple profiles. I'm using it on my desktop systems with multiple profiles for years and it's very reliable.

However it's a GUI first application, so for server applications Borg is a much better choice.

Re: Timeshift: System Restore Tool for Linux

#89

Post by arianvanp »

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.

Nixpkgs is the largest and most up to date package repository according to https://repology.org/

I'm honestly curious what packages you have a problem with

Post reply on HN