VPS Snaps vs cron scripts
Backup scripts fail quietly.
Most backups start as a crontab line and a pg_dump script, and some should stay that way. Here is where those scripts fail without a word, and how to move off one.
# /etc/cron.d/backup
0 2 * * * root pg_dump shop | gzip > /backups/shop-$(date +\%F).sql.gz
0 3 * * * root find /backups -name '*.sql.gz' -mtime +7 -deleteThe short version
We wrote both columns. If the left one describes you, keep your script.
Keep your script if…
Three situations where it is the better answer.
- You have one server and one database, the script uploads off the machine, and you look at the backups yourself every week. That is a working system, and nothing here is worth a subscription to you.
- You need point-in-time recovery. pgBackRest, WAL-G or Barman archive the write-ahead log and can restore to any second. We take full dumps on a schedule and cannot do that.
- You back up something we do not, such as Redis. We cover PostgreSQL, MySQL, MariaDB and MongoDB, files, Docker volumes and Kubernetes.
Switch to VPS Snaps if…
Four signs the script has become the risk.
- You have found out about a failed backup later than you would have liked. Every run here is checked as it uploads, and a failure, a run that never started, or a job overdue for a good backup each sends an alert.
- Backups live on the server they protect, or the upload to S3 was added later and old objects never get deleted. Ours go to your own bucket and are pruned to each job's window, never the newest.
- Nobody has restored one of those dumps in a year. A scheduled test restore puts the newest backup on a throwaway server on your own cloud, checks it and deletes the server.
- The scripts live on several servers in slightly different versions, and only the person who wrote them knows where. One dashboard shows every job, every run and its log to everyone in the workspace.
Five ways a script fails without telling you
Each of these is how cron and a shell pipeline behave by default. You can check every one on your own server.
- The pipe reports gzip's success
- A typical script
pg_dump shop | gzip > fileexits with gzip's status. Withoutset -o pipefail, a pg_dump that fails halfway leaves a small, valid .gz file and cron records success. - VPS SnapsEvery dump runs under pipefail, and the archive is checked as it uploads: the gzip stream must be whole and the dump must have finished.
- Cron's error mail goes nowhere
- A typical scriptCron mails a job's output only if the server can send mail. Most VPS images have no mail server, and Ubuntu's cron logs “No MTA installed, discarding output” and moves on.
- VPS SnapsFailures go to email, Slack, Microsoft Teams, Google Chat or Discord on every plan, with the step that failed and its error text.
- A job that never ran tells you nothing
- A typical scriptIf the server was off at 02:00, or the crontab was lost when it was rebuilt, there is no failure to report. The backups just stop.
- VPS SnapsA scheduled run that does not happen sends a missed-run alert, and a job that goes longer than its schedule allows without a good backup sends another.
- Retention drifts
- A typical script
find -mtime +7 -deleteprunes the local disk. Once the files also go to S3, nothing prunes the bucket unless someone adds a lifecycle rule, and a full disk stops the next dump. - VPS SnapsEach job keeps its own window, pruned in your bucket after every successful run. Only objects we wrote are touched, and never a job's newest.
- Nobody has restored one
- A typical scriptA dump that has never been restored is a hope. Restoring by hand is a job for a quiet afternoon, so it rarely happens.
- VPS SnapsRestore from the dashboard onto any server, or schedule a test restore that proves the newest backup comes back on a machine that started empty.
Moving off a script
Nothing has to be switched off until the new backups have proved themselves.
- Step 1
Connect the server
Over SSH with a key you add, or through the Agent if it has no inbound route. pg_dump, mysqldump or mongodump is already installed if your script works.
- Step 2
Create the same job
Same database, same time of day, a bucket you own. Our dump is pg_dump --clean --if-exists piped through gzip, so the archive is the same kind of file your script makes.
- Step 3
Run both for a week
Leave the crontab line in place. Compare the sizes of the two archives each night, and restore one of ours somewhere to see it come back.
- Step 4
Retire the script
Comment out the crontab line. The archives it already made stay where they are, in a format you can open without us.
The details, including what each job type needs on the server, are on the database backups and file backups pages.
Line by line
The script column is what a crontab line and a dump script do unless someone has written more.
| VPS Snaps | Cron and a script | |
|---|---|---|
| When something goes wrong | ||
| A failed dump is reported as a failure | Only with set -o pipefail | |
| Failure alerts | Email and four chat apps | Cron mail, if the server can send it |
| Alert when a backup did not run at all | ||
| Each run's log kept | Whatever the script writes | |
| Where backups go, and how long they stay | ||
| Off the server | Always, to your bucket | If the script uploads them |
| Pruned to a retention window | In the bucket, per job | find -mtime, where it can see |
| Checksum recorded for each archive | If the script records one | |
| Getting it back | ||
| Restore without typing commands | ||
| Scheduled test restores | ||
| Point-in-time recovery | With pgBackRest, WAL-G or Barman | |
| Cost | ||
| Price | Database backups from Standard; files and snapshots free for one server | Free, plus the time to keep it working |
FAQs
Can’t find the answer you’re looking for? Reach out to our support team.
Should I replace a backup script that works?
Not if it uploads off the machine, tells you when it fails, prunes what it uploads, and you have restored from it recently. That script is doing the job. The case for replacing it is the parts it does not do yet, and the time it takes to keep doing them across more servers.
Can I keep my script and still know when it fails?
Yes. Uptime monitoring on Starter and above includes heartbeat monitors: your script calls a URL when it finishes, and if the call does not arrive in time you get an alert. That catches the job that silently stopped, without moving the backup itself.
What about pgBackRest, WAL-G or Barman?
They are better than us at what they do: continuous WAL archiving and restoring a PostgreSQL database to any moment. We take full dumps on a schedule, which restore to the moment each one was taken. If you need point-in-time recovery, use one of them, and use us for everything around the database.
Which plan replaces a pg_dump script?
Standard, the first plan with database backups. File backups and provider snapshots are on every plan, Free included, so a script that tars a directory can move over on the Free plan. The pricing page has the numbers.
Do I need to install anything on the server?
No, for a server you reach over SSH: the dump runs with the client tools your script already uses. For a machine with no inbound route, the Agent is one docker run command, and it connects out to us.
What happens to the backups my script already made?
Nothing. They stay wherever the script put them. Ours are plain .sql.gz and .tar.gz files in your own bucket, so both sets can be opened without either tool.
Everything else it does
Storage, schedules, alerts, recovery and team access, in one place. Which plan each one starts on is on the pricing page.
- Bring your own storage
- Backups land in your own S3-compatible bucket — Backblaze B2, Wasabi, Cloudflare R2, or plain S3 — or in your own Google Drive. You hold the keys and the data.
- Snapshots stay with your provider
- Provider snapshots are created through the provider's own API and never leave your account. We store the snapshot ID, not the image.
- Eight providers, one dashboard
- DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Google Compute Engine and Microsoft Azure — scheduled and reviewed from the same place.
- A replacement server on demand
- Recover now builds a new server on your own DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine account, from its snapshot or from its backups, software included.
- Failover on any cloud
- When a server stops answering, its traffic moves to the recovery server: by reserved or floating IP where your cloud has one, or by your DNS on Cloudflare, which works on every cloud.
- Know it's down, with the way back
- Uptime monitors for sites, ports and scheduled jobs confirm an outage before alerting, name the server's newest backup, and publish a status page. On paid plans.
- Your DNS zones, backed up
- Every record in a Cloudflare zone, kept in your own storage as a BIND file too. A restore previews what differs and writes back only that.
- Schedules that fit your traffic
- Hourly, daily, weekly, monthly, or a fixed interval in minutes — anchored to your timezone, so a 02:00 job stays at 02:00 across a DST change.
- Retention that prunes itself
- Set how many days to keep. Older snapshots and archives are cleaned up after each successful run, so storage bills stay flat.
- Every run on record
- Status, duration, size and trigger, with each step it took in order and its warnings and errors kept in place — so a failure tells you which step broke.
- Checksummed on upload
- Every archive is hashed as it streams to your bucket and the checksum is stored with the run, so you can verify what landed.
- Run on demand
- Trigger any job by hand before a migration or a risky deploy, without touching its schedule or its retention window.
- Alerts on five channels
- Email plus Slack, Microsoft Teams, Google Chat, and Discord — on success, on failure, and on a job that missed its schedule entirely.
- Encrypted credentials
- SSH keys, database passwords, and storage secrets are sealed with AES-256-GCM before they touch the database.
- Team access with roles
- Invite your team into a shared workspace as owner, admin, or member, so backups outlive whoever set them up.
“We manage a mix of VPS instances, Docker workloads, and traditional Linux servers, so backups used to be scattered across several different processes. VPS Snaps brought all of that into one dashboard and made it much easier to see what ran, what failed, and what needs attention.”
Run it next to your script for a week.
Database backups start on Standard; files and provider snapshots are on the Free plan, with no card. Leave the crontab line where it is until ours has earned the job.
No credit card required. Cancel anytime.