Backups that have actually been restored.
Who it is for
For companies and public bodies with applications, portals or databases they cannot afford to lose, and nobody with the time to check that the backup works.
The problem
"We have backups, I think." Someone set them up years ago and nobody has looked since. You do not know what is backed up, where it is or how long it would take to be running again. And the day you need it, the backup is incomplete or nobody knows how to restore it.
How we solve it
We list what has to be backed up and copy it, encrypted, off the server. Then we restore it: we bring the backup up in a separate environment and check that the application starts with its data. A backup that has never been restored does not count.
What it includes
Inventory
What is backed up, what is not and why: databases, documents and configuration.
Encrypted backups
Encrypted before they leave the server and stored somewhere else.
Restore tests
We actually restore in a separate environment, and record the date and the result.
Backup monitoring
If a backup fails or does not run, we find out, not you.
Written procedure
The steps to restore, written down and tested, so they do not depend on one person.
Monthly report
Backups made, restore tests and anything that failed.
How we work
We start with the inventory and by agreeing with you, in writing, how often backups run and how long they are kept. After that the backups run on their own and we check them. Every month you get the report with the restore tests. If one day a real restore is needed, you decide and we do it.
What we measure
Backups made and backups failed, age of the last valid backup, date and result of the last restore test, and how long a restore takes.
How it is built
We back up three things: the database (a consistent dump, not its live files), the documents and the configuration. In a Liferay installation that means the PostgreSQL database, the document library and the configuration files. The Elasticsearch search index is not backed up: it is rebuilt.
Backups are encrypted at the source, before they leave the server, and stored separately from production. The encryption keys live in the secrets manager, not on the server or in a file: without them the backup cannot be read.
The restore test always follows the same steps: the backup is brought up in an isolated environment, the application is started, and we check that it responds and that the data is there. If it fails, it is handled as an incident. The infrastructure is described as code, so the server can be rebuilt too, as well as its data.
The backup jobs, their scripts and the restore procedure stay in your repositories. If another team runs it tomorrow, they have what they need.
Frequently asked questions
What does a tested backup mean?
That we have restored it in a separate environment and the application started with its data. We record when it was done and how it went.
How often do backups run and how long are they kept?
It depends on how much work you can afford to lose and on your legal obligations. We agree it in writing before we start and it appears in every report.
Who can read the backups?
Nobody without the key. Backups are encrypted before they leave the server and the key lives in a secrets manager, with a record of who accesses it.
Can you take over the backups of a system you did not set up?
Yes. We start by reviewing which backups exist and by restoring one. Whatever that test shows is the starting point.
Also in Managed systems
Monitoring
Error and availability monitoring, with the fix already prepared.
Deployments
Every change goes through tests before production, with rollback.
The next step
Tell us how you work today and we will tell you where to start.