
Show HN: Simple Linux Backups - XERQ
https://jarvys.io
======
Animats
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](https://www.linkedin.com/profile/view?id=166917144)
and has another business, "Xerq.io". It's a social network (at
[https://xerq.io/hotness](https://xerq.io/hotness)) which has a big banner ad
for Jarvys.

There are terms of service
([https://my.jarvys.io/JARVYS_TOS.pdf](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
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.

------
vinceguidry
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.

~~~
cperciva
_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...

~~~
StavrosK
"To be precise, the time to start doing backups was immediately _before_ you
lost all your data", huh...

~~~
cperciva
I usually say two weeks, but yes. Immediately after you've lost all your data,
you don't really have anything worth backing up any more...

------
moe
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.

~~~
XERQ
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](https://my.jarvys.io/docs/home) [1]
[https://blog.jarvys.io/2014/11/04/the-jarvys-logo-
design/](https://blog.jarvys.io/2014/11/04/the-jarvys-logo-design/) [2]
[https://www.ssdnodes.com](https://www.ssdnodes.com)

~~~
panzi
> 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?

------
kijin
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.

~~~
cperciva
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?

~~~
kijin
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 :)

------
XERQ
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](http://www.mondorescue.org/docs/mondorescue-howto.html)

[2] [https://jarvys.io](https://jarvys.io)

~~~
leephillips
This comment is identical to your comment from 18 days ago:
[https://news.ycombinator.com/item?id=8670717](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?

~~~
virmundi
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?

~~~
otoburb
The third and most likely option is looking up the poster's HN profile and
checking out historical comments made by the poster.

~~~
virmundi
I guess the idea of looking a person's profile is foreign to me. Perhaps I
should get into the flow of doing that.

------
encoderer
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.

------
sjs382
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>"

~~~
XERQ
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.

~~~
sjs382
I understand. The way it was presented _seemed_ deceptive though. Hope that
feedback is useful.

------
kgtm
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...](http://kappataumu.com/articles/cloud-backups-
duplicity-s3.html)

~~~
StavrosK
I much prefer attic: [https://attic-backup.org/](https://attic-backup.org/)

~~~
witten
And here's an attic wrapper script I wrote that makes it easy to use:
[https://torsion.org/atticmatic/](https://torsion.org/atticmatic/)

~~~
StavrosK
That's very useful, thanks!

------
alrs
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."

~~~
Skywing
Is this just a long way of saying that you shouldn't execute code, downloaded
using curl, like this?

~~~
girvo
Yes, but in a way that makes the person saying it feel superior to others.

~~~
alrs
My beef isn't with the people who don't know they don't know, it's with
vendors that encourage this. It makes the vendor look like amateur hour.

------
spitfire
I am quite jealous of everyone else's bootstrap skills. Wish I could pull
something even half that quality together.

------
fractalcat
What's "enterprise security"? Is it like regular security? Does it involve
client-side encryption?

~~~
ultramancool
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.

~~~
cperciva
_from the inventor of scrypt_

It's more the other way around - I created scrypt because I wanted it for
Tarsnap. :-)

