Backups are good. Backups are important. But who are these guys who want you to trust them with your data?
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.
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.
I happen to be Matt Connor :-) My username also happens to be "XERQ," and my profile lists SSD Nodes, JARVYS, and XERQ. I'm transparent when it comes to the projects I'm a part of, if that's a concern.
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.
Ha. Nothing to say about Jarvys, so completely unrelated but your comment reminds me of a friend from highschool (this is in Europe) who I lost contact with and then reconnected with years later. Asked him "So, what do you do?". Him: "Well I do business". Me: "What do you mean, business?". Him: "You know, everything, party balloons, renting apartments, writing fake visa aplications for people, computer repair [+ a few others]".
Backups are this thing that lots of people buy but nobody tests. People seem to refuse, every single time, to understand that if you're hoping your backup system will protect you from catastrophic failure, until you've actually tested your production servers by making them fail catastrophically and then restoring from your backup, then you what you bought was an expensive wish.
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.
Nothing says "Faith-based engineering" like buying a backup system you refuse to test.
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.
Your comments are exactly what peeve me about developer entitlement and ego's. I'd be curious if you've ever tried to run a business?
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".
That really rubs me the wrong way. What do you know? Perhaps their development skills may not be the best, but if you look around at successful startups, usually the founders have a more rounded skill set other than being a pure hacker. They are designers, they are leaders, they hustle...
It's built by the SSD Nodes people (https://www.ssdnodes.com/). I too would like to see more technical details on the site, but there's probably a better way to frame the criticism than "u r idiots".
Hi there and thank you for taking the time to look into JARVYS. I'd happily go through and answer your questions. Some of them are answered here[0]
> 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.
There are several questions that I need to ask anyone who claims to provide backups as a service (Baas?):
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.
The tarsnap-keymgmt utility allows you to create a key file which can be used to create backups but can't read or delete them. I think this satisfies the concern you mention at the end?
I've seen many of my clients set up their own backup systems and have those fail at the worst times. Last month a large client of ours called our managed support team at 3AM saying they hired the wrong developer who completely trashed their database and hosed their entire application. They had their own backup system in place and it silently failed, but luckily they ordered our internal backup solution as a secondary. We were able to get them restored in 5 minutes, if they didn't have our solution in place they would've had to spend weeks fixing what the developer broke.
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.
You built a beautiful site, but I wish you provided a little more technical information. For the Linux market, you can probably wade fully into the details of how the backups work (rsync, something else?), whether the client process is going to want root (I would assume so), how the "secure" part of your service works, etc. Or maybe it's there and I'm too dumb to find it. :-)
Not trying to imply that it is trivial to set up a reliable backup and restore mechanism, but the link you provide hardly provides an example of the current state. Never heard of modoresque, but the documentation has not been updated since 2006.
I've never heard of Mondo, but there are well maintained and widely used backup projects such as Bacula (http://www.bacula.org).
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).
The pricing page is deceptive enough to make me reconsider trusting them.
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>"
I apologize if there was any confusion. We're running a holiday promo, which is written above the pricing table: "Get 14 days free + 90% off for 3 months during the holidays!"
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.
Any product that wants you to pipe some crap from curl is communicating "our product is for all of the Windows people who bought Macs in the last couple of years and are still playing pretend when it comes to administering a Linux box."
Not sure, but if you want real security and dead simple backups on Linux, check out Tarsnap. From the inventor of scrypt. Full client-side encryption with very strong key derivation.
[+] [-] Animats|11 years ago|reply
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.
[+] [-] XERQ|11 years ago|reply
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.
[+] [-] rdtsc|11 years ago|reply
[+] [-] vinceguidry|11 years ago|reply
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.
[+] [-] cperciva|11 years ago|reply
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...
[+] [-] 2bluesc|11 years ago|reply
http://worldbackupday.com
[+] [-] moe|11 years ago|reply
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.
[+] [-] nodesocket|11 years ago|reply
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?
That really rubs me the wrong way. What do you know? Perhaps their development skills may not be the best, but if you look around at successful startups, usually the founders have a more rounded skill set other than being a pure hacker. They are designers, they are leaders, they hustle...[+] [-] thaumaturgy|11 years ago|reply
[+] [-] XERQ|11 years ago|reply
> 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
[+] [-] vld|11 years ago|reply
[+] [-] kijin|11 years ago|reply
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.
[+] [-] cperciva|11 years ago|reply
[+] [-] XERQ|11 years ago|reply
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.
[1] http://www.mondorescue.org/docs/mondorescue-howto.html
[2] https://jarvys.io
[+] [-] leephillips|11 years ago|reply
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?
[+] [-] thaumaturgy|11 years ago|reply
[+] [-] joepvd|11 years ago|reply
[+] [-] druiid|11 years ago|reply
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).
[+] [-] encoderer|11 years ago|reply
[+] [-] sjs382|11 years ago|reply
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>"
[+] [-] XERQ|11 years ago|reply
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.
[+] [-] kgtm|11 years ago|reply
[+] [-] StavrosK|11 years ago|reply
[+] [-] alrs|11 years ago|reply
[+] [-] Skywing|11 years ago|reply
[+] [-] XERQ|11 years ago|reply
[+] [-] spitfire|11 years ago|reply
[+] [-] fractalcat|11 years ago|reply
[+] [-] ultramancool|11 years ago|reply