The two tiers
| What | Standard | Managed database |
|---|---|---|
| Who it suits | Most small clients: one server with the database on it | Larger clients on MyRecords Cloud |
| Backups | A full set every day | The database is backed up continuously; files daily |
| Kept | 14 days on the server, 90 days off it (when off-site backup is set up) | 14 daily database backups, point-in-time recovery for 7 days, plus the daily set |
| Most data you could lose (RPO) | 24 hours | Minutes for the database; 24 hours for uploaded files |
| Back in service (RTO) | 4 hours | 2 hours |
You choose the tier when you sign. On MyRecords Cloud, the Large plan includes a managed database with a standby copy.
What a backup set holds
- The full database.
- Every file people uploaded: public and private attachments.
- The system’s settings.
- Encryption. The database and both file archives are encrypted with AES-256.
- The keys. They are written next to each set on the server, and we keep them in a separate secret store too, leaving them out of the off-server copy. Without them an encrypted set, and the encrypted fields inside it (PAN, Aadhaar, bank numbers), cannot be read.
The restore drill, 22 Oct 2026
We rebuilt a working system from a backup set and the keys alone, with no access to the original system. Every step was timed:
| Step | Time |
|---|---|
| Set up the site from the keys | 0.8 s |
| Restore the database | 19.2 s |
| Unpack 1,346 files | 0.1 s |
| Web check | answered at once |
| Sign in, read an encrypted value, check the books (649 ledger entries, balanced) and document counts | 3.5 s |
| Bring the database up to the current version | 52.3 s |
| Save a new document | done |
| Total, backup files to a usable system | 79.5 s |
The drill used our demo company. A real recovery also needs a server with MyRecords installed (7.5 to 11 minutes on our rehearsals), the web address pointed at it and a security certificate. That is why the Standard tier promises 4 hours: hours of margin over the minutes measured.
On 3 Nov 2026 we ran it again on an encrypted set: decrypting took 0.8 seconds, all 246,058 rows were restored with no table different, and the whole run took 209.9 seconds. Most of that was bringing the database up to a newer version than the backup’s.
We repeat the drill whenever the backup or restore scripts change, and on each client’s first real backup before go-live.
What we do in common situations
| Situation | What happens |
|---|---|
| A record or a day’s work deleted by mistake | We restore the latest backup into a separate test copy and bring back what was lost, or restore the whole system to the last backup |
| Server disk full | The health check warns us; we free space or grow the disk |
| Server lost (deleted, data-centre outage, ransomware) | New server, install, restore the latest off-server set, point the address at it |
| Encryption keys lost | Encrypted fields cannot be recovered; everything else restores. This is why the keys are kept in three places |
| Backup key lost | An encrypted set cannot be restored at all. This is why the key sits in a password manager from the day encryption is switched on |
Watching the backups
A health check runs every 5 minutes on each system. It warns when off-site backup is not set up, or when the newest backup is more than 30 hours old.
On your own server
The daily backup runs on your server too. Off-site copies need a place to send them, such as a storage bucket or a second machine, which we set up with you. Until that is done, backups stay on the same server, and a lost server means lost backups.