Every Fast Hive VPS plan includes daily backup, with nightly images kept off-server plus manual snapshots you take before risky changes. That is a strong safety net - but a disk image is a blunt instrument, and it is not the whole answer. This guide explains what each layer protects against, what it does not, and how to build a routine you can actually restore from.
- Nightly images (automatic, off-server) - the server dies, or you break it beyond repair.
- Manual snapshots (before changes) - an upgrade goes wrong and you want the previous state back in minutes.
- Your own dumps (files and database) - you need one table, or last Tuesday's uploads, without rolling back the whole machine.
Why images alone are not enough
Restoring a disk image takes the entire server back to a point in time. That is exactly right when the server is unrecoverable. It is a poor fit for the far more common situations:
- A bad migration corrupted one table - a full restore would also discard every order taken since.
- Someone deleted a directory of uploads - you need those files, not yesterday's operating system.
- You want to move the site to a different server - an image of a 100 GB disk is an awkward way to carry a 2 GB site.
- You want to check the backup is good - verifying an image means actually restoring it somewhere.
Application-level dumps solve all four, and they are small enough to keep several generations of.
Backing up databases
# One database
mysqldump --single-transaction --quick --routines --triggers \
-u backup -p mysite | gzip > /var/backups/mysite-$(date +%F).sql.gz
# Everything
mysqldump --single-transaction --quick --all-databases \
-u backup -p | gzip > /var/backups/all-$(date +%F).sql.gz
# PostgreSQL
pg_dump -Fc mysite > /var/backups/mysite-$(date +%F).dump--single-transaction matters: it takes a consistent snapshot without locking the tables, so the site keeps working while the dump runs.
ps can read it, and it lands in your shell history. Create ~/.my.cnf with chmod 600 instead:
[client]
user=backup
password=your-passwordBacking up files
# Web root and key configuration
tar -czf /var/backups/site-$(date +%F).tar.gz \
/var/www /etc/nginx /etc/letsencrypt
# Or mirror to another machine
rsync -az --delete /var/www/ backup@elsewhere:/backups/www/Worth including beyond the obvious: /etc/nginx, /etc/letsencrypt, crontabs (crontab -l), and a list of installed packages. Those are what turn "I have the data" into "I can rebuild this server".
# Debian/Ubuntu
dpkg --get-selections > /var/backups/packages.txt
# AlmaLinux/Rocky
rpm -qa > /var/backups/packages.txtGetting backups off the server
A backup stored only on the server it protects is not a backup. The nightly images are already held off-server; your own dumps are not, until you move them.
# Pull from a machine you control (preferred - the VPS holds no
# credentials for the backup destination)
rsync -az vpsuser@your.vps.ip:/var/backups/ /local/backups/vps/Automating it
Put the commands in a script, make it executable, and schedule it:
sudo crontab -e
# Nightly at 03:17 - avoid the top of the hour
17 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
# Delete local copies older than 14 days
30 4 * * * find /var/backups -name "*.gz" -mtime +14 -deleteThe second line is not optional. A backup job with no retention policy fills the disk, and a full disk takes the site down - a backup that causes the outage it was meant to protect against.
Check it is actually running
ls -lh /var/backups/ | tail
tail -20 /var/log/backup.logA silent cron job that has failed for three months looks exactly like one that is working. Check the file dates monthly.
Restoring
A database
gunzip < /var/backups/mysite-2026-08-20.sql.gz | mysql -u root -p mysiteFiles
# Look inside first
tar -tzf /var/backups/site-2026-08-20.tar.gz | head
# Extract one path, not the whole archive
tar -xzf /var/backups/site-2026-08-20.tar.gz -C /tmp/restore var/www/example.comExtract to a temporary directory and inspect before overwriting anything live. Restoring straight over a working site is how a recoverable problem becomes two problems.
A whole server
Restore the nightly image or a snapshot from the client area. Everything written since that point is lost, so copy off anything current you still need first.
Test a restore, twice a year
This is the step that separates a backup strategy from a backup hope. Deploy a temporary VPS - hourly billing makes this cost very little - restore into it, and confirm the site actually runs. Then destroy it.
What this catches: dumps that were empty, archives missing a directory, a database user that no longer exists, a certificate that was never included, and instructions that only made sense to the person who wrote them.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| Backup file is a few hundred bytes | The dump failed and only wrote an error. Check the log - usually wrong credentials or missing privileges. |
| Disk filled up overnight | No retention policy. Add the find -mtime +14 -delete job. |
| Restored database is missing recent rows | The dump predates them. This is why nightly is a floor, not a target, for a busy site. |
| Site restored but shows a database error | The database user was not recreated. Users live outside the individual database dump - recreate and re-grant. |
| HTTPS broken after restore | /etc/letsencrypt was not in the archive. Re-run certbot - and add it to the backup. |
| Cron backup stopped silently | Output was discarded with 2>&1 to /dev/null. Log to a file instead so failures leave evidence. |
| Backups deleted along with the server in an attack | They were reachable from the VPS. Switch to a pull model, and rely on the off-server nightly images. |
Frequently asked questions
Is the included daily backup enough on its own?
For "the server is gone", yes - nightly images are kept off-server. For "restore one table from Tuesday", no. Add your own dumps.
How long are nightly images kept?
Retention is finite, so the sooner you notice a problem the more options exist. Ask Technical Support immediately rather than after the weekend.
Does a snapshot pause my server?
Snapshots are quick and generally non-disruptive. For a database, stopping the service or taking a dump first gives a cleaner, guaranteed-consistent copy.
How often should I back up?
Ask what you can afford to lose. A brochure site is fine on nightly. A shop taking orders hourly should dump the database far more often - the interval is your worst-case data loss.
Can Fast Hive restore a nightly image for me?
Yes. Open a ticket with Technical Support naming the server and the date and time you want. Say explicitly whether current data may be overwritten.
What happens to backups if I cancel the VPS?
They go with the service. Take a full copy off-platform before cancelling - there is no recovery afterwards.
