What backup setup includes
You can start with what matters most, usually the database, and add the rest later.
Databases
A database changes every second and has to be backed up with its own tools, not by copying files.
- ✓PostgreSQL: dumps and continuous log archiving
- ✓MySQL and MariaDB
- ✓point-in-time recovery
- ✓Redis and ClickHouse if they hold important data
Files and servers
User uploads, configuration, certificates.
- ✓restic: deduplication and encryption
- ✓only changes are sent after the first copy
- ✓cache and temporary files excluded
- ✓server configuration in Git as an extra safety net
Storage
A backup on the same server as the data will be lost along with it.
- ✓S3 at another provider or in another region
- ✓encryption before upload
- ✓versioning and separate access keys
- ✓retention: days, weeks, months
Schedule
Frequency depends on how much data you can afford to lose.
- ✓database: from continuous archiving to once a day
- ✓files: daily or more often
- ✓old copies pruned by rules
- ✓runs at low-traffic hours
Restore testing
A copy nobody has tried to restore is a hope, not a backup.
- ✓automatic restore to a test server
- ✓a check that the data is readable and complete
- ✓restore time measured
- ✓a report on every test
Alerts
Backups often break silently: the disk filled up, a password changed, a key expired.
- ✓an alert when a backup didn't run
- ✓size tracking: a sudden change is worth a look
- ✓free space in the storage
- ✓Telegram notifications
Ransomware protection
Whoever gets into the server shouldn't get into the backups.
- ✓storage with time-based deletion lock
- ✓write-only keys without delete rights
- ✓a copy at another provider
- ✓an alert on mass deletion
Recovery plan
When the server is down, there's no time to figure out commands.
- ✓a step-by-step runbook for your project
- ✓who restores what, and in which order
- ✓a target recovery time
- ✓a practice restore following the runbook
Backup setup pricing
The cost depends on the number of servers and databases. I give an estimate in hours before starting. Storage is paid to the provider separately.
| Format | Price | What's included |
|---|---|---|
| Backup audit | from $230 | what is backed up, where it's stored, whether it restores; a test restore and a report |
| Setup | $35/hour | database and file backups, storage, encryption, restore testing, alerts |
| Support | $250/month | watching backups and restore tests, responding to failures |
Example estimates
| Task | Estimate |
|---|---|
| Backups of one PostgreSQL database to S3 with alerts | 2-4 hours |
| Server file backup with restic and encryption | 2-3 hours |
| Automated restore testing on a test server | 3-6 hours |
| Recovery plan and a practice restore | 3-5 hours |
How the setup goes
- 1
What can't be lost
We define the data and the acceptable loss: how many hours of work you can afford to lose and how fast you need to recover.
- 2
Checking current backups
If backups exist, I try to restore from them. Often it's the first restore ever.
- 3
Setup
Schedule, storage, encryption and retention to match your requirements.
- 4
Test restore
I restore the data on a test server and measure the time.
- 5
Monitoring
I add alerts and automated restore testing and hand over the runbook.
What teams come with
There was a backup, but the restore failed
The copy turned out empty, incomplete or without the encryption key. People find out on the day of the incident.
Backups are on the same server
The server was deleted or encrypted, and the copies went with it.
The hosting provider does the backups
A daily snapshot with no testing, and a database in a snapshot of a running server may not start.
Data was deleted by mistake
You need yesterday evening's copy, but only the latest one is kept, already without that data.
The 3-2-1 rule
The classic rule of reliable backups:
- 3 copies of the data: the live one and two backups;
- 2 different media or storage systems;
- 1 copy off-site: at another provider or in another region.
For a small project it looks like this: the live database on the server, a daily backup to S3 in the same cloud and a weekly copy at another provider. These days people often add a copy that can't be changed or deleted, in case of ransomware.
How to check that a backup works
A minimal check worth doing at least once a month:
- Find the latest backup and check its date:
restic snapshotsor the file list in the storage. - Restore it to a separate server, not over the live data.
- For PostgreSQL, restore the dump into an empty database with
pg_restoreand compare row counts in key tables. - Start the application on the restored data and check login and the main pages.
- Write down how long it took: that is your real recovery time.
If something went wrong at any step, it's good that you found out now and not during an incident.
Technologies
- Tools
- resticpg_dumpmysqldump
- Databases
- PostgreSQLMySQLRedisClickHouse
- Storage
- S3AWS S3Hetzner Object Storage
- Monitoring
- PrometheusGrafanaTelegram
Case studies
IPTV service: the server can be rebuilt
Configuration and data lived only on the servers themselves, with no copies.
Set up daily backups to external storage and described the configuration in Ansible: the server is rebuilt from code and the latest data copy.
Mobile app: backups that are tested
The app's data had to be protected so that a restore wouldn't come as a surprise.
Set up S3 backups with regular restore tests and Telegram alerts.
Why work with me
I test restores
I consider a backup working only after a successful restore from it.
Your data stays yours
The storage and encryption keys are in your name. I don't keep your data.
No expensive licenses
restic and the databases' built-in tools are free. You pay only for storage space.
I know what the app needs
As a former developer, I understand which data must not be lost and which regenerates on its own.
Frequently asked questions
How much does backup setup cost? +
Backups of one PostgreSQL database to S3 with alerts take 2-4 hours at $35/hour. An audit of existing backups with a test restore starts at $230. Storage is paid to the provider separately.
How often should backups run? +
As often as the amount of data you can afford to lose. If losing a day of work is unacceptable, the database is archived continuously or hourly; files are usually backed up daily.
How long should backups be kept? +
A common scheme: daily copies for a week, weekly for a month, monthly for a year. The periods depend on your business and data retention requirements.
Are the hosting provider's backups enough? +
As an extra layer, yes; as the only copy, no: they are stored at the same provider, rarely tested, and a database in a snapshot of a running server may not start.
Where should backups be stored? +
In S3-compatible storage at another provider, or at least in another region. 100 GB in such storage costs a few dollars a month.
Can a database be restored to a specific moment? +
Yes, for PostgreSQL and MySQL this is done with continuous log archiving: the database can be brought back to the minute before an accidental deletion.
Send a request
Tell me what data you have, where it lives and how backups are made today. I'll say whether you can restore from them and what to add.