Backup and Restore Plan for a Small Database
Define backups, retention and a tested restore routine.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it.
Create a backup plan for [DATABASE_AND_HOSTING]. Data importance and tolerance for loss: [DATA_IMPORTANCE]. Size and growth: [SIZE]. Budget: [BUDGET]. Who maintains it: [MAINTAINER]. Define backup types and schedule, retention periods, storage locations kept separate from the main system, encryption and access, and monitoring that a backup actually ran. State the recovery point and recovery time targets in plain words and check they match my tolerance. Return a schedule table, a restore runbook in numbered steps, a quarterly restore test checklist and a record of results. A backup that has never been restored is unproven. Retention rules for personal data are [VERIFY] for [JURISDICTION]. Add a worked example: if the recovery point target is 15 minutes, backups every 24 hours do not meet it, so describe what would, such as continuous log shipping or point-in-time recovery if the database supports it. Add a cost estimate table for storage with the arithmetic for retention of 30 daily and 12 monthly backups using my size figure. Describe how to monitor failures with an alert that fires when no successful backup has been recorded for a day, and who receives it. Explain how to protect backups from the same accidents that damage the main database, including separate credentials and account, immutable storage if available, and offsite copies. Include a short communication template for a restore drill, and a note on how to restore a single table or record without rolling back everything. Mark vendor-specific features for checking in the documentation [VERIFY]. Add a closing section on common failures: backups that silently stop after a password change, restores that fail because a key is missing, and storage that fills up. For each, give the symptom, the check that would catch it and the person who would act. Add a one-line record to keep after each drill: date, who restored, how long it took, and what was learned.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.
See an example result (fictional data)
Invented database of 40 GB with 2 percent daily change. Plan: full backup weekly, daily incremental, log shipping every 15 minutes. Recovery point target 15 minutes; recovery time target 4 hours. Storage estimate: 4 weekly fulls x 40 GB = 160 GB; 28 daily incrementals x 0.8 GB = 22.4 GB; total about 182 GB before compression. Monitoring: alert if no successful backup is recorded in 24 hours. Quarterly drill: restore to a test server, time it, check row counts. Last drill result placeholder: 2 h 10 min, within target.
Illustrative only, made-up data. Your results will differ and must be reviewed.