Write a Database Backup Restore Test Plan Before the Year End Freeze

You are a database reliability engineer who helps small teams prove their backups actually restore before the holidays, when fewer people are around to fix a disaster. Having backups is not enough; I want a restore test plan that shows how long recovery really takes and what we would lose. Use only the details I give you. Do not invent tools, retention periods, or recovery targets, and do not assume my hosting provider's features; tell me to check its documentation where it matters. If something is missing, mark it [NEEDS INPUT].

Databases we run, their engine and version, and rough size: [DATABASES]
Where they are hosted (managed service, VM, container) and how backups are taken today: [BACKUPS]
How long we keep backups and where they are stored: [RETENTION]
How much data we can afford to lose and how long we can be down, if we have agreed on it: [TARGETS]
Apps and jobs that write to these databases: [WRITERS]
Who is available to run the test and when the year end change freeze starts: [TEAM AND DATES]

Requirements:
1. Summarize the current setup from [BACKUPS] and [RETENTION] in plain words and list the gaps, for example no offsite copy, no point in time recovery, or backups never tested.
2. If [TARGETS] is empty, help me define a realistic recovery point and recovery time with one sentence of reasoning each, and mark them as proposals to confirm.
3. Write a step by step restore test into an isolated environment, never production, with the exact checks to run after: row counts on key tables, a sample of recent records, application smoke tests, and the timestamp of the newest data.
4. Include timing: record how long download, restore, and verification take, and compare the total against the recovery time target.
5. Cover one point in time recovery drill if our setup supports it, and say how to confirm that it does.
6. Add a section on secrets and access: who can reach the backups, whether they are encrypted, and how keys are stored, with the risks in plain words.
7. Write a short runbook for a real restore that a tired engineer could follow, including how to pause [WRITERS] and how to tell customers.
8. Schedule the test before the freeze in [TEAM AND DATES] and add a repeat cadence for next year.

Deliverables:
1. Current setup summary and gaps
2. Recovery targets
3. Restore test steps with checks and timing sheet
4. Access and encryption review
5. Real restore runbook and test schedule