3 ms·

"How are personal files being handled? Is encryption being used? Are you able to access this data using a shared key?" We give you an empty UNIX filesystem. S

by rsync 6y ago

"How are personal files being handled? Is encryption being used? Are you able to access this data using a shared key?" We give you an empty UNIX filesystem. So, if you push up files over rsync or sftp, they will sit here unencrypted. However, there are now excellent "tools like rsync that encrypt the remote result with a key rsync.net never sees" - chief among them being 'borg'[1]. Other options include duplicity and restic - all of which transport over SFTP. So it's up to you and you have total control. If you want ease of use and you want to browse into your account (or one of your immutable daily snapshots[2]) and grab a file over SFTP you probably don't want to encrypt everything on this end. On the other hand, if you want a totally secure remote filesystem that is nothing but encrypted gibberish from our standpoint, you should use 'borg'. "Are you able to access this data using a shared key?" We are running stock, standard OpenSSH and you can, indeed, use an SSH keypair to authenticate with. In fact, you have a .ssh/authorized_keys file in your account so you can specify IP restrictions and command restrictions as well ... " ... how will you be able to recover from physical failure if you only appear to be serving from a single location?" A standard rsync.net account has no replication. We are the backup and your account lives in, and only in, the specific location you choose when you sign up. However, for 1.75x the price (ie., not quite double) we will replicate your account, nightly, to our Fremont, CA location.[3] "As a sidenote, what keyboard are you using?" It is a Keytronic E03600U2. [1] https://www.borgbackup.org/ https://www.borgbackup.org/ [2] We create and rotate/maintain snapshots of your entire account that are immutable/readonly - so you have protection against ransomware/mallory. [3] ... which happens to be the core he.net datacenter - one of the nicest and most operationally secure datacenters I have ever been in.

frammie 6y ago
Thank you for clarifying your points, as I've said in my previous reply I do appreciate the simplistic approach. As well I mean no offense, the entire platform seems very sturdy though it leaves some questions which aren't apparent immediately (which may just be me) If I wasn't contempt with my current backup solution I would seriously consider yours, and I wish you guys the best of luck. You're one of the few keeping simplicity as a key value.
vinay_ys 6y ago
The phrase 'Cloud storage' conjures distributed replicated fault tolerance within a region to provide high availability and strong durability against datacenter disasters (fire, electrical/mechanical failures etc) and cross geographic region replication to protect against natural calamities (earthquake, tornado, floods etc). It also conjures a managed service with object-level (volume, directory, file) metadata, versioning and strong identity access management capabilities. rsync.net doesn't seem to do any of these and charges 0.5 cent more per GB/month. What's the secret advantage I'm not seeing?
- rsync 6y ago
  "and cross geographic region replication to protect against natural calamities (earthquake, tornado, floods etc)." As I mentioned - you can have that. That "geo redundant" service is managed by us and requires no intervention on your part. It costs 1.75x more. "It also conjures a managed service with object-level (volume, directory, file) metadata, versioning and strong identity access management capabilities." We give you an empty UNIX filesystem that you access over (Open)ssh. Whatever metadata and identity management comes with that (or with overlay tools, like borg or restic) you may use as you see fit.
benlivengood 6y ago
Once ZoL hits in 13 are you planning to give users direct access to ZFS for encrypted filesystems? My goal is to have a remote ZFS host I can push my snapshots to without loading the keys remotely. That would give me emergency access to the files if I load the key (less preferable), but mostly the ability to receive all the remote filesystems+snapshots to local storage with the flexibility of ZFS tooling. Right now I encrypt the incremental snapshot streams and archive them on traditional backup systems which doesn't allow the same flexibility or assurance. I'd be happy with a socket/pipe to 'zfs recv zpool/benlivengood/data' that I could throw send-stream data at once a day or so.
derekp7 6y ago
Since I've had a handful of users ask about cloud storage for Snebu, Would you be interested in adding Snebu as a supported protocol? It should be similar to how you currently support Borg. For Snebu, the client runs find and tar, sending results via ssh to the snebu binary on the remote host. And more recently client-side public key encryption support has been added via a client-side filter called "tarcrypt". Ideally, a customer would use Snebu to back up to a local device on their network (for example a Raspberry Pi with a large USB drive attached), and then use Snebu's efficient replication to send deltas to the cloud-hosted server. Client files are stored individually (deduplicated) on the Snebu server, and metadata is in an SQLite DB (advantages over Borg is more open standards for the data storage and public-key encryption, disadvantage is file-level instead of block-level deduplication and a project that isn't as widely used). If you are interested, I would be more then happy to have an extended discussion with you going over implementation options, and updating the client side script to make it work better with your service. (https://www.snebu.com https://www.snebu.com, https://github.com/derekp7/snebu https://github.com/derekp7/snebu, and the tarcrypt extensions to tar are described at https://www.snebu.com/tarcrypt.html https://www.snebu.com/tarcrypt.html).

by rsync 6y ago

frammie 6y ago

Thank you for clarifying your points, as I've said in my previous reply I do appreciate the simplistic approach. As well I mean no offense, the entire platform seems very sturdy though it leaves some questions which aren't apparent immediately (which may just be me) If I wasn't contempt with my current backup solution I would seriously consider yours, and I wish you guys the best of luck. You're one of the few keeping simplicity as a key value.

vinay_ys 6y ago

The phrase 'Cloud storage' conjures distributed replicated fault tolerance within a region to provide high availability and strong durability against datacenter disasters (fire, electrical/mechanical failures etc) and cross geographic region replication to protect against natural calamities (earthquake, tornado, floods etc). It also conjures a managed service with object-level (volume, directory, file) metadata, versioning and strong identity access management capabilities. rsync.net doesn't seem to do any of these and charges 0.5 cent more per GB/month. What's the secret advantage I'm not seeing?

rsync 6y ago
"and cross geographic region replication to protect against natural calamities (earthquake, tornado, floods etc)." As I mentioned - you can have that. That "geo redundant" service is managed by us and requires no intervention on your part. It costs 1.75x more. "It also conjures a managed service with object-level (volume, directory, file) metadata, versioning and strong identity access management capabilities." We give you an empty UNIX filesystem that you access over (Open)ssh. Whatever metadata and identity management comes with that (or with overlay tools, like borg or restic) you may use as you see fit.

benlivengood 6y ago

Once ZoL hits in 13 are you planning to give users direct access to ZFS for encrypted filesystems? My goal is to have a remote ZFS host I can push my snapshots to without loading the keys remotely. That would give me emergency access to the files if I load the key (less preferable), but mostly the ability to receive all the remote filesystems+snapshots to local storage with the flexibility of ZFS tooling. Right now I encrypt the incremental snapshot streams and archive them on traditional backup systems which doesn't allow the same flexibility or assurance. I'd be happy with a socket/pipe to 'zfs recv zpool/benlivengood/data' that I could throw send-stream data at once a day or so.

derekp7 6y ago

Since I've had a handful of users ask about cloud storage for Snebu, Would you be interested in adding Snebu as a supported protocol? It should be similar to how you currently support Borg. For Snebu, the client runs find and tar, sending results via ssh to the snebu binary on the remote host. And more recently client-side public key encryption support has been added via a client-side filter called "tarcrypt". Ideally, a customer would use Snebu to back up to a local device on their network (for example a Raspberry Pi with a large USB drive attached), and then use Snebu's efficient replication to send deltas to the cloud-hosted server. Client files are stored individually (deduplicated) on the Snebu server, and metadata is in an SQLite DB (advantages over Borg is more open standards for the data storage and public-key encryption, disadvantage is file-level instead of block-level deduplication and a project that isn't as widely used). If you are interested, I would be more then happy to have an extended discussion with you going over implementation options, and updating the client side script to make it work better with your service. (https://www.snebu.com https://www.snebu.com, https://github.com/derekp7/snebu https://github.com/derekp7/snebu, and the tarcrypt extensions to tar are described at https://www.snebu.com/tarcrypt.html https://www.snebu.com/tarcrypt.html).