5 ms·
You should just encrypt your data yourself before it gets to your provider. It takes an extra step and is annoying but then you can store the data anywhere that
by Rd6n6 5y ago
You should just encrypt your data yourself before it gets to your provider. It takes an extra step and is annoying but then you can store the data anywhere that’s cheap and convenient
- kangaroozach 5y agoWhat’s best way to do this on Mac?
- deleted 5y ago[deleted]
- eric__cartman 5y agoPersonally I split everything into equally sized tar.gz files, encrypt everything with gpg and upload it using rclone. It should be easily doable and scriptable in any Unix-like machine. It's not the fastest way of doing this, and very inconvenient if you need to access the data often. I only use this for off-site archiving that I will never use unless something catastrophic happens.
- danuker 5y ago> I will never use unless something catastrophic happens Have you ever tried to restore from one such archive?
- eric__cartman 5y agoYes, it's quite easy. Once all the gpg files are decrypted, the tar archives can be uncompressed with any piece of software that supports tar archives.
- spinax 5y agoYou've basically just described duplicity with rclone as the backend (their term). I personally add duply in front for usability (it handles your includes, excludes, "profile", etc.). Restoring is easy with these 3 working in tandem, and you can manually extract the data as needed for SHTF - just gpg encrypted tarballs. duply runs duplicity who runs rclone in a soundbite.
- aborsy 5y agoI am curious, why don’t you use rclone crypt? (And as someone said, duplicity).
- 1630269196 5y agoI used to do something similar, but these days I either just use rclone's crypt backend (folder hierarchy is kept intact, files encrypted and filenames obfuscated), or a Restic repository hosted on an rclone backend.
- cpach 5y agoRestic is one option https://restic.net/ https://restic.net/
- xmodem 5y agoThere are tools that will provide a virtual drive backed by files that are encrypted on disk. I use Cryptomator [1], which is cross-platform and is designed with cloud syncing in mind, but on mac you can just use Disk Utility to create an encrypted DMG. [1]: https://cryptomator.org/ https://cryptomator.org/
- kayodelycaon 5y agoPersonally, I use encrypted sparse disk images. (You can make them with Disk Utility.) It makes a disk image using many small files in a folder. Might leak some information related about size or number of the contents, but the contents and metadata of the filesystem are encrypted. This method can result in corruption of the disk image if you’re not careful. Edit: This is probably the most seamless way to handle encryption. It’s built in to the OS and you can save the password in Keychain if you like. Used it with Dropbox for years. Just make sure to unmount and let it sync before opening the disk on another system.
- jsjohnst 5y agoI use this same route pretty heavily across several cloud backup providers and never had corruption issues, but yes, it’s technically possible corruption could occur.
- kayodelycaon 5y agoCloud backup is unlikely to corrupt a disk image. Syncing one through Dropbox and having it open on two computers at the same time is living dangerously. :)
- jsjohnst 5y agoHaving two independent writers to a file is generally living dangerously, even without the extra complexity of unpredictable async file syncing.
- Rd6n6 5y agoI’ve been trying duplicati recently and it seems fairly simple and is cross platform with a GUI
- olalonde 5y agoI use rclone crypt for that (https://rclone.org/crypt/ https://rclone.org/crypt/).
- TillE 5y agoYeah I don't really understand all the chatter about the details of "end-to-end encryption" in this or that product. If you care, if it's important, you absolutely need to take control of that yourself.
- hyperhopper 5y agoThe chatter is because storing a blob of encrypted files is secure, but it is another hassle for and end user, and maybe even more importantly, comes with less features: if I stored my photos in an encrypted blob, I wouldn't be able to type my friends name and see all pictures I have with my friend from a random web portal on my phone. End to end encrypted services allow for users to do more interesting things with the data
- red0point 5y agoOf course, but it's not like other providers offer this ability already "baked in". At the same time, Backblaze only offers a security-theatre for encryption - they give you the ability to encrypt your backup private key with a password before sending it to them. But during restore, they collect this password and decrypt everything server-side. What's the point of offering encryption then?
- jdlshore 5y agoBecause security isn’t black and white. If you’re going to use BackBlaze’s software, which has access to all your files, you have to trust Backblaze as a company. If you don’t trust them, don’t use their service. Simple. There is no circumstance under which you can both distrust them and run their software. (Try tarsnap instead.) So now the question becomes: what threats are you protecting yourself against? For me, it’s: - malicious employees accessing my data - a security breach giving outside actors access to my data. Encrypting the backups and encrypting the private key protects me against these threats. My “restores” aren’t protected against these threats, because they’re not encrypted (as of 2019 when this FAQ was written), so that’s a gap. It’s one I’m willing to put up with because I can mitigate the risk by not leaving restores hanging around.
- red0point 5y agoYou’re saying that security isn‘t black and white, but trust somehow is, which I find a bit weird, since they‘re intimately related. Backblaze could easily reduce the trust required, which they‘re not doing, but have been promising to do for years, with nothing happening. Also, given your threat model, I‘d say the risk-mitigation is not applicable. Attackers lying low and continuously collecting and exfiltrating data is nothing new. Especially if this data includes passwords, private keys and data „zipping-by“. Or does your threat model include specifically only an attacker being advanced enough to compromise Backblaze, but somehow not being able to persist for a while? No, it‘s Backblaze‘s job of keeping data safe the best way possible, it shouldn‘t be necessary for customers to find excuses for their bad encryption scheme or to add another layer of encryption, especially if the fix is quite obvious and has been promised for years.