Backups Aren't Simple • Hacker News Board

Re: Backups Aren't Simple

#211

Post by Dylan16807 » Thu, Sep 17, 2026, 6:32 PM UTC

mrheosuper wrote: post #176

Dylan16807 wrote: post #149

Earlier quoted context omitted.

Playing audio over bluetooth also wakes things periodically, but it uses almost no power. With a similarly competent design photo transfer should be very battery efficient.

No, most(if not all) bluetooth controller has audio offload, basically the cpu does not involve(or very little) when transfering data from storage to radio.

Don't you mean yes bluetooth controllers have audio offload? "similarly competent design" means you do the exact same thing in the other direction. Instead of rarely waking up the CPU to coordinate sending, you rarely wake it up to coordinate receiving.

Re: Backups Aren't Simple

#212

Post by graemep » Thu, Sep 17, 2026, 7:36 PM UTC

bnegreve wrote: post #207

graemep wrote: post #202

Earlier quoted context omitted.

What if that happens after your monthly creation of a new backup.

I keep the previous backup for one month and then delete it. So eventually the file is lost yes, but this is inevitable if you assume finite amount of storage.

In that case I think its a good system. Its very similar to an incremental backup in what it achieves.

Re: Backups Aren't Simple

#213

Post by pmw » Thu, Sep 17, 2026, 7:43 PM UTC

cortesoft wrote: post #39

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…

The problem with using glacier for backups is it's hard to run restore exercises, and without restore exercises, a backup is pretty dangerous

The most polished Glacier backup/restore mechanism I know -- because I helped build it -- is through rustic https://rustic.cli.rs/docs/commands/init/cold_storage.html>. It has native support for backing up to Glacier (because writing to Glacier is identical to writing to regular S3), and it supports external "warmup" programs to support cold storage of your choice, with Glacier having an existing warmup program you can use.

Re: Backups Aren't Simple

#214

Post by iririririr » Thu, Sep 17, 2026, 8:34 PM UTC

GTP wrote: post #157

iririririr wrote: post #136

Earlier quoted context omitted.

why do you assume a functionality will obligatory be abused against the client? pro camera manufacturers are not google or apple. Have we became that defeatist?

Unfortunately, your comment reminds me that car manufactures aren't Google or Apple either, and still it seems that modern, high-end cars have a tendency of collecting more than what's needed for the car to remain in good shape or be diagnosed. I guess we became so defeatist when more and more companies started realizing they could make extra profit by collecting data from their customers.

Of course they are google and apple. They are in an even more monopolisticaly and gov enabled market!

just look at the chinese import ban on both mobile phones and cars!

Re: Backups Aren't Simple

#215

Post by rsync » Thu, Sep 17, 2026, 9:01 PM UTC

rsync wrote: post #204

zenoprax wrote: post #131

Earlier quoted context omitted.

I've been trying to find a solution for this too! I was considering using Rclone but too many things are using SQLite for me to trust rsync. I was also going to go with CoreOS but I'm leaning towards Fedora Cloud now in case I need to manage things a bit more (and "auto updating" is not something I want as that suggests auto rebooting). Your secrets.yaml makes me nervous though - too easy to miss a key and leave some…

Are you aware of sqlite3-rsync ? It is a tool that was created by the author of sqlite. It does just what you would expected to do.

It is here:

https://sqlite.org/rsync.html