4 ms·
Folks, remember the 3-2-1 rule. IMO, it’s still extremely relevant, even in today’s cloud-centric world. For data you can’t afford to loose, please, for the lo
by cpach 5y ago
Folks, remember the 3-2-1 rule. IMO, it’s still extremely relevant, even in today’s cloud-centric world.
For data you can’t afford to loose, please, for the love of ${DEITY}, don’t store it with just one vendor. You never know what happens.
https://www.backblaze.com/blog/the-3-2-1-backup-strategy/ https://www.backblaze.com/blog/the-3-2-1-backup-strategy/
- bombcar 5y agoI think that people forget that you need two copies of your data under your control - and when your data is primarily on the cloud it is not data under your control; it is under the cloud company's control. You should have at least one copy that is physically in your possession, offline preferably, so that you have access to it. For my cloud data, I sync it down to a local server and then sync that to removable offline media.
- KronisLV 5y ago> For my cloud data, I sync it down to a local server and then sync that to removable offline media. This seems like an excellent approach. Personally i use BackupPC which internally uses rsync and allows for incremental backups, compression and deduplication of said backups as needed, then copying the data over to additional HDDs with cron. Works pretty decently on a slow residential connection, since it all happens in the background through WireGuard and one of my homelab boxes. Plus, BackupPC allows to test restoring backups with a single click, on a per-file or per-directory basis. Of course, internally the solution is a bit of an Eldritch mess with Perl and whatnot, so other pieces of software like Bacula might be more popular in comparison.
- 1970-01-01 5y agoYou forgot to explain it: Make 3 copies of your systems (just data if you can rebuild infra within your RTO) Use 2 different media (compress then encrypt) Move 1 copy off-site. (print the encryption key and store that in a fireproof safe)
- freemint 5y agoMaybe not compress and encrypt depending on your thread model.
- noodlesUK 5y agoI generally think not encrypting data is a bad idea, but I can see a world where that’s a risk trade off you want to make (such as a hard drive with family photos). Why wouldn’t you want to compress it though?
- freemint 5y agoThere are cryptographic attacks that can exploit things being compressed. If an adversary can control some part of the files you compress together with sensitive information the size of the compressed backup provides a side channel into the content of the sensitive data.
- jl6 5y agoLast time I surveyed my data, more than 99% of it was in an already compressed format (e.g. JPEG and HEVC), so compressing the backups added almost no benefit. (Now, that’s not strictly true any more for JPEGs thanks to projects like lepton and JPEG XL which can indeed compress already-compressed JPEGs losslessly).
- KronisLV 5y ago> Last time I surveyed my data, more than 99% of it was in an already compressed format (e.g. JPEG and HEVC), so compressing the backups added almost no benefit. Personally, i use regular HDDs for storage of data (SSDs are out of my price point for anything but boot drives) and having fewer larger files seems to result in slightly better copying performance than having more smaller files. Though that might also have to do something with the file system and method of copying as well.
- jl6 5y ago
- mekster 5y agoI don't like 3-2-1. It's pretty fragile. I don't know how any sys admins can sleep over 1 remote backup. My setup has 4-2-2 and using 2 different backup implementations for the remote, so bugs in them wouldn't be corrupting entire backups unknowingly at the same time. Apparently the 1 local and 2 remotes are having generations of incremental backups as well.