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

211–219 of 219 posts

Re: Backups Aren't Simple

#211

Post by Dylan16807 »

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 »

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 »

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 »

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 »

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

Re: Backups Aren't Simple

#216

Post by wuschel »

wallst07 wrote: post #151
baxtr wrote: post #79

Earlier quoted context omitted.

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

Amazing question with nobody really answering your question 100%. The answer is : it's hard. If you only have a iphone and more photos on your icloud than can fit on your phone, you're kinda screwed if you don't know what you're doing. AFAIK Apple makes it very difficult to get all your icloud photos bulk downloaded, original quality off icloud. Google is no better. It's much easier to start backing up from the begin…

I did not try it, and I am nervous the day I need to - but I think there are some solutions to export photos from the Apple technology stack using open source software [1,2,3].

I remember seeing a longer blogpost re the topic of retroengineering the Apple phot sync story, but I could not find it.

[1] github.com/rcarmo/PhotosExport [2] https://github.com/craigtrim/icloud-photo-export [3] https://icloud-photos-downloader.github.io/icloud_photos_dow...

Re: Backups Aren't Simple

#217

Post by GarnetFloride »

voiceofunreason wrote: post #32
AdieuToLogic wrote: post #27

A friend of mine used to work at Veritas[0] making enterprise data retention solutions. When I spoke about their product as being "making backups", he corrected me by saying: We are not in the backup business. We are in the restoration business. 0 - https://en.wikipedia.org/wiki/Backup_Exec

Backups are boring. Restores, on the other hand, are often exciting.

Restores can be Very exciting. I worked tech support and got trained on an email server backup program. I was alone for my first call on the program.

Before I could finish the greeting I knew it was going to be a wild call as I could hear in the background someone shouting and someone sobbing, the guy actually on the phone sounded like he wasn't planning on making it home that night.

Turned out they were testing out some sync software and after a test they deleted the sync without turning off the app which then did its thing and now nobody could log in except admin who was the only user left.

I was able to find and confirm that the backups were in place and accessible. Which was good, I could hear them breathing again. But I had no way to get the restore going because the source server was so hosed.

Just then the dev walking by and I got him on the call and he did some outright hacker magic to get things to the point that a restore could function.

I thought about writing my notes into a troubleshooting guide but then realized it would be better to skip the hacking and make a setup guide that showed them how to set it up properly in the first place.

Re: Backups Aren't Simple

#218

Post by skylurk »

pariainterpares wrote: post #181
wallst07 wrote: post #151

Earlier quoted context omitted.

Amazing question with nobody really answering your question 100%. The answer is : it's hard. If you only have a iphone and more photos on your icloud than can fit on your phone, you're kinda screwed if you don't know what you're doing. AFAIK Apple makes it very difficult to get all your icloud photos bulk downloaded, original quality off icloud. Google is no better. It's much easier to start backing up from the begin…

Not a very good answer. If you have a Mac with sufficient storage, you can just enable iCloud to store photos locally, then export them. That could miss some data (I think descriptions you set for a photo were not exported the last time I checked), but it is most of the data.

Do you need to export them? Can you not copy the library file to a different drive?

Re: Backups Aren't Simple

#219

Post by jongjong »

TeMPOraL wrote: post #93
jongjong wrote: post #57

When it comes to software, it's almost never simple. What people think of as simple is rarely so. For example: Requirement: "Just copy a file from folder A to folder B." Minimal translation: "Implement the capability to copy any file, in any format and of any size from SharePoint, located at a configurable path, with appropriate authentication and access control checks, then stream it in chunks to a different, config…

Here's a thing: my intent and requirements actually are: "Just copy a file from folder A to folder B." All that access control and authentication and symlink nonsense? That's a self-inflicted problem that exists only in enterprise, and shouldn't be assumed - much less created - for regular users.

This is your intent until I finish implementing and then you complain that it doesn't also work with folders or large files and it doesn't work with any file system. Or you will complain if your colleague accesses your file without your permission.

Reality of software development is that the user would expect every single one of those things but they simply don't understand what they want up front.

There are three different aspects to consider in my experience; what the user says they want, what the user thinks they want and what the user actually wants.

The three can have substantial differences.

Post reply on HN