Show HN: Simple Linux Backups
jarvys.io
jarvys.io
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.
If the main concern of this post is pricing: our service isn't the cheapest, nor do we want it to be. We want JARVYS to provide the most value and peace of mind to our customers. It allows us to focus on delivering quality instead of searching for the next buck. Is the loss of your data worth the money you'd be saving from choosing one providing over another?
We actually called up iDrive to learn more about their Linux product and to ask them for help installing it, and their response was to read the documentation. Linux felt almost like an afterthought with them, with their core product being Mac and Windows. Instead of us half-way supporting Windows, Mac, Linux, and everything else, we want to be the best Linux backup service available and to focus solely on it.
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.
I'd rank "not doing backups" pretty highly in terms of having misplaced faith in things not breaking, too.
I don't ask new Tarsnap users why they decided to start using it, but sometimes they volunteer the information; and by far the most common reason I hear is "I just lost all of my data, so I decided it was time to start doing backups". I am frustrated every time I see this...
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.
Jarvys.io just launched, and their marketing site is geared toward features/benefits and not bogged down with technical details. In fact, a landing page that answers all your questions would be poor and missing the point of marketing. When dropbox launched did they go into the technical details of how it worked?
"...a strong feeling you are not qualified to run a service like this".
But this is a product that targets Linux novices and asks them to upload all their data under a hand-wavy promise of protection.
There should be a tad more explanation on how privacy is ensured and how the actual protection works, no?
For that kind of stuff, I want neckbeards that can install linux on a dead badger.
The same reason why you wouldn't want to have your surgeon be a guy that manufactures scalpels.
This is supposed to send, receive and store data for LONG periods of time without any accidents. It's "boring". Just as boring as safety belts and breaks on elevators, but just as important.
> No word on encryption.
We encrypt data in motion, but not at rest (yet). Since this is a beta product we wanted to get it out there first with a free version that would bring the barrier down and allow us to learn as much from users as possible.
> No word on what is actually backed up, how to include or exclude files.
By default it backs up everything except /proc and /sys, which you can change here (with detailed instructions): /var/jarvys/etc/include
> No word on when anything is backed up and how (cronjob, daemon?).
It's a cronjob that checks in with our servers every hour and backs up once a day. The reason it's not a daemon is because daemons die, and we needed something as bulletproof as possible. Checking in every hour allows us to tell you when your server hasn't been checking in (which means you can proactively see if your cron daemon is broken or if something else went wrong before it affects your backups).
> No word on how running services and databases are backed up that may need special procedures for a consistent snapshot.
We include a special script that allows you to run things like mysqldump before the servers back up to JARVYS: /var/jarvys/etc/run-before-backup.sh
> No word on how to restore or access backups when the backed up host has failed.
That's also included in here[0] - that feature is still in testing and hasn't been released yet.
> 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.
Another backup concern you didn't mention is bit rot, which we're using ZFS to mitigate.
Thank you for your kind words regarding our website, our designer actually wrote a detailed blog post on how they came up with the logo[1]. We've been providing managed backup services (among other managed services) for our SSD Nodes[2] clients, which is for whom we originally built this service.
[0] https://my.jarvys.io/docs/home [1] https://blog.jarvys.io/2014/11/04/the-jarvys-logo-design/ [2] https://www.ssdnodes.com
What does this even mean? When is data in motion or at rest? I hope your servers never see a single unencrypted byte. Just imagine lots of services using your backup system. That will make you a very very valuable target for hacking. You don't need to hack N services anymore, you only need to hack one.
Also what encryption algorithms are used? What key lengths? How are the keys generated?
And even if you do proper encryption, how can the authenticity of your software be verified? What if you where hacked and the hacker manipulated your software and thus installs back doors on all your customers through your software install/update method? Can a customer see the source of what is running on their server?
> By default it backs up everything except /proc and /sys
I guess you don't include the encryption keys in the backup, so there has to be something more excluded. Also what about /tmp?
I can't see much in the way of details so I figured you might be able to help
- How do you ensure consistency of the disk for the snapshot? (i.e. the time it takes to walk the filesystem and files have changed)
- How do you verify the file is captured in its entirety?
- How do you know a file has changed?
- Do you de-duplicate the storage?
- What filesystems / attributes do you support / don't support?
- Do you support bare metal restoration?
- Do you transfer the Delta or complete copy of changed files?
So I read it as meaning that data is not encrypted at all on disk (i.e. no privacy). This does render the service useless for, not all, but many use-cases.
>> No word on how to restore or access backups when the backed up host has failed. > That's also included in here[0] - that feature is still in testing and hasn't been released yet.
I hope you're kidding :-)
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.
If I were really paranoid, I'd still be a little worried about possible information leakage via the local cache, which seems to be necessary for deduplication to work, especially without being able to read previous archives. But I don't have enough money to buy that much tinfoil :)
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.
It's certainly not point-and-click or paste-and-run, but it's free and allows you to keep data in house, which for 'hosted' backup solutions is always a great concern of mine. Many hacks in the past I've read about were from the backup situation that people had implemented (and was used as a backdoor in one way or another, be it via code/key leakage or simply allowing connections from the backup solution).
You're far from the only one using HN to advertise your business, but maybe you should try to mix it up a little.
18 days ago was in November. Did a client call you a 3 am in October and also in November?
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>"
We try to keep it as clear and concise as possible by showing the pricing you get with the promo + the normal pricing after that.
It's more the other way around - I created scrypt because I wanted it for Tarsnap. :-)