Protect Backup Versions and Prove They Can Be Restored
Consider a hypothetical incident: ransomware scrambles live files, the backup system syncs those encrypted files, and the attacker then tries to delete older restore points. Having backups is not enough if the same compromise can destroy the versions needed for recovery.
Recoverable backups need protection from the credentials an attacker might steal. Amazon S3 Object Lock helps protect retained versions, but the protection depends on the retention mode and permissions. It is one part of a recovery plan, not a guarantee that backups are ransomware‑proof.
This guide covers Amazon S3 general purpose buckets, versioning and Object Lock with fixed retention dates. It explains governance versus compliance, the limits of MFA Delete, lifecycle and replication choices, and isolated restore drills. These controls help resist backup destruction; they do not prove that a backup is clean, decryptable or usable by the application.
How Ransomware Can Reach Backup History
An attacker with production access may also find credentials for snapshots, NAS storage or cloud backups. If the backup job can overwrite the current view and permanently delete older recovery points, the same compromise can affect both live data and recovery history. Separate backup writing from deletion and retention administration.
Synchronization can faithfully copy encrypted or corrupted files. Object Lock does not inspect uploaded data for correctness; it protects the versions to which retention or a legal hold actually applies. Detection time and the required clean recovery window therefore matter when choosing how long to preserve history.
Governance retention can be bypassed only with the appropriate permission and an explicit bypass request. Compliance prevents users, including account root, from deleting a protected version or shortening its retention while that retention is in effect. Account closure, lost access and unavailable encryption keys remain separate risks; avoid treating either mode as a guarantee against every recovery failure.
Object Lock Protects Individual Versions
Object Lock requires S3 Versioning. A particular object version can have retention, a legal hold, or both. Writing new data to the same key creates another version; it does not overwrite the protected version. A normal DELETE without a version ID can still add a delete marker, making the current object appear absent while older protected versions remain.
This guide uses fixed retention with a retain-until date. Select the mode and duration from the required recovery history and applicable retention obligations. A bucket default covers applicable new versions written afterward; it does not retroactively lock all existing versions. Explicit individual retention settings can override the default, so verify the actual retained versions.
In governance mode, bypass requires s3:BypassGovernanceRetention and an explicit bypass selection in the request; the S3 console can add the bypass header for an authorized user. In compliance mode, the protected version cannot be deleted, its mode changed or its retention shortened during retention, including by root. An authorized user can extend the date. Choosing compliance mode does not itself establish compliance with every regulation.
A legal hold remains until a user with the relevant permission removes it. It is independent of retention: an expired retention date does not remove a legal hold, and removing a hold does not cancel active retention. Governance bypass does not bypass a legal hold. Record why a hold exists and who can authorize its removal.
Object Lock can be enabled on new or existing general purpose buckets, with versioning enabled. After Object Lock is enabled, it cannot be disabled and bucket versioning cannot be suspended. Enabling the feature and protecting every required existing version are separate tasks; inspect the current backup inventory before assuming historical coverage.
Use bucket default retention for tools that do not set explicit retention, then verify the resulting version ID, mode and retain-until date. Do not assume that an upload tool or an S3-compatible provider supports every Amazon S3 feature. The rclone, S3 and Backblaze B2 backup guide discusses transfers, encryption and lifecycle planning.
Versioning, MFA Delete and Encryption Keys
In a versioning-enabled bucket, a new upload to an existing key creates a new version. A DELETE without a version ID normally adds a delete marker; a DELETE specifying a version ID requests permanent removal of that version and is subject to permissions and protection. Not every operation creates a new data version: updating an existing version’s tags is different. Each stored version is a complete object for storage charging, rather than only a difference from its predecessor.
MFA Delete requires additional authentication for permanent object-version deletion and changes to the bucket’s versioning state. It does not generally prevent a simple DELETE from adding a delete marker. Enabling or disabling it requires the bucket owner’s root account through CLI/API, rather than a normal console toggle. Requests use a supported registered hardware or virtual MFA device’s serial number/ARN and six-digit code; a security key is not automatically that type of code-generating device.
MFA Delete cannot be used with lifecycle configurations. Choose an Object Lock + Versioning design with lifecycle and narrowly scoped IAM permissions when automated tier changes are needed, or document a lifecycle-free workflow if MFA Delete is required. MFA-protected IAM access is a different mechanism. See the official MFA Delete behavior and Object Lock details. Verify the registered device and account recovery route; do not assume an arbitrary spare device works or put root credentials in daily backup automation.
Use TLS for transfers and suitable at-rest encryption. With SSE-KMS, separate key administration from encryption/decryption use and preserve access to every key required by retained backups. Object Lock does not stop a key being disabled, made inaccessible by policy or deleted. A deleted symmetric KMS key cannot simply be recreated to decrypt its old ciphertext. Test recovery access in both primary and replica locations, and monitor key-policy changes and deletion scheduling.
Choose Governance or Compliance Deliberately
Governance can support a controlled trial of retention settings because a separately authorized operator can correct mistakes using an explicit bypass. Keep that capability out of the routine writer role and protect emergency access with strong authentication, limited scope and an audit trail. MFA alone does not provide team approval or confirm that the selected version is the right target.
Compliance is suitable when the required period is established and users must not shorten it. During active retention, even root cannot delete the protected version or switch its mode. That constraint makes storage cost, encryption-key lifetime and retrieval time part of the design before large backup sets are locked. Test the workflow with a small, noncritical set first.
Daily, weekly and monthly copies can have different retention needs. Windows such as 7–30 days for daily copies, several months for weeklies and a year for monthlies are illustrations, not universal requirements. Choose from detection delay, recovery needs and obligations. Separate buckets can carry different defaults; a prefix alone does not create a prefix-specific bucket default. Explicit version settings require suitable tooling and permissions.
Plan Lifecycle Costs and Replication Limits
This lifecycle design assumes MFA Delete is not enabled. Object Lock protection remains through storage-class transitions. Lifecycle cannot permanently expire a version while protected by retention or a legal hold, although it can add delete markers. Conversely, retention expiry does not itself delete the object; a matching expiration action or authorized deletion is still needed.
Standard-IA has a 30-day minimum storage charge; Glacier Instant Retrieval and Flexible Retrieval have 90-day minimums, and Deep Archive has 180 days. Glacier Instant Retrieval supports direct access. Flexible Retrieval and Deep Archive require an archive restore request first, with waiting time depending on the retrieval option. Include that wait, transfer and application recovery in RTO planning; a Deep Archive copy alone may not meet a target measured in minutes.
S3 replication copies eligible objects asynchronously. For locked-source replication, destination buckets must also have Object Lock enabled, and the replication role needs the required permissions including retention and legal-hold reads. Verify completed replication and retained version state at the destination. The legacy Object Lock replication link now redirects to the user-guide index; use its Object Lock considerations section for current replication guidance. A second region alone does not isolate deletion credentials.
Separate the production account from the backup-owning account when that fits the threat model, and actually restrict cross-account permissions. The uploader may need scoped multipart, listing, verification and KMS permissions beyond PutObject. Avoid routine version deletion, governance bypass and bucket retention-policy administration. Stolen writer credentials may still add bad versions or increase cost, so monitoring and independent recovery access remain necessary.
A Practical Backup-Vault Blueprint
Start with the account, region and general purpose bucket that will own the backups. Enable versioning and Object Lock on a new or existing bucket, and choose a justified default. A 14-day governance period is only an illustrative trial, not a recommended duration for every workload. Inventory existing versions separately and verify retention on a small upload before expanding.
If using SSE-KMS, prepare a backup key and policies that distinguish key administration, upload and restore roles. Do not grant backup automation key-policy administration or deletion scheduling. Grant the cryptographic operations its actual upload method needs; multipart operations can require more than an assumed encrypt-only permission. Alert on unusual usage, policy changes, disabled keys and deletion scheduling, and test recovery access.
If replication is required, prepare the destination Object Lock configuration and IAM permissions first. SSE-KMS objects require an explicit replication opt-in and an appropriate destination-region key and policy. A successful configuration request does not prove that objects replicated or can be decrypted. Check replication completion, destination version retention and a real test download using the intended recovery role.
Create a consistent, completed backup set before transferring it. Copying a live database directory with a generic sync tool does not establish database consistency. For rclone or another uploader, use bucket default retention where appropriate and inspect the resulting retained version. Do not assume unspecified “object-lock upload parameters” exist in the installed tool; verify supported options before using explicit per-version settings.
Keep write, verification, restore and retention administration permissions distinct. Give routine jobs only the scoped permissions they need; reading a specific version can require version-specific access, and reading retention/legal hold requires its own permissions. If MFA Delete is selected, plan its supported device and root access separately from automation, and use a workflow without lifecycle.
For the lifecycle alternative, choose transitions from access patterns and measured recovery time. AWS removed the old 30-day waiting period before Standard-IA/One Zone-IA transitions on 16 July 2026; transitions can be scheduled from object creation day. Their minimum storage billing still applies. A week-old IA transition is therefore possible, but is not automatically economical. Account for request charges, object size and time in each class; new lifecycle configurations normally leave objects below 128 KB untransitioned.
Run Spot Checks and Full Restore Drills
Use two levels of evidence: a small restore checks the data path, while a full rehearsal checks whether the service can function with recovered data and dependencies. An illustrative starting schedule is weekly spot checks and a monthly full service restore. Set the actual frequency from criticality, change rate and obligations, and repeat affected tests after significant changes.
For a spot check, select a known-good candidate by exact version ID, retrieve it into an isolated target and compare against a trusted checksum recorded for that backup. Rotate through buckets and storage classes. Do not assume an S3 ETag is always a plain file MD5. Inspect the restored content as well as its transfer result; a matching hash only proves agreement with the chosen baseline, not that the baseline was clean.
For a full rehearsal, restore the application with its matching database, files, configuration and required secrets through a restricted recovery path. Test login and representative workflows with expected outcomes. Use an isolated environment, sandbox payments and disabled real emails/webhooks. Apply any required masking to a derived test copy, preserving the original recovery artifact. The WordPress on Docker Compose guide provides related stack context; a started container alone does not prove successful recovery.
Database recovery needs its own checks. PITR requires a suitable consistent base backup and the complete required WAL/log chain to the chosen target; a generic file copy is insufficient. Restore an isolated instance and verify relationships, business totals and application behavior against the same recovery point. The pgBackRest and PostgreSQL PITR guide explains that database-specific workflow. Align database time with file and deployment versions.
A runbook should record exact version IDs, recovery target, tool/engine versions, access prerequisites, owners and acceptance checks. RTO is the target time from interruption to the agreed usable service level; RPO is the acceptable data-loss window measured backward from interruption to the recoverable point. Keep objectives separate from observed results. The disaster recovery plan guide gives structure for these decisions.
Check the Remaining Failure Paths
Enabling Object Lock on an existing bucket is supported, but that action alone does not protect every old version. Inspect historical retention and any legal holds, then address gaps through an authorized version-specific operation. Changing the bucket default affects applicable future uploads, not the retain-until date already attached to each retained version.
Audit IAM and bucket policies for version deletion, governance bypass and retention/legal-hold administration. Keep break-glass access separate and logged. A legal hold and compliance retention are not bypassed simply because an operator assumes an emergency role. Test the intended access route when the normal identity or primary-region path is unavailable.
Verify KMS decryption using the actual recovery role in each location. Limiting key deletion permissions, monitoring policy changes and documenting recovery access reduces risk, but a policy statement alone is not evidence that a restore works. Preserve key availability throughout the lifetime of all backups that depend on it.
Test retrieval from each archive class you intend to rely on. Include archive waiting time, download and application validation in the result. Cost review should include retained-version count, GB, transition and retrieval requests, minimum-duration charges and temporary recovery infrastructure; cheaper storage does not necessarily mean cheaper or faster recovery.
Where the tool relies on bucket defaults, inspect uploaded versions to confirm coverage and test a missing/incorrect retention setting with noncritical data. Longer retention or a legal hold may be applied where justified and authorized. Prefixes help classify data, but do not create separate default retention rules by themselves. Existing compliance retention cannot be shortened to correct a cost mistake.
Object Lock complements endpoint protection, patching and credential control. Keep the backup host narrowly purposed and monitor failed jobs, unexpected uploads and access changes. An immutable copy can preserve corruption just as faithfully as good data, so retain enough history to select and validate a clean point.
From a Trial Upload to a Verified Restore
Stage one: choose the backup account/bucket and prepare versioning, Object Lock, default retention and encryption. Use a small, noncritical set for an illustrative 14-day governance trial. Specify which role may upload, restore or administer retention. Choose either lifecycle-based tier management without MFA Delete, or the separately operated MFA Delete alternative.
Stage two: upload the consistent backup set and record version IDs, retention mode/date, legal-hold status and encryption. If using replication, verify its destination copy and decryption. CloudTrail object data events are not enabled by default; select the needed bucket/prefix and read/write coverage, with costs and log retention planned. Use data events to inspect DeleteObject requests including version IDs, and management events for bucket versioning/policy changes. Verify alert delivery with a controlled authorized test instead of assuming “every access” is logged.
Stage three: restore the selected version to an isolated environment and perform file, database and application checks. Record archive wait, transfer, database recovery, application startup, validation and traffic-routing time separately. DNS changes do not immediately update existing caches. An alternate hostname needs tested client routing, TLS, cookie and callback configuration; it is not an automatic remedy for cutover delay.
Stage four: use the observations to adjust future retention and, in the lifecycle design, tier rules. Keep weekly spot checks and monthly full restores as an illustrative starting rhythm, with retests after relevant changes. Record supported MFA device/access procedures and approval owners without copying secret values into the runbook. Extending retention is different from shortening an already protected compliance version.
Finish the trial only when the recorded acceptance checks pass and remaining gaps have owners. A successful small drill is evidence about that tested path, not a guaranteed recovery time for every workload. Expand coverage across data types and storage classes, keeping the oldest required clean recovery point usable.
Review Compliance Retention Before Expanding It
Use established recovery and retention requirements to decide which sets need compliance mode. Monthly archives, critical snapshots or regulated records may qualify, but the data label alone does not decide the duration. Include cost, key access, required log chains and tested retrieval. While retention is active, a mistaken long period cannot be shortened by a user.
A hybrid design can keep selected versions in compliance and others in governance, using appropriate buckets or explicit supported per-version settings. Promotion should follow verified requirements and tests. Do not treat governance as permission for daily automation to bypass the lock; restrict those exceptional operations separately.
Connect Backup Protection to Operations
Harden administrative entry points and limit where AWS credentials can be used. Where suitable, mTLS adds a client-certificate requirement at an administrative edge, but it does not replace authentication, authorization or backup controls. Apply the same principle of deliberate, auditable access to backup and key administration.
For WordPress, include the database, uploads, matching themes/plugins and configuration. For Laravel, include persistent storage, the database, deployment version and recovery access to environment secrets. A rapidly recreated container stack can still lack its data or keys. Test business actions in a sandbox without sending real charges, emails or webhooks.
Record which backup/version restored, which role and key were used, archive delay, missing dependencies and the last consistent recovered point. If file and database recovery points differ by five minutes, verify whether the combination is application-consistent instead of relying on timestamps alone. Review the strategy, for example every six months and after major changes; this review does not replace weekly/monthly restore exercises.
Use Drills to Find Concrete Gaps
In one hypothetical drill, some uploads lack explicit retention but are covered by the intended bucket default; verification should prove that coverage rather than assume it. In another, the replica exists but the recovery role cannot decrypt it. Both are reasons to check version-level state and actual recovery access before relying on the copy. No fixed repair time follows from these examples.
A controlled simulation can test whether a narrowly scoped writer role is denied permanent deletion and governance bypass on noncritical retained versions. Define authorized test targets and stop conditions first. Also test whether the role can still complete valid backups and whether attempts reach the configured logs. Do not infer complete ransomware resistance from a few denied requests.
Start With One Proven Recovery Point
Select one consistent backup set, preserve its required versions with the intended lock settings and verify the recovery role’s access to data and keys. Restore into an isolated environment and complete meaningful application checks. Document the chosen lifecycle or MFA Delete workflow, replica coverage and any remaining gaps before expanding.
Schedule weekly spot checks and monthly full service restores as an example rhythm, adjusted to your workload. Rotate through recovery points and classes, record elapsed time and data consistency, and retest corrections. A usable runbook connects these results to owners and agreed recovery objectives.
