We operate out of several datacenters, the servers for this deal are located in Montreal, Canada. We don't have EU servers yet, but are planning in expansion.
Across the company we use all of them, because our enterprise clients all have different needs. For this deal we use OpenVZ, with our own proprietary workload balancing algorithm that migrates containers so that each gets optimal performance.
No problem. We actually ran a sale a few weeks ago at LowEndBox and added several hundred customers for our OpenVZ offerings, so I would point at the numbers as proof :-)
Not quite a SaaS company, but I'll chime in anyway. For SSD Nodes we've done "trials" for enterprises with an explicit expiration date where the service gets disabled if we don't receive their payment. This tightens our AR and incentivizes them to push the payment through their channels faster.
Sometimes a dev from a large company will test us on a smaller package with a company credit card and expand from there after we push them through the sales funnel.
Most of our enterprise clients pay using either ACH or check, while the remaining typically use credit cards.
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.
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.
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.
> 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?
> 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'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).
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.
[plug] 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. [/plug]
I have a Redmine install that I want to backup. It uses both a database and the file system. If I attach a file to an issue, the attachment is stored on the FS with a reference in the DB.
I don't know how Redmine deals with keeping the FS vs the DB consistent, but assume it uses some type of transaction across both when an attachment is added.
How do you back that up without possibly getting the FS and the DB out of sync. Ex: What if you snapshot the FS right after an attachment is written, but before the reference is added to the DB? The transaction in the app will succeed, but your backup is inconsistent compared to what the app expects.
How can you get a truly consistent backup without either a) stopping the app or b) integrating with the app to make sure you're not breaking assumptions needed for consistency?
Basically, almost every backup solution I've ever seen is crash consistent at best. How is yours different?
I've been struggling with this myself in various cases. The conclusion I've come down to, is that the app has to take some responsibility to provide for consistent backups, either via checkpoints / write barriers, or via a quiesce command that can finalize in-flight transactions, and pause / buffer operations long enough for a volume snapshot to take place. The other thing I've seen apps do is provide a data export functionality, so you end up backing up the export file not the live data. But that requires extra time and disk space. Another option is to run the app in a VM, and do a live VM snapshot which includes the running state of the VM.
Bottom line is if you can't live backup your app, file a bug report with the app vendor. Although it would be really nice if there were standards in this area, so that a backup tool would just need to call one operation to put all supported apps into a hot-backup mode.
This is why I prefer to have objects in the DB if they are not too large or numerous for that to be practical, that way the transactional integrity of the DB and its backup handles this. Unfortunately it is not always practical or under your control.
From a developers PoV you can increase the consistency of your users backups by being careful how you order operations. If you make sure the DB is updated after the file is in place and tell the app administrators to backup the database first, and your blobs are insert-and-soft-delete only (you can do updates in an insert & soft delete only way with versioning instead of in-place updates). That way you are never in a position where you have a missing blob, though you might end up with orphans where inserts happen during the time the backup took to run.
Other than that, as you say, you have to stop the app or the app has to have built in support for consistent backups (or integration into your chosen solution).
To minimise the downtime associated with this you can use tricks like LVM snapshots or your OS's equivalent. That way the downtime is only as long as it takes to stop the app, take the snapshot, and restart the app, instead of the full length of time it takes to make the backup (which could be a fairly long time if it involves a full backup of a large DB), and it means you can coordinate the backups of apps that are integrated (or just used in sync) but not in a transactionally safe way, without having to stop them all for the full backup run.
That is the best you can do without explicit support in the app - there is only so much a backup solution can be in control of.
Our core value is around the simplicity of use, so instead of having to read a novel of a manual written by a crusty UNIX sysadmin, along with combining it with storage, you can create an account and copy-and-paste a single command that does all the work for you. We've even tested it with people who've never used Linux before and they were able to install it and restore a file without much direction.
With that said, we do provide the ability to hook your own scripts and commands into the backup process itself, for instance backing up MySQL you'd just put in the mysqldump command (with relevant DB and user/pass info) into the hook script uncleverly titlted 'run-before-backup.sh' in the config directory.
I personally don't have any experience with Redmine. Application-specific backups are outside the scope of our initial launch, but as we get more user feedback we'll be able to build plugins that integrate with specific applications. In the mean time, I'd both: 1) pester the developers to provide a simple backup solution for Redmine, and 2) look into either putting it on a VM that you can snapshot, or use something like ZFS snapshots and send/receive it to a remote location.
This is a beta product, and we put that up on the docs so people can understand in its current state what it's capable of and what it isn't. One thing we didn't put in the docs is that we can change the target of a new system to an old server's backup. So in the case of your server going up in smoke, you would simply open a uservoice ticket (or email me using my profile info), fire up a new server installed with JARVYS (disabling the cronjob until you're restored), and we'd change the target UUID to that of the new server, allowing you to restore from your old backups.
Soon we will have it where you can simply select any other server from your account to restore from it to any other server on your account, and the docs will be updated with how to do it.
> 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.
Meaning that they didn't have a QA process in place before putting things in production, or that "dev" is also "production"?
That's surprisingly common for "internal" applications. And quite frankly, the type of dev that screws everything up like that is also the type of dev that doesn't know any better, doesn't version things, doesn't have an issue tracker and doesn't set up DB backups, etc., etc.
That's an institutional failure in this case. I certainly wouldn't expect a dev to setup backups for the company database, for instance. A VCS and issue tracker should be a company-wide (or at least department-wide) thing, not something you setup (or not) from project to project.
https://www.ssdnodes.com/hn/
* You can upgrade with zero downtime to a larger server (it will live resize)
* 100% uptime SLA
* Fastest SSDs (we've achieved over 200K write IOPS and 1GB/s writes)
* Direct support from engineers
* Bitcoin payments accepted
* 7-day no-hassle refund guarantee
/plug