Markdown Editor

Backup and Restore Procedure Template

Backup and restore procedure: data inventory, policy table with 3-2-1 check, jobs, monitoring, step-by-step restore, test evidence log

운영표준backuprestoreprocedure

사용법: Use it for any system whose data must survive deletion, corruption or loss of an account or region. Start with the data inventory and RPO/RTO per data set, then derive the policy. The main pitfall is untested backups; only the restore evidence log in section 6 proves they work.

미리보기

Backup and Restore Procedure: [System or data set name]

Procedure for backing up and restoring the data of one system or platform: data inventory, backup policy, backup job steps, monitoring, step-by-step restore, restore testing with evidence, and roles. Based on common IT operations practice, including the 3-2-1 backup rule. Replace every [bracketed] value and every row marked Example.

FieldValue
Procedure ID[BRP-SYSTEM-001]
System[System name]
Version[0.1]
Status[Draft / Approved]
Owner[@backup-owner]
Last restore testYYYY-MM-DD
Next reviewYYYY-MM-DD
Related[Disaster recovery plan], [Data retention policy], [Runbook]

1. Scope and data inventory

Data IDData setStore / technologySizeClassificationRPORTOOwner
D-01Example: Orders databasePostgreSQL 16, managed1.3 TiBConfidential15 min4 h[@name]
D-02Example: Uploaded invoicesObject storage bucket invoices-prod4.8 TiBConfidential24 h24 h[@name]
D-03Example: Infrastructure configurationGit repository infra200 MBInternal0 (Git history)2 h[@name]
D-04Example: Secrets[Secrets manager]n/aRestricted24 h1 h[@name]
[D-nn][Data set][Store][Size][Class][RPO][RTO][@name]

Excluded: [list data deliberately not backed up and why, for example "cache cluster, rebuilt from the database on start"].

2. Backup policy

Data IDBackup typeFrequencyRetentionPrimary locationOff-site / second copyEncryptionImmutable
D-01Example: Continuous WAL archiving (point-in-time)Continuous7 daysSame region, provider-managedCross-region copyAES-256, provider KMS keyNo
D-01Example: Full snapshotDaily 02:00 UTC35 daysSame regionSeparate backup account, other regionAES-256, dedicated keyYes, 35-day lock
D-01Example: Monthly archiveMonthly13 monthsBackup accountCold storage tierAES-256Yes
D-02Example: Object versioning plus replicationContinuous90 days of versionsPrimary bucketReplica bucket, other regionSSE with KMSYes, object lock
D-04Example: Encrypted exportDaily30 daysBackup accountOffline encrypted media, quarterlyAge / GPG, split key custodyYes
[D-nn][Type][Frequency][Retention][Location][Copy][Method][Yes / No]

2.1 3-2-1 compliance

Data IDCopiesDifferent media or servicesOff-site copyImmutable or offline copyCompliant
D-013 (live, snapshot, cross-region)2YesYesYes
D-0221YesYesExample: No, add a third copy in other provider by YYYY-MM-DD
[D-nn][n][n][Yes / No][Yes / No][Yes / No]

2.2 Key management

[Describe where encryption keys are held, who can use them, how they are backed up separately from the data, and how access is reviewed. A backup whose key is lost with the primary account is not a backup.]

3. Backup job steps

3.1 Job: [D-01 daily snapshot]

ItemValue
SchedulerExample: Provider backup plan orders-daily
Schedule02:00 UTC daily
Configuration source[Infrastructure code path]
Runs as[Service account / role]
Expected durationExample: 25 min
  1. Scheduler triggers snapshot of the database instance.
  2. Snapshot is tagged with data-id=D-01, retention=35d.
  3. Copy job replicates the snapshot to the backup account in [region].
  4. Lock policy is applied to the copied snapshot.
  5. Job writes a success or failure event to the monitoring system (section 4).

3.2 Job: [Data ID and name]

[Repeat for each backup job in section 2: scheduler, source, steps, outputs and verification.]

4. Monitoring and alerting

CheckConditionSeverityRoutes toRunbook
Job failureAny backup job reports failureTicket, page if two in a row[Team][Link]
Missing backupNo successful D-01 snapshot in the last 26 hPage[On-call][Link]
Replication lagCross-region copy older than 30 hTicket[Team][Link]
Size anomalyBackup size changes by more than 30% day on dayTicket[Team][Link]
Retention driftOldest restorable point younger than policyTicket[Team][Link]
[Check][Condition][Severity][Team][Link]

A weekly report lists every data set with its latest successful backup and oldest restorable point, reviewed by [@owner].

5. Restore procedure

5.1 Before you start

  • Confirm the restore request: data set, point in time, target environment, approver.
  • Open or link an incident or change ticket: [ticket ID].
  • Check whether the security team must preserve the current state as evidence.
  • Estimate duration from the last restore test (section 6.2).

5.2 Restore steps: D-01 Orders database (point in time)

StepActionCommand or locationVerificationDone at
1Identify target time (UTC) just before the data loss eventLogs, audit trailTime agreed with data owner[hh:mm]
2Restore to a new instance at the target time[provider CLI] restore-to-point-in-time --source orders-prod --target orders-restore-[date] --time [timestamp]New instance available[hh:mm]
3Run integrity checks[checksum or row count queries]Counts within expected range; latest row timestamp equals target time[hh:mm]
4Validate with data ownerSample of records reviewedOwner confirms[hh:mm]
5Choose switch-over methodRepoint application or copy selected rows backDecision recorded[hh:mm]
6Switch over or merge data[command]Application healthy; smoke tests pass[hh:mm]
7Keep the old instance for [7 days], then delete with approval[Ticket]Deletion scheduled[hh:mm]

5.3 Restore steps: [Data ID and name]

[Repeat for each data set. For object storage, describe restoring a prior object version or copying back from the replica bucket. For secrets, describe the two-person key ceremony.]

5.4 After the restore

  • Record the restore in the evidence log (section 6.2), even when it was a real event.
  • Confirm backups resume on the restored system.
  • Update this procedure with anything that was unclear or slow.

6. Restore testing

6.1 Test schedule

Test IDData IDTest typeFrequencyNext dateOwner
RT-01D-01Point-in-time restore to isolated instance plus integrity checksMonthlyYYYY-MM-DD[@name]
RT-02D-02Restore random sample of 100 objects from replicaQuarterlyYYYY-MM-DD[@name]
RT-03D-04Decrypt and import secrets backup in isolated vaultTwice a yearYYYY-MM-DD[@name]
RT-04AllFull restore as part of DR exerciseYearlyYYYY-MM-DD[@name]
[RT-nn][D-nn][Type][Frequency]YYYY-MM-DD[@name]

6.2 Evidence log

DateTest IDBackup usedRestore durationRTO metData verifiedIssuesTester
YYYY-MM-DDExample: RT-01Snapshot of YYYY-MM-DD 02:00 plus WAL to 09:151 h 52 minYes (4 h)Row counts and checksums matchBR-ISS-03: restore role lacked KMS permission in backup account[@name]
YYYY-MM-DD[RT-nn][Backup][Duration][Yes / No][Checks][Issue IDs][@name]

6.3 Issues from testing

IDIssueActionOwnerDueStatus
BR-ISS-03Example: Restore role lacked key permissionGrant decrypt permission; add to IaC[@name]YYYY-MM-DD[Done]
[BR-ISS-nn][Issue][Action][@name]YYYY-MM-DD[Status]

7. Roles and responsibilities

RoleResponsibilitiesPerson / team
Backup ownerMaintains this procedure, policy and jobs; reviews weekly report[@name]
Data ownerSets RPO and RTO; approves restores and validates restored data[@name]
Operator / on-callResponds to backup alerts; performs restores[Team]
SecurityKey management, access review, immutability settings[@name]
Restore approverAuthorises production restores and overwrites[@name]

Access to delete or shorten retention of backups requires [two-person approval / break-glass role] and is reviewed [quarterly].

8. Review

This procedure is reviewed every [6 months], after each failed or slow restore test, and when a data store is added or changed.

Based on common IT operations practice for backup and recovery, including the widely used 3-2-1 backup rule. Original text written for this collection; commands are illustrative. Template licence: MIT.

관련 템플릿