4 ms·

I've used ZFS as my primary data workstation FS (as opposed to NAS), first under OS X and then FreeBSD, for over 4 years now, and amongst the many benefits back

by xoa 11y ago

I've used ZFS as my primary data workstation FS (as opposed to NAS), first under OS X and then FreeBSD, for over 4 years now, and amongst the many benefits backup/replication definitely rates highly for me. But while I'm interested to see native send/receive in the cloud, particularly once resumable support makes it into mainline OpenZFS, I'm actually not sure how useful it'd be in general for plain backup purposes. One of the most valuable choices Sun made in send/receive was that it uses normal stdin/stdout, and that in turn can give ZFS immense flexibility in terms of cloud storage targets. While I do local online replication to a NAS, for remote backup I just dump to files. Simplifying here without all the exact options: zfs send tank@snapshot | lz4 | openssl enc | par2 > file OpenSSL of course using AES-256 and a key, and par2 adjustable based on characteristics of the target storage. This is part of a simple script to produce and cycle incrementals. The result are an original and then set of deltas that are client encrypted and have some redundancy even in the face of errors in the foreign filesystem or transmission process, and thus can be used practically anywhere with minimal thought towards remote security, no need to trust any sort of closed client or service, etc. It works nicely with Amazon's offerings (including Glacier), particularly since they allow actually physically sending in a hard drive which is really handy for freelancers or small businesses with significant datasets but highly mediocre netlinks (ADSL 5/1 or some equivalent is still depressingly common in America at least). Since par2 can also split output to arbitrary sizes and numbers, it'd be possible to use this workflow for anything from optical to storage lockers as well (dataset size permitting). Really, with stdin/stdout the sky is the limit, and there are minimal ties to any specific service since only the most generic raw cloud storage features are being used.

rsync 11y ago
"Really, with stdin/stdout the sky is the limit, and there are minimal ties to any specific service since only the most generic raw cloud storage features are being used." That's the key and that's why it's here. It's a very, very stretched analogy, but from the very beginning, we at rsync.net have tried to run rsync.net itself as a unix primitive. After already supporting actions like this, for years: ssh user@rsync.net sha256 some/file ssh user@rsync.net s3cmd get s3://rsync/mscdex.exe mysqldump -u mysql db | ssh jo@rsync.net"dd of=db_dump" It made perfect sense to support workflows just like the one you describe above. And yes, you can indeed do just what you've written (with lz4 and openssl encryption)at rsync.net (with or without breakout to files).
RJIb8RBYxzAMX9u 11y ago
Are you doing a full dump each time and syncing that? Or are you dumping and syncing incremental streams (i.e. zfs send -i [...])? If the latter, how do you deal with expiring old dumps, without having to re-sync a full dump periodically?
- eeZi 11y ago
  That's what I thought as well. It's impossible to expire old backups that way since all backups sets depend on each other.
Freaky 11y ago
> openssl enc Careful. Openssl enc is basically a poor toy example, it's not a robust authenticated encryption tool for real world use. It explicitly doesn't support modern AEAD ciphers or even a simple MAC (so the ciphertext can be silently tampered with - note anyone who can do that can also replace your par2 files), and it doesn't use a robust key derivation algorithm for password use (single-round of a hash, basically, default MD5 - about as weak as it comes). hpenc looks like a nice high performance modern alternative: https://github.com/vstakhov/hpenc https://github.com/vstakhov/hpenc

by xoa 11y ago

rsync 11y ago

"Really, with stdin/stdout the sky is the limit, and there are minimal ties to any specific service since only the most generic raw cloud storage features are being used." That's the key and that's why it's here. It's a very, very stretched analogy, but from the very beginning, we at rsync.net have tried to run rsync.net itself as a unix primitive. After already supporting actions like this, for years: ssh user@rsync.net sha256 some/file ssh user@rsync.net s3cmd get s3://rsync/mscdex.exe mysqldump -u mysql db | ssh jo@rsync.net"dd of=db_dump" It made perfect sense to support workflows just like the one you describe above. And yes, you can indeed do just what you've written (with lz4 and openssl encryption)at rsync.net (with or without breakout to files).

RJIb8RBYxzAMX9u 11y ago

Are you doing a full dump each time and syncing that? Or are you dumping and syncing incremental streams (i.e. zfs send -i [...])? If the latter, how do you deal with expiring old dumps, without having to re-sync a full dump periodically?

eeZi 11y ago
That's what I thought as well. It's impossible to expire old backups that way since all backups sets depend on each other.

Freaky 11y ago

> openssl enc Careful. Openssl enc is basically a poor toy example, it's not a robust authenticated encryption tool for real world use. It explicitly doesn't support modern AEAD ciphers or even a simple MAC (so the ciphertext can be silently tampered with - note anyone who can do that can also replace your par2 files), and it doesn't use a robust key derivation algorithm for password use (single-round of a hash, basically, default MD5 - about as weak as it comes). hpenc looks like a nice high performance modern alternative: https://github.com/vstakhov/hpenc https://github.com/vstakhov/hpenc