by XERQ on 12/17/14, 12:00 AM with 49 comments
by Animats on 12/17/14, 2:23 AM
They're at 2522 Chambers Road Suite 100, Tustin, CA 92780. This is "Irvine Ranch Executive Suites" which advertises "Private Offices From: $ 375 to $1000 / Per Month, Identity Package (Phone and/or Mail Only) From: $ 65 / Per Month".
SSDNodes, Inc. (their parent company) is a Delaware corporation at that address. The agent for service of process is MATTHEW GEORGE CONNOR. He's on LinkedIn: https://www.linkedin.com/profile/view?id=166917144 and has another business, "Xerq.io". It's a social network (at https://xerq.io/hotness) which has a big banner ad for Jarvys.
There are terms of service (https://my.jarvys.io/JARVYS_TOS.pdf) but no sign of a service level agreement.
The pricing goes up by a factor of 10 after the first three months. $240/year for 150GB. That's more than 3x more expensive than iDrive, which supports Linux. Jarvys isn't cheap.
Not seeing a good case for using this service.
by vinceguidry on 12/17/14, 12:28 AM
On the other hand, if you're implementing catastrophic recovery in the first place, something's gone seriously wrong with your engineering culture, assuming you have one, or never implemented important capabilities in the first place, like one-command provisioning and deployment. Your app's years out of date but it's supporting your entire business. You can't afford to test your security end-to-end because if it fails, it might be days before it comes back up, because the guy that invented it skipped town, and there's bits of functionality hiding everywhere on the machines, done ad-hoc without any documentation.
Nothing says "Faith-based engineering" like buying a backup system you refuse to test. And I see it way too often.
by moe on 12/17/14, 1:04 AM
No word on what is actually backed up, how to include or exclude files.
No word on when anything is backed up and how (cronjob, daemon?).
No word on how running services and databases are backed up that may need special procedures for a consistent snapshot.
No word on how to restore or access backups when the backed up host has failed.
All things considered I have a strong feeling you are not qualified to run a service like this. Your expertise seems to be in webdesign, not in Unix and servers.
by kijin on 12/17/14, 1:17 AM
1) Client-side encryption?
2) If the answer to 1) is "yes", are the keys managed on the client-side as well?
3) What algorithms do you use for encryption and key derivation? They're not home-grown, are they?
4) Ideally, the keys that are used to manage my account on the web should be totally unrelated to the keys that are used to encrypt my backups. Otherwise it becomes trivial for the service provider to capture my password the next time I log in, and use that to decrypt my backups.
5) In order to minimize damages when a client is compromised, clients should not be able to access/restore files backed up by other clients, except with a key that is stored elsewhere.
6) For the same reason as above, clients should not be able to modify or delete files that were previously backed up, except with a key that is stored elsewhere. In other words, snapshots should be read-only.
7) Ideally, clients should not even be able to access/restore files that were previously backed up by itself, except with a key that is stored elsewhere. This prevents previous versions of files (or deleted files) from becoming exposed in case of compromise. But this is probably too much to ask of the typical backup service...
8) Filesystem permissions and other basic metadata (e.g. mtime) should be backed up and restored, too.
9) Proper and fully configurable handling of symlinks, please.
10) Your TOS, AUP, and privacy policy should be readily accessible from your home page, and customers should be notified of any changes at least a couple of weeks in advance.
My favorite solution so far is to pull backups from another machine that I control, using rsync/rsnapshot over ssh. The snapshots are then encrypted and pushed to their final resting place, such as S3, which knows nothing about the rest of my infrastructure. It's a bit of a hassle to set up correctly, but I'm in control of all the keys, a compromised client cannot access anything (restores are pushed from the server), the intermediate server can be destroyed if necessary, and the final storage provider (Amazon) cannot decrypt anything even if someone held a gun to their head.
Unfortunately, I have yet to find a one-stop backup solution that achieves the above. I'm not even sure if it would be possible without risking serious inconvenience. Tarsnap comes close, but AFAIK it makes it too easy for a compromised client to pull down everything I ever backed up.
by XERQ on 12/17/14, 12:01 AM
Current Linux backup solutions are not made for humans. Have a look at the mondorescue guide[1], nobody is going to read that and comprehend it with full mastery, meaning you're leaving yourself open to losing data. VPS providers offer backups that are usually in the same datacenter, which means you're SOL if there's a disaster. Those same providers also don't allow you to restore single files/directories from snapshots, usually you have to launch a new instance or revert everything back to snapshot.
We ended up creating a simple Linux backup solution[2] that's as simple as copying and pasting a single command to get installed, notifies you if your backups aren't running, handles snapshots, and is secure. Restoring your data is a single command away, so you can focus instead on building your startup rocketship. Our mission is to make data loss a thing of the past.
by encoderer on 12/17/14, 12:42 AM
by sjs382 on 12/17/14, 3:01 PM
Pricing that's presented like that makes me think like this:
"$20/month in large text, then $200/month hidden below that? I wonder what other details I'm missing that could cost me 10x (in time, money, security, anything else) in the long run. <close window>"
by kgtm on 12/17/14, 12:51 AM
by alrs on 12/17/14, 12:48 AM
by spitfire on 12/17/14, 12:52 AM
by fractalcat on 12/17/14, 12:30 AM