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

Backups Aren't Simple

filipovski.net

Post reply on HN
Print view View original

121–130 of 209 posts

Re: Backups Aren't Simple

#121

Post by afilipovski »

justsomehnguy wrote: post #55

> So our first principle is to have a backup, i.e. a copy of your files someplace else. So far so good. So who are we? A household with a localhost administrator?[0] Then you are surely doesn't need encrypted, chunk-level corporate level bla-bla-bla. You need a Syncthing copy to some other device not at home - and an additional backup procedure to maintain the history and protect against PEBKAC errors - which can run…

> So who are we? A household with a localhost administrator?

In my case, yes. I've gotten into the trap of building a homelab that over time became pretty important, more like a small prod environment. We take for granted the "stability" that cloud services provide (until the terms of service change and you are screwed over by either loss of privacy, loss of access, etc). Self-hosting these things yourself exposes you to this complexity.

Photos aren't that important, how about your passwords and documents and the whole setup around all this?

I also do a part of this just for the love of the game.

Re: Backups Aren't Simple

#122

Post by afilipovski »

innocent_name wrote: post #11

>Motivated by our success in developing this solution, we try to use it to backup the homelab with its 10 Docker containers. But later we find out from logs on the individual machines that backups are failing. The reason being that many Docker containers like to create root-owned files, and if you’re not careful you can create a cronjob running as the default user. and a privesc also.

The ideal setup is rootless Podman and having all your containers not even be able to create root-owned files.

It would also be great if services did their own database dumps. Immich does this and it's such a relief to just be able to copy over its volume for backup purposes.

Unfortunately we don't live in an ideal world and so much of the software both doesn't dump it's own databases, and is incapable of running in a rootless container.

If you weigh the probability of a privesc from your backup with full access to the volumes, against the probability that the software you run has a CVE, which one is worse?

This is one of those things I consciously chose to ignore in my setup. Maybe it will come back to bite me in the future, sure. Or maybe I will learn a better approach that pushes my frontier of convenience-security forward.

Re: Backups Aren't Simple

#123

Post by hovering_nox »

Helmut10001 wrote: post #83

I really like ZFS snapshots with offsite pull-mode sync using Jim Salter's sanoid/syncoid [1]. ZFS is the base for all OS/filesystems on top of it. If you have a good system for organizing ZFS datasets, and separating ephemeral from persistent data (e.g. [2]), then this is 90% of the backup requirements already fullfilled. [1]: https://github.com/jimsalterjrs/sanoid [2]: https://du.nkel.dev/blog/2026-05-16_rootless_d…

I like to use ZFS snapshots of running systems and then create and upload the backup from them via the excellent Borgmatic. (I know you can't depend on snapshots for databases and similar, but it's worked until now™.)

Re: Backups Aren't Simple

#124

Post by Gigachad »

Terr_ wrote: post #38
Gigachad wrote: post #36

Earlier quoted context omitted.

>I've been weary of using rewritable media for some time now as a consequence I briefly considered using bluray disks as a backup for my photos and other critical docs. But getting a decent bluray burner seems not so easy these days with most production winding down. Next best thing looks like the "object lock" feature on object store services that prevents deleting objects for a certain time.

I pretty much instantly wrote off physical media because I know I won't reliably move it to a separate location. If I'm going to have backups, I want ones that are not within fire/flood range of my computer. In terms of preventing "oops" moments, I'm mainly relying on software (restic) for that, where I trust that (A) backups always append data rather than replacing and (B) it's logic works for marking which data to…

You want to make sure the append only is enforced by the hosting provider rather than duplicity. Your backups should be resistant to having an attacker on the system who can run arbitrary commands with duplicity.

Re: Backups Aren't Simple

#125

Post by zenoprax »

Helmut10001 wrote: post #83

I really like ZFS snapshots with offsite pull-mode sync using Jim Salter's sanoid/syncoid [1]. ZFS is the base for all OS/filesystems on top of it. If you have a good system for organizing ZFS datasets, and separating ephemeral from persistent data (e.g. [2]), then this is 90% of the backup requirements already fullfilled. [1]: https://github.com/jimsalterjrs/sanoid [2]: https://du.nkel.dev/blog/2026-05-16_rootless_d…

Thanks for the second link - looks interesting.

I have an old and loud 16-bay server that boots every 7 days or so if no one is home, `syncoid there here`, and shuts off. I'll get pinged by uptimerobot once in a while if it's overdue and I'll get a notification if a pool is unhealthy or reaching capacity (`sanoid --health` I think). Otherwise I forget I even have it set up.

Automated cold backups are great peace-of-mind.

Re: Backups Aren't Simple

#126

Post by Gigachad »

BetterThanSober wrote: post #104
torton wrote: post #76

Earlier quoted context omitted.

There's plenty of backup services and cloud solutions. The article mentions Borg and Restic, others like Backblaze are more consumer friendly. Which needs do you have that aren't met by any of these tools?

> backup services and cloud solutions online backup should not be your primary method of backup, you're one billing, identity theft, financial issue, or health issue away from getting your backup nuked do you have PBS clout? if not good luck https://arstechnica.com/information-technology/2026/08/pbs-s...

Online only is fine as an actual backup, presuming you have the primary in your control.

It shouldn’t be the only copy of the data that exists.

Re: Backups Aren't Simple

#127

Post by snizovtsev »

nine_k wrote: post #37
snizovtsev wrote: post #30

I'm polishing my backup system right now, and found that `tar | zstd | gpg` plus a small vibe-coded wrapper is pretty much all I need. GNU tar has its own incremental index via `--listed-incremental=FILE`. Unlike Borg or Restic, which have their own more complicated repository formats, this leaves me with just one additional file (the `.snar`) alongside a dumb, portable full-disk tar archive. The nice part is that, u…

How well did it work for restoring? For me, the ability to mount a backup and look at a particular file proved to be important. Also, I restored from my backups four times; two of them was moving between machines, pretty quickly.

[dead]

Re: Backups Aren't Simple

#128

Post by abejora »

I agree with this sentiment! For our Abejora timesheet SaaS, setting up backups was one of the harder parts. We had to change direction a few times while implementing it.

We finally got a nice setup with CloudNativePG + Barman. This allows for point-in-time restores, but there were a lot of lessons to learn along the way.

- The various types of (database) backups (logical, binary, onsite, offsite, snapshots, write-ahead log...) in combination with the various types of data (database, files, cluster configuration...)

- In our earlier approaches, we tried to preserve the old database volume if it was not corrupt, and use that in our restore. This caused so many complications, because you are fighting the recommended approach. So now, when we need to restore, we always restore from backups and the 'live volume' is dropped.

- For a restore, we just spin up a completely new Kubernetes cluster, instead of trying to restore in-cluster. This is a lot easier.

- Many object stores allow for retention periods, which you can put to good use to prevent malicious or accidental removal of backups. HOWEVER, not all of them are really 'locked'. In some services, you can still override the lock with a forced delete; in others, you can still remove the project holding the storage buckets, which will delete the buckets, and so on... so test those things, instead of just blindly depending on a 'retention period' claim.

- We now automatically run a scheduled restore with verifications on a weekly basis. This requirement does shape your environment, so keep that in mind! There is also the question of how you can reliably and automatically verify that the restore restored the latest data (of a live prod environment). Various solutions exist here, but most are not very elegant!

Honestly, this is only worth it if you are already handling sufficient volume. If you are just starting out, then the easier approach is to just go with a hosted database, which will handle backups and point-in-time restores for you.

Re: Backups Aren't Simple

#129

Post by nodar86 »

baxtr wrote: post #79
publlus_enigma wrote: post #20

There are four times in my life I have suffered regrettable data loss incidents. The first was when the telephone pole outside our house was struck directly by lightning. Not only was it the loudest thing I have ever heard, the current surged through the telephone line, into the internal fax modem, and fries everything within its vicinity. I was 10. I did have backuos, but only only floppy and they didn't cover every…

Since we’re talking about it: anyone backing up their iCloud photos? If so, how?

I self-host Immich, and run the iPhone app to back up my photos. I used this guide [0] for the initial import.

[0]: https://github.com/immich-app/immich/discussions/21251

Re: Backups Aren't Simple

#130

Post by Gigachad »

dsego wrote: post #63
mrheosuper wrote: post #41

Earlier quoted context omitted.

Sadly after 22 years, it's still considered a "high-end" feature. Even on $1600 Fujifilm x100vi, there is still single SD slot.

I also have the same fuji. Digital cameras are still in the stone ages. I think Tony Northrup covered it well. Nothing has changed since digital cameras came to market, the workflow is still the same, copy files from a card to PC. They aren't connected to the internet, they don't have automatic syncing to cloud for backups or sharing, fuji doesn't even have a gps chip built in to store the location (only works if con…

Cameras had gps for a moment but they all dropped it because it sucks. GPS takes a long time to get a fix so unless you want to turn the camera on and sit for 5 minutes before taking the photo, it doesn’t work. Meanwhile an app on your phone can ping the current location to the camera for free. Your phone always has a location lock and it’s super power efficient at getting it.

And the rest of it is essentially features for a market that doesn’t exist. People buying cameras today don’t want to send straight to Facebook. They want to sort through raws, edit in Lightroom and then post from a laptop. The market for the features you want all moves to phones long ago.

Sony also has a bunch of the features you are asking for. It can connect to the internet and live sync files to an ftp server. It can even upload proxy videos so your editors can start work before you get back to copy the master copy over. Cameras are sold to prosumers and actual professionals now so the featureset reflects it.

Post reply on HN