Why you'll love Dumper?
Think what you'd do when you do it yourself.


Do It Yourself

No hassle

Don't mess with cron. Control everything from the browser. Just follow the instructions on the site – we'll carefully guide you throughout the procedure. You will make the first backup in a few minutes.

Setup, install, configuration, repeat...

To take a backup, you need to install, understand and manage a slew of software, like dump tools, shell scripts for cron, logical volume managers, replication software and monitoring tools.

Automated daily backups

We take backups from your server, every day. With Dumper, Everything is fully automated. But that doesn't mean you can't take backups manually. You still can take a manual snapshot anytime.

Manual backups

Okay so you have installed everything. Now what, take a backup from phpMyAdmin or by typing a dump command? No way. We all know that's not a sustainable way of taking backups.

Daily and weekly backup slots

You will have up to four backup slots for extra peace of mind - one daily, two weekly automated backups and one manual snapshot.

today this week last week manual

Disk full

Even when you have an automated backup script, it's not done until it ensures sweeping old backups. Otherwise, take 1GB backups every day, and months later you’ll run out of disk space if you’re not managing it. It's also costly to leave stale backups – Dumper is cheaper than poorly written scripts.

Consistent data

We are database experts. We make sure your backups are safe and sound. When a catastrophic event happens on your server, restore data from Dumper and start again with the most recent data.

Corrupted data

It's so easy to create a backup that's just broken. Copy database files manually and you’ll get corrupted data. Your database won't start with those files.

Monitoring and notification

When backup fails for some reason, we send an email notification to you. That's one thing you often forget when you write your own backup scripts, but it's extremely important.

Silent failure

This is the scariest part. A false sense of security could be dangerous. There are a number of situations that could permanently halt the backup jobs. Unless you have a proper monitoring system, you'll never notice there's a problem.

Recovery from human errors

Backups are often useful to recover from operational mistakes or software bugs. Unless of course you're R2-D2 and never let bugs slip in your code.

RAID and replication aren't enough

You have RAID and replication slaves. Great. But what if you run an UPDATE command without a WHERE clause on the SQL terminal? You're totally screwed. You still need backups from the past. A read-only slave is a great target to take backups from, though.

Multiple physical locations

Don't put all your eggs in one basket. We store your backups on Amazon's famous S3, located somewhere in the United States. Oh, and S3 offers 99.999999999% durability, which is astronomical.

Filesystem snapshots are on the same host

Filesystem-level snapshots are a super handy feature on modern operating systems, and we recommend to use them whenever available. But you should know that they don't rescue you when the entire disk system is physically damaged. Not to mention natural disasters.