[flagged]
Backups Aren't Simple
191–200 of 208 posts
Re: Backups Aren't Simple
#192A 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
[dead]
Re: Backups Aren't Simple
#193Earlier 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 seem to remember being able to select all of the photos in iCloud in a browser and clicking download. It zips them and it worked.
I would imagine this doesn't work well after a certain amount of data. I’m also not sure they were the originals.
Re: Backups Aren't Simple
#194I have a cron script that rsync my entire home directory every day with a remote server. Since rsync doesn't remove remote files, I re-create a backup from scratch the first day of each month and store a copy of the previous one. Using old standardized open source tools means it survives system updates without having to fix anything for years. I got my laptop stolen/lost 3 times over the past 15 years, and I have alw…
rsync can delete remote files with --delete or --delete-after What is missing is recovering accidentally deleted or corrupted data.
> rsync can delete remote files with --delete or --delete-after
Yes but I don't use it precisely because that lets me recover files that I have accidentally deleted. I assume it's the intended default behavior of rsync.
Re: Backups Aren't Simple
#195> There are two types of people: those who have suffered a catastrophic loss of data, and those who will. This is an empirical claim, but is it grounded in reality? 99% of people don't backup, and that's probably the right choice because the risk is low, they can't meaningfully improve their restoration rate themselves and they don't care enough about their data to classify its loss as catastrophic. When a person hea…
> When a person hears someone talk about the importance of backups, but also haven't heard friends/family suffer this date, they will rightfully ignore this warning.
Maybe they just haven't talked to you about it? Most people I know have suffered some form of (partial) data loss or another, and lived with it.
Re: Backups Aren't Simple
#196I’m setting up 3-2-1-ish backups for my infra of 3 hosts, and definitely leaning towards Restic + Backrest. All my hosts run the same CoreOS setup ( https://github.com/ebrahim37/infra-template ), where container volumes are placed in one central volumes/ folder and that is the only thing I have to backup. I plan to implement it like this: vps1: - restic container with custom sh entrypoint that will backup volumes/ to…
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…
I like CoreOS because of the fact that all config, etc files, sysctls are in one place.
Previously, I was using artix and had this “etc” directory[1] checked in to keep track of system configuration, but there was no good way to keep track of config drift (other than remembering to update this dir).
Haven’t gone through a CoreOS update yet (been using for ~2 months), but doubtful it would break anything. I’ve tested to make sure all my containers shutdown gracefully etc.
The SOPS (secrets.yaml) pattern is more common in NixOS configs, and I found it works nicely here too. In the artix setup, I had a bunch of .example files strewn around [2], which I had to remember to sync with the real versions.
Encrypting a key is just prefixing it with “enc_priv_”, SOPS will encrypt and decrypt it automatically. I keep “public” values plaintext to maybe help someone setting this up for themselves. Just have to double-check git diff before committing.
[1] https://github.com/ebrahim37/infra-template/tree/00eccff06ae... [2] https://github.com/ebrahim37/infra-template/blob/00eccff06ae...
Re: Backups Aren't Simple
#197Earlier quoted context omitted.
If you have lots of data, I would suggest using a filesystem designed for this, like ZFS or BTRFS. You would still have to spend in storage though, as ultimately protecting from bit rot requires redundancy.
I do use btrfs, but I don't really understand how to use it to protect against bit rot. I tried to look into it at some point, but got overwhelmed. Did invest in two backup copies, one of them off site, though. However, looking at prices, I can see one of those backups just being dismantled to be used as more storage.
If you got overwhelmed in trying to understand how to do it, just do it the easy way: create a ZFS pool of two drives of identical size in mirroring. Then, make sure to have regular scrubs (this means ZFS will regularly check all files for corruption, and recover from eventual errors), use your OS' task scheduler (e.g. Systemd or cron) to run this once a month. This should be sufficient to protect you from bit rot.
Re: Backups Aren't Simple
#198Re: Backups Aren't Simple
#199Earlier 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…
Yup. Only reason I'm on OneDrive is that they don't mess with photos and their metadata. For now, at least.
I guess it's because the core offering is still some version of "a folder that syncs", and the photo gallery is just a view bolted on top.
I steer clear of any solutions scoped to photos only, as it always turns out they either screw you up by reducing quality and throwing away the originals, or trying to lock you in by only offering metadata they keep in a database they will not let you export.
Re: Backups Aren't Simple
#200I don't want backups. I want synced duplicated data in geographically separated by shared credentials.
> I don't want backups. I want synced duplicated data in geographically separated by shared credentials. If you accidentally delete something, how long does it take for the delete to propagate to all of your geographically separated datacenters? You need some sort of point-in-time snapshots to be able to recover from accidents and silent corruption.
Dropbox is quite good like that - you can get back deleted or changed stuff up to 30 days old.