-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
"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) 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 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.[2]
"As a sidenote, what keyboard are you using?"
It is a Keytronic E03600U2.
[1] https://www.borgbackup.org/
[2] ... which happens to be the core he.net datacenter - one of the nicest and most operationally secure datacenters I have ever been in.
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://github.com/derekp7/snebu, and the tarcrypt extensions to tar are described at https://www.snebu.com/tarcrypt.html).
If you want to see more on this theme, the Upspin docs[1] are a really interesting read. This 2017 talk[2] that Rob Pike gave on it is also really good.
[1] https://upspin.io/