Database backup with tested recovery
A backup only counts once it can be restored, within the time your business can bear. Sortia Labs sets up backups for PostgreSQL, MySQL, MariaDB, Oracle and SQL Server, keeps an encrypted copy off site and practises the restore regularly, so that it is routine when it matters.
- Database backup
- Point-in-time recovery
- Restore testing
- Backup strategy
- Object Lock
- RPO and RTO
- DatabaseRunning system
- Regular backupFull and incremental
- Second placeAnother provider
- EncryptedWith a retention lock
- RestorePractised regularly
What a dependable backup includes
A backup plan that fits
Full backups, differential or incremental backups and continuously archived transaction logs (WAL for PostgreSQL, the binary log for MySQL and MariaDB). How often you back up depends on how much data loss you can bear.
Back to a specific minute
An accidental DELETE at 14:03? With archived logs the database can be brought back to its state at 14:02, first as a copy if you like, from which you recover only the lost rows.
A copy off site
A backup on the same server is lost together with the server. An encrypted copy belongs with a second provider or at a second site, separate from the production system and its credentials.
Protection against deletion by attackers
Attackers who encrypt servers go for the backups first. A retention lock (Object Lock) is designed so that backups can be neither deleted nor overwritten before the period ends, even with stolen credentials.
Practising the restore
Automated tests regularly restore backups into an empty environment and use known records to check whether everything has arrived. On top of that we recommend an exercise with your team following a written emergency plan.
Retention and deletion periods
How long backups are kept follows from your obligations: retention for audits, but also deletion of personal data with GDPR in mind. We document periods and responsibilities.
How your backup concept takes shape
- 1
Clarify the goals
How many minutes of data may be lost, and how quickly must the system run again? These two answers (RPO and RTO) determine frequency, storage location and method.
- 2
Set up
Backups, log archiving and an encrypted copy at a second provider, with an alert whenever a backup is missing or fails.
- 3
Verify
Test restores measure how long recovery really takes. The result goes into the emergency handbook, together with the steps for your team.
Software we build and run ourselves.
Questions about Backup and recovery
Is a virtual machine snapshot enough as a backup?
On its own, usually not. A snapshot shows the database as it would be after a sudden power cut, often sits on the same storage as the original and cannot take you back to a specific minute. It is a useful addition, but it does not replace a backup made through the database.
How often should we test restores?
Automated tests should run regularly, for example weekly, and also after every change to the backup, the storage or the database version. An exercise with the team that plays through the whole sequence from the alert to the running application is worth doing at least once a year.
Where should database backups be stored?
The 3-2-1 rule has proven itself: three copies on two different storage systems, one of them off site. Today a copy that cannot be changed afterwards is often added. For personal data we choose storage locations in Germany or the EU, with GDPR in mind.
Should backups be encrypted?
A backup contains the whole database with all its personal data, so every copy outside your own systems should be encrypted. Keep the key separately and documented, otherwise the backup cannot be read in an emergency.
Read on.
When did you last test a restore?
We restore your backup as a trial and show how long recovery takes and whether the concept has gaps.