Show HN: Simple Linux Backups(jarvys.io)
jarvys.io
Show HN: Simple Linux Backups
https://jarvys.io
11 comments
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.
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.
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...
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...
I check/test my backup setup on World Backup day aka March 31st.
http://worldbackupday.com
http://worldbackupday.com
No word on encryption.
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.
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?
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".
I would agree if this was yet another Todo-List app.
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?
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?
While I don't necessarily question their ability to run the service, I think backups are one of those things where you DON'T want designers, leaders or hustlers trying to market a product rather than having a solid engineering base.
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.
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.
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.
[0] https://my.jarvys.io/docs/home [1] https://blog.jarvys.io/2014/11/04/the-jarvys-logo-design/ [2] https://www.ssdnodes.com
> 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
> 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.
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 :-)
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 :-)
> We encrypt data in motion, but not at rest (yet).
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?
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 am assuming by encryption in motion you are talking about using SSL tunnels to transfer the data.
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?
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?
Some of those are answered here: https://my.jarvys.io/docs/home
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.
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?
That looks great! I should really stop relying on the human-friendly documentation and dig into the manpages where all the gems are.
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 :)
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 :)
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.
[1] http://www.mondorescue.org/docs/mondorescue-howto.html
[2] https://jarvys.io
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
This comment is identical to your comment from 18 days ago:
https://news.ycombinator.com/item?id=8670717
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?
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?
Out of curiosity, do you have an automated system that checks for duplicate comments? Did you just happen to read it before and remember it?
I also read through the comment thinking.. deja vu?
But yeah it was a copy paste from three weeks ago.
No automation. I had a feeling I'd read it before, so I checked the profile.
Honestly didn't expect this submission to go anywhere, and only had a minute before jumping on a call :-)
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).
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).
I think if you provide enough features to be the only backup solution a business needs for their server, $20/mo is too cheap. Just my 0.02.
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>"
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.
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.
I understand. The way it was presented seemed deceptive though. Hope that feedback is useful.
Upvoted. For those that prefer getting their hands dirty (but not too dirty), duplicity and S3 might be a good alternative. It's really simple to get up and running: http://kappataumu.com/articles/cloud-backups-duplicity-s3.ht...
I much prefer attic: https://attic-backup.org/
And here's an attic wrapper script I wrote that makes it easy to use: https://torsion.org/atticmatic/
That's very useful, thanks!
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."
Is this just a long way of saying that you shouldn't execute code, downloaded using curl, like this?
Heroku is one of the offenders, but you're absolutely right and I went ahead and fixed it.
I am quite jealous of everyone else's bootstrap skills.
Wish I could pull something even half that quality together.
What's "enterprise security"? Is it like regular security? Does it involve client-side encryption?
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.
from the inventor of scrypt
It's more the other way around - I created scrypt because I wanted it for Tarsnap. :-)
It's more the other way around - I created scrypt because I wanted it for Tarsnap. :-)
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.