1. Test your backups. I see no testing procedure described, and although maybe the author's scripts have spot checking beyond what is described in the article, code will only ever catch the cases it was programmed to expect.
Manual testing does not have to be frequent or extensive, but making sure the backups are still recoverable and complete (take five minutes to spot check some old and new files) every six months helps ensure no silent issues are occurring
2. Less importantly: use append-only backups to an independent system. While ransomware for consumers is comparatively rare these days, it would give me peace of mind. The author's deposit box mostly fulfils that purpose, but whether it gets filled with bogus data or wiped by the malware is a matter of luck in timing (with the odds heavily in their favor due to the irregular connection of the drive and the existence of another computer that the malware probably isn't programmed to expect).
Of course, "append only" is a bit of a misnomer because eventually you'd run out of space, but the system should independently delete old data rather than being able to command it remotely (from the potentially infected system) to wipe anything. Restic has docs with considerations for data deletion in an append-only setup (disclose: I helped write them), which are also relevant if you don't use restic because they describe the method more than the specific implementation: https://restic.readthedocs.io/en/latest/060_forget.html#secu...
What happens if you discover something is missing or corrupted after 6 months?
E.g. if I use some special backup software that creates incremental archives or whatever, and then I die... My family would have absolutely no idea how to access that data. While with a normal NTFS partition and data on an external HDD they could just plug it in some PC and look at the family photos.
> rsync everything to each of them, bringing one down to a safe deposit box downtown, and taking out the one that was there from my last visit
Sounds like you are underestimating how much time you spend on backups. Sounds good though
Accept the impermanence of data, memories and memorabilia.
Ideally I'll strive to keep that data backed up as long as I can, and will mourn its loss, but mentally I prepare myself that one day I might lose access in some way. Most importantly, that data is also 99% irrelevant to the next generation, maybe save for a handful of photos or videos ("what did grandpa look like?"). So in the grand scheme of things it's not like I have to be an epic archivist of my own life.
I suppose it helps that this was done for me in the past - toxic family members threw out all my childhood family photos a decade ago.
I went to school with a boy who had no photos from his youth. His parents took many photos but didn't get them developed, and when they took all the films to the pharmacy (here in the UK) to get them developed, the pharmacy sadly burned down and they didn't ever get any photos. Quite sad I thought.
"Files I use and change every day" are on Dropbox, which gets synced to a NAS.
Photo and video files are directly stored on the NAS and don't live anywhere else.
The NAS is rsynced automatically every day to an external disk (connected via USB) of which there are three copies. One is in a safe at home, the other at my parents' house. The one in the safe is rotated every week, the one at my parents' every month.
If my house gets robbed or even burns down it's likely the disk in the safe will survive and I lose only one week of data. If the house gets completely destroyed or the safe is cracked, then I can turn to the disk at my parents and lose one month.
It's true that rsync is not a backup. But by default rsync only adds data. Delete is an option one has to turn on. My daily rsync does not have the delete option. I have a different script with delete, that I run manually.
The theory was that I would review the delete process with a dry run before committing to it. In practice I don't do this and simply run the delete script occasionally, which ruins the purpose. But I guess I could be more careful if I really wanted to.
Fairly easy to configure, does snapshots to S3 and has a icon in my tray I can watch :)
Everything boils down to your amount of files or GBs when some solution becomes "too slow" doing incrementals and/or file processing. My two cents.
> Daily rsync to an encrypted Linux USB stick attached to the desktop.
> Daily rsync to an encrypted MacOS USB stick attached to the laptop.
> Daily rsync to an encrypted ZFS SSD inside the desktop.
> Daily rsync to OpenBSD remote attached storage at vultr.com
> [...] I do it a few times a day, especially if I’ve just made or saved something of value. And always right before I shut down the computer, which I do almost any time I step away from it for more than a few minutes.
Have you ever noticed blog posts rarely go viral if they describe a normal setup, and are much more likely to do so if they describe a really complicated setup?
I'm all for people coming up with needlessly complex homelab setups if they have fun doing so - but sometimes I wonder whether newbies see this sort of thing, and think Linux needs this level of complexity.
To be fair, people who aren't already familiar with Linux, won't even come across these articles to begin with.
But I can see when this type of articles reach someone through a network on Twitter or reddit, when they hear alien technical tools and script this and that they think: "Cool, that's what IT specialists do, not for me, I'm doing fine."
Resilient? Yes. Simple? No.
I'm aware ext4/3 filesystems don't store creation times. But I want to use rsync on Linux to sync files between an NTFS(supports creation times) and a Btrfs partition(also supports creation times) without losing the creation times.
Currently rsync just sets the creation time to the modification time on the destination directory. Which is not what I want.
When I use `--crtimes` I get a "This rsync does not support --crtimes (-N)" error.
Weirdly, just using `cp -a` works. But it doesn' t have any of the checksumming and differential copy bells and whistles of rsync.
How do you rsync on linux while preserving creation times(on supported file systems)?
First, ext4 actually does support creation times, called "crtime". But there's some internet confusion about it since this support predated linux kernel support, so you had to use ext4-specific tooling (on an unmounted filesystem) to access it, e.g.:
debugfs -R 'stat <inode>' /dev/nvme0n1p1
debugfs -R -w 'set_inode_field <inode> crtime <new-time>' /dev/nvme0n1p1
The btrfs situation is similar, but btrfs called it "otime" (for some reason?). Linux 4.11 introduced kernel-level support unified across all filesystems, calling it "btime" (birth time).But the normal file syscalls only support reading btimes, not setting them to arbitrary values. And rsync on linux, as you saw, can't do anything the kernel doesn't have a syscall for. For a while the only option was to:
1. set the system clock
2. create a file (at which point the kernel sets btime to the system time, plus a few nanoseconds)
3. restore the system clock
Obviously a huge hack, and needs root, but tools like s-tar automated it (search for "time storm" in this manpage):
https://web.archive.org/web/20220331080358/http://schilytool...
I almost gave up and spun up a Windows VM (since Windows has supported reading and writing creation times since the beginning). But then it clicked -- the kernel interface to the filesystem module takes the btime as an explicit parameter. So if you could find a kernel module that talks to the filesystem module directly (instead of going through the usual high-level file syscalls), you can pass along any btime you want. And there just so
My work directories are synced on all devices. With my NAS up 24/7, I can always pick up the last changes when I switch computers. The irreplaceable documents (all my notes, taxes, company accounting,...) are also backed up by the NAS on Backblaze, keeping all versions. I occasionally create a snapshot on Backblaze for those files – should totally automate that but I'm lazy.
I do agree though: it's more "syncing stuff between multiple places" than a real backup.
In the before times I put everything in Dropbox. Dropbox synced with an empty directory by mistake and deleted everything. Not going to use Dropbox again.
- Dropbox for "core files" (small subset of files I don't want to lose, mostly my notes, papers, etc) - Arq with S3 for backups (do a backup each hour) - An external SDD to do semi-frequent backups (mostly used in case I change laptop to ensure I have a backup of my files, but otherwise I mostly rely on Arq)
zfs rent = 4+TB drive + $10/mo (base 1TB) + $5*3 (extra 3TB) = drive + $25/mo
hetzner = 5TB $10.9/mo
vultr = $5/mo (probably more)
4x ~4TB drives = $800
assuming you replace drives every 5yrs: $3,254 or $54.23/mo.
assuming the drives last 10yr which are common now: $5,708 or $47.56/mo.
7€/month for 5y
If you want to use rsync, do rsync and snapshots...and those snapshots should automatically made on the remote destination (can be just a daily cron), only accessible read only from the source machine without having any administrative rights to tamper them.
HN: nitpick about potential problems which are present even in some industry grade data loss solutions.
This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
And that included the time when HDDs had a tendency to fail. And what little data loss occured was actually a grand total of 3 hours of work to recreate it.
I simply don't get the obbsession people have with data back ups for their private needs.
All power to the author, that's a hell of a set up.
- servers and laptops (laptops : except /home): restic to local minio instance + rclone to B2 storage
- /home of laptops : kopia to b2 storage
I never delete those snapshots because the big items like images don't change.
Well, that's a fun casualty of the title filter!