Operational policy design for small internal IT teams and MSPs. Example periods require approval for each workload; they are not legal retention requirements or a universal vendor configuration.
Schedules, dates and capacity figures below are illustrative planning examples, not measured restore results. Product lifecycle behaviour must be confirmed for the chosen workload and backup service.Separate frequency, retention and isolation
Start with the recovery question, not a storage-saving percentage. Frequency determines how often a new recoverable state is captured. Retention determines how long selected states survive. Isolation determines whether a production failure or compromised identity can also destroy the recovery copy. Each needs its own decision.
A daily job with 30 days of retention might support a file deletion noticed two weeks later. It does not automatically meet a four-hour recovery point objective. A monthly point retained for a year offers a longer look-back window, but leaves much wider gaps between the older states you can choose.
Replication and synchronisation can carry an unwanted change to another location. Retaining versions can help, but verify whether deletion, account compromise or expiry can remove those versions too. A long retention period under the same unrestricted administrator is not equivalent to an independently protected copy.
Agree the workload and its discovery window
List the service, application data, configuration, identity dependencies and encryption keys required for recovery. Name a business owner who decides how far back recovery must go and a technical owner who can demonstrate it. A policy for a server is incomplete if its database or keys follow a different undocumented schedule.
Ask when a mistake is likely to be noticed: immediately, at weekly reconciliation, or at month-end. Add time for investigation and restore approval. If an error can remain unnoticed for 45 days, a 30-day daily history cannot recover the last correct state once it has expired. Either retain suitable points longer or explicitly accept the gap.
Keep legal records retention separate from operational backup. The data owner should obtain applicable jurisdiction, contract, privacy and hold requirements rather than copying a seven-year period from another organisation. Backups may contain personal or obsolete data, and making every backup permanent creates its own access, cost and disposal problems.
Use a sample schedule as a discussion draft
The following is an illustrative schedule for a modest internal file service. It is a starting point for a business decision, not a default for every workload. A transactional application may need much more frequent application-consistent protection, and a low-value rebuildable system may need less history.
Specify the capture timezone, selection rule and successful-job condition. For example, the last successful daily point on the last calendar day of each month may be the monthly selection. Define a fallback for a failed month-end job; do not silently label an earlier point as month-end.
| Recovery tier | Illustrative retention | Purpose and limitation |
|---|---|---|
| Daily point | 35 days | Recent accidental changes; still only daily granularity |
| Weekly selected point | 12 weeks | Intermediate look-back; does not retain every day |
| Monthly selected point | 12 months | Longer history; month-to-month gaps remain |
| Separate protected copy | Independently agreed period | Survives specified failure or deletion paths; test access |
See what an older restore can actually recover
Imagine an error is introduced on 8 September and discovered on 20 October. The elapsed date difference is 42 days. Under a 35-day daily policy, the daily state immediately before the error has expired. If monthly points exist for 31 August and 30 September, September contains the error and August is the candidate to investigate.
Restoring 31 August also loses legitimate subsequent changes unless they can be reconstructed or selectively recovered. Retention has preserved an older state, but it has not made that state current. Determine the first affected point, validate the candidate in isolation and agree what later data must be reconciled.
Weekly points may narrow that gap if a clean one survives. Do not infer that any particular point is clean from its timestamp alone. Verify application consistency, credentials, dependencies and the actual business records before restoring over production.
Budget storage without counting points as full copies
The sample tiers select up to 35 daily, 12 weekly and 12 monthly positions: 59 tier selections. That is not necessarily 59 unique backups. One recovery point can qualify for more than one tier, and products differ in how they implement overlapping policies, incremental chains, synthetic fulls and expiry.
For a deliberately simple capacity estimate, assume a 1,000 GiB starting dataset and 10 GiB of additional retained data per day for 35 daily captures. One base plus 34 changes gives 1,340 GiB before metadata, compression, deduplication, extra copies and older weekly/monthly history. This is an assumed model, not a bill estimate or a promise about any vendor.
Measure actual retained growth after a representative cycle and include temporary space for restore, chain maintenance and policy transitions. Archive storage can introduce retrieval delay, retrieval charges and minimum storage periods. The AWS Backup lifecycle reference, for example, requires eligible backups moved to cold storage to remain there at least 90 days; verify resource support rather than assuming every backup can move.
Budget recovery time as well as capacity. A low-cost archive point that cannot be retrieved and validated within the agreed recovery time is a different service from a readily available recent copy.
Control expiry, holds and policy changes
Document who can change retention, who approves a reduction and who reviews deletion exceptions. Separate routine job operation from the authority to shorten protected history where the product supports it. Record the policy version, affected workload, old and proposed values, approval, effective date and rollback limitations.
Never test expiry by deleting the only good production recovery point. Use a disposable protected test workload, inspect the supported policy preview or export, and confirm which existing points are affected. Vendor behaviour can differ when a policy is shortened, extended or reassigned. Verify exact workload and policy type before applying the change.
An immutable period, a legal hold and soft delete solve different problems. An immutable setting may prevent deletion for a defined period; a hold preserves specified material under an authorised process; soft delete may provide a bounded recovery opportunity after deletion. Check scope, privileges, effective dates and release conditions for each rather than substituting one label for another.
Do not promise that a locked backup can be shortened later to save money. Some retention protections deliberately prevent that. If a legal hold applies, obtain its explicit scope and release authority before normal disposal resumes.
Complete the editable policy worksheet
Download the worksheet below and complete one entry per workload class. Store the approved version with its owner and review date; keep credentials and sensitive tenant details in their approved secure systems rather than embedding them in the policy.
| Policy field | Decision to record |
|---|---|
| Scope and owner | Service, data, exclusions, business owner and recovery operator |
| Capture rule | Frequency, timezone, consistency and failure handling |
| Retained tiers | Selection rules, periods, overlap and approved discovery window |
| Protection and expiry | Locations, independent access, locks, holds and change authority |
| Acceptance evidence | Recent and old point restores, outcome and remediation owner |
| Review trigger | Next review plus workload, supplier, staffing or obligation changes |
Accept the policy with restore evidence
Check the actual recovery-point catalogue against the expected schedule. Look for a missed daily run, absent month-end point, unexpectedly young oldest point or a workload omitted from protection. A green job dashboard does not prove the entire policy is satisfied.
Restore a recent point and an older retained point to an isolated destination. Include archive retrieval if you depend on it. Record point identifier, workload version, keys and dependencies, elapsed retrieval and validation time, business acceptance and unresolved gaps. One successful file restore does not establish whole-application recovery.
Test a failed scheduled capture and the authorised expiry/change process on disposable data. Retain expected and actual outcomes. Review exceptions at a frequency matched to workload risk and assign a named owner and deadline; never quietly mark a missing monthly point compliant.
Review the policy when an application, repository, identity, supplier plan or business obligation changes. A longer retention setting is useful only if the retained states remain accessible, affordable and demonstrably recoverable.
Next step: approve the schedule before choosing a tool
Agree the recovery task and discovery window, write the tier-selection rules and obtain the data owner's decision. Then compare tools against that policy, including workload support, expiry controls, independent access and tested restoration. Retention length alone is a poor reason to choose a backup product.