Direct answer
A backup only counts once it has been restored. Many organisations have backups that were never tested and discover on the worst day that a file is missing, unreadable or unusable without a key nobody has. A plan therefore has two halves: making copies, and proving that you can get the system back from them. It also needs owners: someone accountable for the copies, and someone able to carry out a restore. We do not promise recovery times on this page, because they depend on the size and design of the system and on who is available. What you can do is decide the questions below and write the answers down. It is part of development infrastructure setup.
What to back up
Start from what you could not rebuild. Typically that is more than the database:
- The database and any records created by users
- Uploaded files and documents, which often live outside the database
- Configuration and environment settings, without exposing secrets in the backup itself
- The source code and deployment setup, so the application can be rebuilt
- Data held in connected SaaS tools that the application depends on
- Domain, DNS and account recovery details needed to bring the system back
Where copies live and who owns them
A copy stored next to the original is lost with it. Keep at least one copy in a separate place, under an account your organisation controls rather than only the vendor's. Decide who can read the copies, because a backup holds the same sensitive data as the live system and needs the same care. Note where encryption keys are kept: an encrypted backup is useless if the key disappears with a former employee. Ownership matters most at the end of a project, so see the software handover checklist.
Frequency as a decision
How often to back up is a business decision, not a technical default. Ask how much recent work you could afford to lose and re-enter. A system where records change constantly needs a different rhythm from one updated occasionally. We do not prescribe a schedule here. Agree the acceptable loss with the process owner, write it down, and check that the setup actually meets it, for example that scheduled copies run and that failures are reported to someone.
The restore test
The restore test is the point of the whole exercise. Restore a backup into a separate environment, not over production, and check that the system starts, that users can sign in and that sample records, files and recent changes are present. Note what you had to do and how many people it took, and fix anything that was unclear. Repeat the test after significant changes and at a regular interval you set. A restore that has only been done by the original builder proves less than one done from the written steps by someone else.
Who can restore
Name the people who are able and authorised to perform a restore, plus a backup for absence. Check that they actually hold the access they would need: to the storage location, the hosting account and the keys. Also decide who can approve a restore, since restoring can overwrite recent data. Make sure the steps and the contact list are available somewhere that does not depend on the failed system itself.
Retention
Retention is how long you keep old copies. Keeping copies only from last night cannot help with a problem discovered next week, while keeping everything forever adds cost and risk. Choose a period that fits how quickly you would notice a problem and any record-keeping obligations you have, and confirm those obligations with your own advisers. Also decide how old copies are deleted, so removed data does not linger indefinitely in archives.
Exporting SaaS data
If part of your process runs in a third-party tool, do not assume its provider's backups are yours to use. Check what the tool lets you export, in what format and how often, and whether an export includes attachments and history. Schedule an export you control and test that you can read it. Where a tool offers no complete export, record that as a risk you have accepted, or as a reason to reconsider the dependency.
The written plan
Put the answers in a short document: what is backed up, where copies are, who owns them, how often, how long they are kept, who can restore, the restore steps and the date of the last successful test. Keep it with your other operational documents and review it when the system changes. LATYNEX is a remote English-language vendor; we agree one scope and one price in writing, and can include backup setup and a restore rehearsal in it. See also software maintenance after launch.
Questions
How do we know our backups work?+
Only by restoring one into a separate environment and checking the result. A backup job that reports success shows that a file was written, not that the system can be rebuilt from it.
How quickly can you restore our system?+
We do not quote recovery times in general, because they depend on the system's design and size and on who is available. A restore test gives you an evidence-based answer for your own setup.
Is the hosting provider's backup enough?+
It might be part of the answer, but check what it covers, how long it is kept and whether you can access it yourself. Keep at least one copy under your own control.
Do we need to back up SaaS tools we use?+
If the process depends on the data in them, yes, in the sense of having an export you can read. Check what each tool can export and test it.
Who should hold the encryption keys?+
Your organisation, with more than one authorised person and a documented recovery route, so that a single departure cannot make backups unreadable.