Data Recovery · October 23, 2026 · ComputerKing Team

Backup Is Not Recovery: Restore Tests and Immutable Backups

Backup success does not prove you can restore. This guide covers restore testing, immutable backups, phone, photo, NAS and key traps, and audit checklists.

Summary

Backup success does not prove you can restore. This guide covers restore testing, immutable backups, phone, photo, NAS and key traps, and audit checklists.

Introduction: what Part 1 already covered, and what Part 2 will not repeat

The previous article covered the 3-2-1 rule: three copies, two media types, one copy offsite. It covered Time Machine setup, and the difference between sync and backup. If you have not read that article, read that article first for the foundations; this article will not repeat each point in detail.

This article answers one question, the question Part 1 left open: how do you know a backup really restores?

Consider the following hypothetical scenario, given as an illustration only and not a real case: imagine a user whose backup job runs every night and always reports "completed". One day the computer hard drive fails. Confidently, the user reaches for the backup, only to discover that the backup disk filled up three months ago and every job since then failed silently. Even for the older files that survived, the encrypted backup password was written inside the very computer that just failed. The backup job showed green every day, yet on disaster day the whole restore chain turned out to be broken in several places.

This situation has a name: the "Schrödinger backup". Until you have actually tried a restore, the state of a backup is unknown. An untested backup is only an expectation, not a guarantee. This article shows how to turn that expectation into something verified.

Section 1: Four layers of restore testing, from shallow to deep

Restore testing is more than "the file opens". A proper test has four layers, and each layer checks something different.

Layer 4 is the one most often skipped, yet it matters most. If a machine failed because of ransomware, restoring from a backup that is already contaminated only restores the problem again. So never restore directly on an infected machine: first isolate the machine from the network, scan it, and confirm the restore point itself is clean before restoring.

The pass checklist: one test must cover all of these

A restore test must not stop at "the file came back". The following checklist must all pass:

1. Scope: the restored items are correct and the coverage is complete, with no folder missed.

2. Integrity: files open, databases mount, and hash or application checks pass.

3. Bootability: for image-level restores, the system must boot inside the isolated sandbox network (not the production network), and core services must start with sandbox networking connected.

4. Restore point: the newest restore point must be within the RPO. If the RPO is 4 hours but the newest restore point is from yesterday, the test has failed; it is not "roughly fine".

5. Restore time: time from the moment the restore is decided until the system is usable again, measured against the RTO. Note: measure the actual restore time, not just the time a backup job takes to finish.

6. Access: encryption keys, credentials, and passwords must all be available. If a key is lost, a backup in perfect condition still cannot be opened.

7. Cleanup: test virtual machines must be shut down and deleted to avoid IP conflicts or licensing problems; test copies must not be left behind as a second data-leak channel.

Tests must run in an isolated network or sandbox, never by restoring a server directly on the production network, or the test itself can become an incident.

Rhythm: sample every quarter, rehearse every year

The minimum workable rhythm for home users and small offices is:

• At least one sample restore every quarter: randomly pick a few old files, a few photos, and one folder, restore them to a different machine or a different folder, and count it only if they open.
• At least one full restore rehearsal every year: restore a whole machine or a whole NAS data set to a standby device, and time it.
• Immediately after every change of backup tool, NAS, or cloud service.
• A successful restore 18 months ago proves nothing about today's environment. Settings, permissions, and encryption keys all drift, so testing must continue.

That is the minimum: home users sample every quarter; small offices run component tests monthly, a sample review every quarter, and a full rehearsal every year.

Every test must be logged: test date and time, scope, actual restore time against RTO, actual data loss against RPO, pass or fail, root cause of any failure, remedial action and deadline. A test with no record is, when disaster strikes, as good as no test at all.

Section 2: RTO and RPO in brief, and how to use checksums

RTO (Recovery Time Objective) is the target time from an incident until the system is usable again. RPO (Recovery Point Objective) is the maximum amount of data, measured in time, that may acceptably be lost — that is, how old the newest restore point may be. Both targets must be set per workload, not as one number for the whole company, and they must be reassessed after every major platform change.

For integrity checking at file level, the method is simple: compute a SHA-256 hash when writing the backup, compute it again later, and a mismatch means the file is damaged, the media has aged, or the file was tampered with. Home users can generate a hash list for important folders with `sha256sum` and compare it regularly. Two points matter: first, MD5 is only suitable for damage detection, not for protection against deliberate tampering, so general users should use SHA-256; second, the checksum list must be stored separately from the backup, for example on another machine or under different access permissions, or an attacker who alters the backup can also alter the checksum and hide the tampering.

The strongest verification method is still a test restore into an isolated environment, starting the application to confirm it works normally. Scheduled verification jobs and synthetic restore tests can turn this into a routine instead of a once-a-year event.

Section 3: Immutable backups — the last two digits of 3-2-1-1-0

Part 1 covered 3-2-1. Part 2 adds the last two digits: 3-2-1-1-0. That is 3 copies, 2 media types, 1 copy offsite, plus 1 offline, air-gapped, or immutable copy, and finally 0 errors — meaning every backup has been verified by automated checks and tested as restorable.

Why are the last two digits the critical ones in the ransomware era? Because modern ransomware does not only encrypt your files; it deliberately hunts down your backups to delete them. According to figures from the Veeam 2025 survey of respondent organisations, 89% of attacked organisations said their backup repositories had been targeted by attackers, and only 32% of organisations used repositories configured as immutable. These figures come from a vendor survey report via secondary sources; the sample is respondent organisations, not all companies in Hong Kong or worldwide. The direction, however, is clear: a backup an attacker can delete is not a defence.

The core of an immutable backup is WORM (Write Once, Read Many): the storage system attaches a "retain until" date to each restore point, and before that date it refuses any delete or overwrite request.

S3 Object Lock: Compliance versus Governance

Amazon S3 Object Lock has two retention modes. Where this article cites them, the AWS global documentation is the authority:

There is also Legal Hold: it has no fixed expiry date and is independent of the retention period. While a legal hold is in place, the object stays protected even after the retention period expires.

Practical points: Object Lock must be used together with versioning, and once enabled for a bucket it cannot be disabled, nor can versioning be suspended. The unit of protection is an object "version", not an object key: a delete request only adds a delete marker, while the locked version itself remains. Backblaze B2 Object Lock follows the same WORM model: under Compliance mode, nobody can edit or delete a file during the retention period, while under Governance mode a user holding special permission can bypass retention; see Backblaze's official documentation for details. It also offers a Legal Hold option. B2 also supports server-side encryption, with either provider-managed keys or customer-managed keys, both AES-256 (an encryption standard).

Synology immutable snapshots: the closest local option for Hong Kong small businesses

Synology's official blog states that most ransomware attacks now target backup repositories, and a backup an attacker can delete is not a defence. Synology's immutable Snapshot Replication creates WORM copies that nobody can modify or delete even when logged in with stolen administrator credentials, with the protection period set by the user.

In setup terms, enable immutable snapshots in the Snapshot Replication snapshot settings, set a protection period, and Synology DSM (the system management interface) will refuse to delete snapshots within the protection period; while a protected snapshot is in use, the shared folder cannot be deleted or moved to another volume. There is also a separate WriteOnce shared-folder feature: under both modes administrators cannot delete locked files, and Compliance mode additionally prevents administrators from deleting the shared folder, volume, or storage pool. Availability depends on model; this article names no models, and details should be checked against Synology's official documentation.

How long should the retention period be? Three sources use different figures, and they must not be merged into a single "standard answer": a third-party guide suggests at least 14 days, on the grounds that ransomware may lie dormant for days before activating and too short a window lets clean restore points expire; a third-party summary of Backblaze B2 says 30 days generally covers the gap between intrusion and discovery; and the CISA guidance cited in Part 1, via a third-party summary, says backups should reach back at least 7 days. The principle is simple: the longer the window, the safer, and the higher the storage cost. Set it from how long you typically need to discover a problem, and never shorter than your average time to notice something is wrong.

Air gaps: low-tech, but effective as the other half

An air gap has a simple definition: when a backup is not being made, it is physically disconnected. The simplest method is rotating two external hard drives: plug one in only while backing up, unplug it and lock it away as soon as the backup finishes, so that at any moment at least one drive is not in the office and not connected to an infected network.

Another method is a "pull-based" backup: a separate backup machine logs into the NAS to copy data, while the NAS itself holds no key to the backup machine, so an attacker who compromises the NAS cannot reach the backup.

Remember: a local snapshot is only a convenient rollback, not the last line of defence. An attacker with root privileges can delete ordinary snapshots; the true last line of defence is one of three options: an immutable snapshot, cloud Object Lock, or a rotated offline drive. You do not need all three; any one of them works, as long as at least one copy exists that an attacker cannot touch. An ordinary (non-immutable) snapshot does not count as the last line of defence; it is only a convenient rollback.

Section 4: The limits of immutable backups — do not present them as magic

Immutable backups are useful, but they have four limits, and an honest article must state them all.

First, a locked copy only protects versions that were already copied; it cannot repair data that was already encrypted before the backup. Keep several old versions spaced weeks apart; never keep only the newest copy.

Second, slow poisoning. Ransomware can interfere with the backup process so that future copies are themselves contaminated, then wait for old clean copies to expire, leaving the victim with no clean restore point. The countermeasures are a retention period longer than the dwell time, plus regular verification that restore points are clean — that is, the Layer 4 re-infection scan from Section 1.

Third, the backup software itself can become an entry point. According to third-party summaries of Mandiant's 2025 case analysis, attackers have targeted backup software to steal credentials from backup configuration databases, and in some cases deleted backup volumes before encrypting. Percentages from that analysis were not verified against the original report, so this article cites no figures here, but the lesson is real: do not only protect the storage layer. Backup software itself must be updated, must use separate credentials, and must use multi-factor authentication (MFA).

Fourth, the identity boundary problem. If a backup server joins the same domain and uses the same domain account as the backup service account, compromising the domain means the restore path can be destroyed too. Backup encryption prevents snooping, but if an attacker obtains the key through the same identity path, encryption at rest does not help either. Backup systems should therefore use separate credentials plus MFA, and never share the everyday domain administrator account.

The cloud account-layer risk is the same: according to reports, one attack on an Azure environment used a service principal password leaked in a public issue to break in, then deleted the vault holding passwords and encryption keys, while also trying to remove the locks protecting Azure Backup and Azure Site Recovery. The lesson is: backup keys and the backup itself must not sit in one account or vault that a single set of credentials can delete in one go.

There is also a classic lesson, old in years but identical in failure mode to this day: the 2014 Code Spaces incident, in which an attacker entered the company's cloud console and deleted snapshots, storage buckets, and machine images, and the company closed the next day. The incident itself was extortion rather than file-encrypting ransomware, but the point is the same — when backups and production share one access path, they can disappear together.

Section 5: Phone backup traps — what you think is backed up may not be

A phone is often the only copy of recent photos and messages, yet phone backup coverage is far narrower than the "whole phone is backed up" picture many people carry in their heads.

iPhone: iCloud Backup does not include content already synced

Content already in iCloud is not included in the backup again. iCloud Backup excludes data already synced to iCloud, such as iCloud Photos, iCloud Drive files, and iCloud Mail; computer backups likewise exclude data already in iCloud, content synced from a Mac or PC, and Apple Mail data. Neither backup type includes Face ID or Touch ID settings or Apple Pay data; apps themselves are not backed up and are re-downloaded from the App Store on restore.

Encryption must be kept straight: iCloud Backup is encrypted by default, with Advanced Data Protection available as an option for end-to-end encryption; computer backups are not encrypted by default and require the user to tick encryption manually. Health data and saved passwords in Keychain appear only in an encrypted computer backup; an unencrypted computer backup does not include these categories, while iCloud Backup includes them automatically.

A misunderstanding worth dismantling: "turning on iCloud Photos means my photos are inside my iPhone backup" is wrong. With iCloud Photos on, photos sync through iCloud Photos and no longer count as part of the device backup. To back photos up to a computer, transfer them separately, or first make sure originals have downloaded to the device (choose 'Download and Keep Originals') and then turn off iCloud Photos and make a full computer backup. Also note that iCloud Backup cannot restore app by app; a restore restores the whole backup at once.

One macOS change to note: from macOS Tahoe 26, Time Machine backups to an AirPort Time Capsule show a warning that the next major version will no longer support them; macOS 27 removes the AFP client entirely, and since a Time Capsule needs AFP or SMBv1 (network file-sharing protocols) while Time Machine backups now use only SMBv2 or SMBv3, a Time Capsule can no longer serve as a Time Machine destination at all. Users still on a Time Capsule need to move to an external drive or a modern NAS. Note also that a third-party guide has claimed NAS backup problem reports increased after the Tahoe upgrade; that claim has not been verified by official or independent statistics, so this article only advises readers to confirm NAS support for SMB3 before upgrading, and cites no failure-rate figure.

Android: the 57-day rule is the easiest trap to fall into

Google One backup includes app data and settings, SMS, call history, device settings (including Wi-Fi passwords and display settings), and contacts; photos and videos need a separate Google Photos backup. MMS coverage differs across sources, depending on device model, carrier, and subscription status; go by what the device itself shows, and do not state flatly that MMS is always or never included.

Two traps must be known, both stated by Google Support itself:

1. The 57-day rule: if a device goes unused for 57 consecutive days, the backup data in Google Drive (except photos and videos in Google Photos) is automatically deleted. An old phone kept in a drawer as a spare, or a new phone left unconfigured after a switch, can both fall into this trap. Turning off backup also deletes the backup (except Google Photos photos).

2. Storage counting policy: there are reports that Google changed policy so that all Android backup data counts against the free Google account storage limit, whereas previously only photos, videos, and MMS media counted. The effective year and the details for Hong Kong users have not been verified directly against an official page, so this article only says "there are reports", and asks readers to check their own account on the Google One storage page rather than presenting it as a verified official term.

Further limits: a backup made with a newer Android version cannot be restored to a device running an older Android version. On encryption, backups are uploaded to Google and encrypted with the Google account password, with some data additionally end-to-end encrypted using the device screen lock PIN, pattern, or password; Google Photos photos and videos and carrier MMS media are not encrypted with the device screen lock.

WhatsApp backup: not end-to-end encrypted by default

End-to-end encryption of everyday chats does not automatically mean the backup is end-to-end encrypted. Without end-to-end encrypted backup turned on, a WhatsApp backup sits in Google Drive (Android) or iCloud (iOS), where the cloud provider can read its contents. End-to-end encrypted backup, launched in 2021, is opt-in, not the default; once on, neither WhatsApp nor the backup service provider can read the backup or its encryption key. The path to turn it on is WhatsApp, then Settings, then Chats, then Chat backup, then End-to-end encrypted backup.

The three unlock methods carry completely different risks:

Passkey was announced by WhatsApp at the end of October 2025 and is rolling out gradually, expected to take weeks to months; not every user gets it on the same day. Do not assume WhatsApp backups are end-to-end encrypted by default, and do not assume WhatsApp support can unlock a lost password for you, and do not assume every Hong Kong user already has the passkey feature.

One side note: a third-party tutorial says that after turning on end-to-end encrypted backup, WhatsApp chat history is excluded from a full device backup; if unsure, check in the iCloud backup settings whether WhatsApp is included.

Section 6: Photo backup — original or compressed is a choice, not a free lunch

Photo backup fails in two places: compression, and deletion spreading.

Google Photos "Storage saver" (formerly High Quality) compresses photos to a maximum of 16 MP and video to 1080p. It saves space but permanently loses detail. The "Original quality" option preserves full resolution and quality and counts against Google storage. iCloud Photos preserves originals by default with no compression, including RAW; "Optimise Storage" only keeps a smaller version on the device, while the original stays in iCloud. iCloud itself has no compression option, so cloud space cannot be saved by compressing.

The practical point: shooting 48 MP ProRAW or 4K 60fps video and then using Storage saver means compression permanently removes detail and dynamic range, and the difference will show when enlarging for print or professional editing. Saving space and preserving originals is a choice between two options; do not claim "compressed is just as good".

The second failure is sync propagation: cloud photo sync spreads a deletion to all devices, so deleting one photo by mistake removes it everywhere after syncing. A real backup needs version retention or a second independent copy. Deletion-recovery windows for cloud storage services, all from third-party recovery guides and depending on plan, are: Google Drive trash 30 days, Google Photos trash 60 days; OneDrive recycle bin roughly 30 to 93 days depending on plan; iCloud Drive Recently Deleted roughly 30 days. These are "change your mind after deleting" windows, not "backup version retention"; once the window passes, the file is gone, so never describe them as unlimited.

Before choosing a cloud backup service, ask four questions: how long is version retention? How long are deleted files kept? Is restore per file or whole-account? Who holds the encryption key, and what happens if it is lost? As for service pricing, this article lists no prices at all; pricing must be checked individually against the official site.

Section 7: NAS security — a snapshot is not immutable, and certainly not offsite

A NAS is a primary copy, not a backup in itself. RAID does not protect against accidental deletion, fire, theft, or ransomware; a NAS still needs an offsite copy. Home NAS devices are often exposed to the internet with default or weak passwords, making them targets for brute force and known-vulnerability attacks; ransomware encrypts all connected storage, including external drives and mapped network drives, and can also spread encrypted files through cloud sync folders.

A snapshot is a read-only point-in-time view: while ransomware encrypts live files, earlier snapshot versions are not changed, so you can roll back to a point before infection. Btrfs snapshots are almost instant and have little performance impact, so hourly or daily snapshots are realistic. Immutable snapshots go further: during the set retention period, not even an administrator account, or an administrator account taken over by an attacker, can delete the snapshot, closing the "ransomware deletes the snapshots too" attack path.

But the hard limits of snapshots must be stated clearly: a snapshot lives on the same NAS, so if the drive pool dies, the machine is stolen, there is a fire, or an attacker with full administrator rights destroys data plus snapshots, snapshots cannot save you. A snapshot is the fastest first-line restore; it is not a substitute for an offsite backup. Both are needed.

The practical setup checklist for Synology Hyper Backup (based mainly on Synology's official pages) is:

1. Run at least two Hyper Backup tasks: one local (for fast restores) and one offsite or cloud (for disaster restores), with the offsite task using different login credentials, never shared with the everyday NAS administrator.

2. Turn on version control with custom rotation; never keep only the newest version, or an encrypted file that syncs will overwrite the only good version.

3. Turn on client-side encryption for the offsite destination, and do not keep the encryption key or password only on the NAS itself.

4. Turn on scheduled integrity checks to verify backup files are undamaged.

5. Test a restore immediately after the first backup completes, and test again regularly afterwards.

Hyper Backup destinations include local shared folders, external devices, another Synology NAS, rsync file-sync servers, and public cloud services. Features include scheduled automatic backups, multi-version backups (block-level incremental backups), custom backup rotation, deduplication, AES-256 encryption (client-side encryption, encrypted before transfer), compression, integrity check scheduling, and pause and resume after an interrupted backup.

Is a second NAS a backup? It is only one more copy; if it shares credentials, network, and location, the risks are shared too, and an independent offsite copy is still needed. NAS basics must not be skipped either: disable unneeded remote access, change default passwords, turn on two-factor authentication, keep firmware updated, and keep the backup administrator account separate from everyday production accounts.

Section 8: Key management — losing the password turns a backup into waste

Losing the password of an encrypted backup is the same as having no backup. This holds in four scenarios:

• Encrypted iPhone computer backup: forgetting the encryption password leaves Apple with no official way to unlock or restore without the correct password. Claims in circulation that resetting all settings can reset encryption settings for future backups do not unlock an old backup — an old backup without its old password still cannot be opened. "Making a new backup" and "rescuing an old backup" are two different things.
• iCloud Advanced Data Protection: this brings iCloud Backup, Photos, Notes, Reminders, Safari bookmarks, Voice Memos, Wallet passes, and iCloud Drive under end-to-end encryption, decryptable only on the user's own trusted devices; before turning it on, at least one recovery method must be set up, such as a recovery contact or a recovery key. Even with it on, iCloud Mail, Contacts, and Calendar are still not end-to-end encrypted, because they must interoperate with other mail and calendar systems. Also note that in February 2025 there were reports that Apple stopped offering this feature to new users in the United Kingdom following a government request; whether it applies to Hong Kong users has not been verified, so do not assume Hong Kong matches the UK situation — readers should check their own device settings for the option.
• WhatsApp encrypted backup: see Section 5. A lost password or 64-digit key plus a lost phone means no restore.
• Cloud backup private keys: using iDrive as an example, the private key is an optional zero-knowledge switch; once on, it is one-way, and losing the key file means no restore. Default server-side encryption has no such problem, but the provider can in theory read the files. Hyper Backup client-side encryption works the same way: without the password or key, the backup files cannot be opened even if you hold them.

Practical advice for keeping recovery keys:

1. Never keep them in only one place, and never only inside the device being backed up. Keep one copy in a password manager (with its own master password and recovery method) and one paper copy in a different location at home or in the office (for example a locked cabinet), so that fire or theft cannot take both at once.

2. Never rely on only one account. If a key lives only in a cloud note inside one Google or Apple account, locking that account locks away the key too; keep one copy reachable without that account.

3. Regularly verify you can still find the key. The monthly audit must include "confirm the encryption password or key can still be found"; do not discover on restore day that the password manager cannot be logged into.

4. Watch out for single-point recovery traps: one phone number serving as both SMS two-factor authentication and account recovery contact, one email account that itself needs that same phone to log in, or only one device set up with everything — break that single point and the whole security chain breaks.

5. Small offices: key custody needs a named deputy who knows how to retrieve and use the keys; it cannot rest with one employee only, and handover on departure must include key handover.

6. Before turning on encryption, ask yourself: "If I lose all my devices tomorrow, what method lets me get the key back?" If you cannot answer, do not turn it on yet; set up a recovery method first (recovery contact, recovery key, or password manager).

Section 9: Audit checklists — home users and small offices

The core principle is one sentence: "a backup job showing success" does not mean "it restores". Completing a backup job only proves data was written; it does not prove files open, systems boot, or applications run. Only an actual restore counts.

Home users: once a month (about 20 minutes) plus a deeper check every quarter

Monthly:

• Randomly pick one file and restore it from every backup copy, then open the file to check it opens; do not only check that the file exists.
• Check the most recent backup date, and confirm it is as new as expected.
• Confirm the offsite copy is still updating.
• Confirm you can still find the encryption password or key.
• Check remaining space on backup drives or in the cloud is enough.

Quarterly:

• Review the past 90 days of backup logs for failed or missed jobs.
• Check the retention policy is actually being met.
• Confirm the 3-2-1 positions: 3 copies, 2 media types, 1 offsite copy, plus 1 offline/immutable copy.
• Restore a whole folder to a test location and time how long it takes.
• Log failed items and fix them within the same week.

Yearly:

• Check storage will last another year (photos and video grow fastest).
• Check subscriptions have not expired, payment cards have not expired, and account login details still work.
• Check the old-device retirement list for unprocessed old machines.
• Update the emergency restore note: which accounts, which services, restore steps, and whom to contact. Do not keep it only in your head.

Small offices: a formal audit every quarter plus a full exercise every year

• Backup success notifications: any failed or silently stopped jobs in the past 90 days? If nobody reads the notifications, a backup can stop for weeks unnoticed and only surface when disaster strikes.
• Retention policy compliance: does the retention period match company policy?
• Offsite plus immutable copies: is the offsite copy truly offsite (different location, different credentials), and is the immutable lock longer than the time you need to discover a problem?
• Restore testing: run component tests monthly, a sample review every quarter, and a full rehearsal every year, with the seriousness of a fire drill; test restores must go to a different location and never overwrite the original.
• Permission checks: who can delete or change backups? The backup administrator account must be separate from the everyday production domain, with multi-factor authentication on; everyday work accounts must not be able to wipe backup history.
• Encryption key retrievability: keys and backup console login details must not live only inside the protected scope — if production is lost, the keys go with it.
• Restore time records: every test restore must be timed from the moment the restore is requested, not from when copying starts; record both RTO and RPO.
• Documentation: restore steps must be written down, not known by one person only; if the usual person is on leave or unreachable, someone else must be able to do it.
• Post-restore checks: match file counts, sizes, and hash values, open sample files, and ask the system owner to run an application smoke test (log in, open recent records, produce one report); test copies used for the restore must be deleted or locked away, not left as a second data-leak channel.

Yearly: one full exercise restoring a tier-one system (or the most important data set) from an immutable or offsite copy, timed and logged; check backup storage and subscription contracts and whether retention policy still fits the business; check departed employees' devices and accounts have been handled; record the "last successful full restore date" and the "next test date" in the calendar.

Old-device retirement checklist (before selling, giving away, recycling, or scrapping, in this order)

1. Back up first, verify before wiping: confirm photos, contacts, messages, notes, authenticator codes, and app data are backed up, and verify from another device by opening the photo album or files; the cloud backup's "most recent backup" time must be new, not just felt to be new.

2. Move two-factor authentication: authenticator app codes usually do not travel with a cloud backup; move them on the old device by transfer or QR code scan to the new device first. Skipping this step makes logging into bank or work accounts very painful later.

3. Sign out of all accounts and remove device locks: sign out of Apple ID, Google account, email, social, cloud storage, and subscription services; turn off Find My device features, or Activation Lock (iPhone) or Factory Reset Protection (Android) will trigger, leaving the next owner unable to use the device and your account still tied to it.

4. Remove physical cards: SIM cards, microSD cards, USB receivers; eSIM needs the carrier transfer process first, since a factory reset does not necessarily cancel mobile service.

5. Factory reset and verify the setup wizard screen: only count it complete when you have seen the device return to its first-time setup screen with your own eyes.

6. Computers follow the same logic: back up everything first, sign out of accounts, deauthorise software, reset the system, and confirm the setup wizard.

7. Devices that cannot be wiped (broken machines, machines with company-sensitive data): do not recycle them directly; consider physical destruction and ask for a destruction certificate.

Section 10: When the backup itself fails — what to do, in order

Case 1: The backup drive fails

1. Do not format it immediately, and do not keep plugging and unplugging it for write tests; write operations may make things worse.

2. First confirm the other copies: the offsite copy, the cloud copy, and the other drive in the rotating offline set — which is newest, which is complete.

3. Restore from the most complete copy to a brand-new destination, never overwriting the original directly.

4. After restoring, open sample files to verify, and only then count it done.

5. Only then deal with the failed drive: add a new local copy so the 3-2-1 positions are complete again.

Case 2: Backup files are damaged, or a restore fails halfway

1. Compare against the hash list to confirm which files are damaged and which are intact; replace damaged files from another backup known to be good, and verify that backup itself is undamaged before replacing.

2. If backup software stopped silently (for example a system update, expired credential, or background permission change stopped backups for months), fix the schedule and credentials first, then make a full backup; do not assume the old schedule will recover by itself.

3. For problems like Windows File History not recognising a drive, the general point is that in 2026 there was a Windows update after which File History failed to recognise drives, and users had to press run-now manually to confirm backups were actually running; specific update numbers should be checked against Microsoft's official update catalogue, and this article cites no unverified numbers.

4. If infection is suspected, never restore directly on the original machine: isolate first, scan, confirm the restore point is clean, then restore into a clean environment.

Case 3: The account is locked, and cloud backup and originals are unreachable together

Be clear about the evidence here: the research round found public cases of a shared access path (Code Spaces) and leaked account credentials (the Storm-3168 reports), but found no named public case of "account lock causing cloud backup and originals to become unreachable at the same time". This section therefore describes mechanism risk only and invents no case.

The response order is:

1. First use the account's own official recovery flow (recovery contacts, recovery keys, backup verification methods) to regain the account; do not stake everything on a single recovery path.

2. At the same time, restore from a copy that does not depend on that account: a rotated offline drive, an offsite copy on another NAS, or a key kept on paper plus in a password manager.

3. After restoring, immediately check the single-point recovery traps: is the key only inside that account's cloud notes? Is two-factor authentication tied to only one phone? Is there a second person who knows the whole process?

4. After fixing, write "not dependent on a single account" into the audit checklist so it becomes a quarterly check.

Common misunderstandings at a glance

FAQ

Q1: What is the difference between a restore test and a backup job showing "completed"?

A backup job showing "completed" only means files were copied; it does not mean they can be restored. A restore test actually restores files, opens them for checking, and compares the restore point and restore time, proving the whole restore chain works. An untested backup is only an expectation until it is proven restorable.

Q2: How much restore testing does a home user need at minimum?

The suggested minimum is one sample restore every quarter (randomly pick a few old files, a few photos, and one folder, restore them to a different machine or folder, and count it only if they open), one full restore rehearsal every year (a whole machine or a whole NAS data set restored to a standby device, timed), and one test immediately after every change of backup tool, NAS, or cloud service.

Q3: What do the last two digits of 3-2-1-1-0 mean?

3-2-1-1-0 extends 3-2-1: 3 copies, 2 media types, 1 copy offsite, plus 1 offline, air-gapped, or immutable copy, and finally 0 errors, meaning every backup has been verified by automated checks and tested as restorable. The last two digits are the critical ones in the ransomware era, because attackers deliberately delete backups they can delete.

Q4: What is the difference between S3 Object Lock Compliance mode and Governance mode?

Under Compliance mode, no user can overwrite or delete a protected object version during retention, including the account root user, and the retention period cannot be shortened. Under Governance mode, ordinary users cannot overwrite, delete, or change lock settings, but a user holding special permission who explicitly sends the bypass header can bypass retention. The practical approach is to rehearse retention settings in Governance mode first, then switch to Compliance mode for live operation.

Q5: Does turning on Synology immutable snapshots solve everything?

No. Immutable snapshots do not protect against hardware failure or physical loss, and are not the same as compliance retention; snapshots on the same NAS, however immutable, cannot replace an offsite copy. The retention period must also be long enough to cover the gap between intrusion and discovery, or clean restore points will expire before the problem is found. Model and feature availability should be checked against Synology's official documentation.

Q6: Are WhatsApp backups end-to-end encrypted by default?

No. End-to-end encryption of everyday chats does not automatically mean the backup is end-to-end encrypted; end-to-end encrypted backup is opt-in, not the default. Without it, the backup sits in Google Drive or iCloud, where the cloud provider can read its contents. Once it is on, losing the password or 64-digit key plus losing the phone means the backup cannot be restored; passkey is a new method that began rolling out gradually at the end of October 2025, and not every user gets it on the same day.

Q7: If an Android phone sits in a drawer for months, will its old backup disappear automatically?

Yes. According to Google Support, if a device goes unused for 57 consecutive days, the backup data in Google Drive (except photos and videos in Google Photos) is automatically deleted; turning off backup also deletes the backup (except Google Photos photos). A spare phone in a drawer, or a new phone left unconfigured after a switch, both need attention to this rule.

Q8: If I lose the password of an encrypted backup, can the vendor unlock it for me?

No. Encrypted iPhone computer backups, WhatsApp encrypted backups, and iDrive private keys cannot be opened without the password or key, and vendors have no official way to unlock them without the correct password. Keys must therefore be stored separately: one copy in a password manager, one paper copy in a different location, and neither copy dependent on a single account to reach.

Q9: If photos were compressed with Storage saver, can the originals be recovered later?

No. Storage saver compresses photos to a maximum of 16 MP and video to 1080p, permanently removing detail and dynamic range, and the difference will show when enlarging for print or professional editing. Saving space and preserving originals is a choice between two options; think before turning compression on.

Q10: If a backup drive fails or an account is locked, what should I do first?

First confirm the other copies; do not format a failed drive immediately or run repeated write tests on it. Restore from the most complete copy that does not depend on the failed account, to a brand-new destination, verify sample files, and only then restore the 3-2-1 positions and fix single-point recovery traps. If infection is suspected, isolate first, scan, confirm the restore point is clean, and only then restore into a clean environment.

Q11: What are RTO and RPO, and how do they differ?

RTO (Recovery Time Objective) is the target time from an incident until the system is usable again; RPO (Recovery Point Objective) is the maximum amount of data, measured in time, that may acceptably be lost — that is, how old the newest restore point may be. In short, RTO answers "how soon can we work again", and RPO answers "how much data may we lose at most"; set both per workload, as explained in Section 2.

Q12: Before selling or giving away a device, what counts as a safe backup?

Follow the retirement checklist in Section 9, in order: back up first and verify from another device before wiping; move authenticator codes to the new device; sign out of all accounts and turn off Find My features; remove SIM cards, microSD cards, and other physical cards; factory-reset and confirm with your own eyes that the setup wizard appears. Devices that cannot be wiped should not be recycled directly; consider physical destruction and ask for a destruction certificate.

Conclusion

In short: a backup job is not proof of recovery — verify the restore chain with four layers of testing; keep an immutable copy plus an air gap so attackers cannot delete the last copy; avoid phone backup and key traps, and do not discover a lost password only on restore day; home users should sample every quarter, small offices should run component tests monthly with a quarterly sample review, and everyone should rehearse fully once a year.

Need help? Call +852 2115 9219 for enquiries; charges require individual quotation.

Related articles

• Hong Kong Backup Strategy Guide: The 3-2-1 Rule Done Properly — Time Machine, Windows, Cloud and Offline Drives

• How to choose, set up, and back up a home or small-office NAS: RAID, 3-2-1, and remote-access security guide
• Deleted iPhone photos or lost WhatsApp chats? A complete iCloud and computer backup restore guide
• What to do when a NAS fails? A complete Synology/QNAP data recovery guide

Sources

All sources were consulted on 2026-10-21, at search-summary level only; verify key figures against the original text before citing them.

• Provaltech — restore testing checklist, isolated sandbox, tiered frequency, RPO as a hard metric
• ThinkOn — why a disaster recovery plan needs regular testing, four test types, re-infection scanning
• Beefed.ai — Tier 0 to Tier 3 tiering suggestion (third-party consultant framework, not an industry standard text)
• SyncroSecure — risk-tiered frequency, test report contents, 18-month-old test invalidity
• DCHost — quarterly restore to staging, timing from restore decision against RTO
• AvePoint — RTO and RPO tiering, restore testing beyond backup jobs, 3-2-1-1, automated verification
• TrainingCamp — backup integrity verification definition, SHA-256
• Medium — checksum files must be stored separately from backups (personal technical article, general principle)
• AWS documentation — S3 Object Lock modes, Legal Hold, version unit, disabling limits
• Backblaze — B2 Object Lock WORM, Legal Hold, server-side encryption AES-256
• Backblaze documentation — Veeam connecting to B2 with immutability
• Retrospect — immutable retention settings on Backblaze B2
• Synology official blog — immutable backup, backups under attack, Microsoft 365 shared responsibility
• Synology Hardening — immutable snapshot settings, shared-folder limits during protection
• Veeam blog — offsite, air-gapped, immutable, recoverable as four distinct properties, 2025 report
• ObjectFirst — Veeam 2025 report secondary summary
• TechEdt — Veeam 2025 report secondary summary
• Secuna — backup software as an attack path, Mandiant 2025 case summaries, older data summaries
• Vinchin — WORM mechanism, slow poisoning, Code Spaces secondary summary
• dev.to — backups as an identity problem, separate credentials plus MFA
• RiseTechs — Storm-3168 Azure case, third-party summary
• Proton — World Backup Day story collection (stories as collected, not verified cases)
• Medium — Schrödinger backup, silent backup failure, sync is not backup
• Managed Nerds — rotating offline drives, 3-2-1 backup rule
• dev.to — 3-2-1-1-0, pull-based backup, separate credentials plus MFA
• How-To Geek — 3-2-1-1-0 definition
• DM System — 3-2-1-1-0, Veeam immutable storage targets
• iFeelTech — 14-day suggestion (third-party suggestion, not an official minimum)
• iFeelTech — immutable snapshot limits, WriteOnce distinction (third-party comparison)
• Homelab Pulse — local snapshots can be deleted, pull-based backup, locked copies do not repair already-encrypted data
• ScalaHosting — B2 Governance and Compliance trade-offs, retention range (third-party summary)
• MacRumors — macOS 27 ends Time Capsule
• MacRumors — macOS 27 removed features, Intel Macs stop at Tahoe
• 9to5Mac — macOS Tahoe 26 Time Capsule warning
• Google Support — Android device backup: 57-day deletion, turning off backup deletes it, encryption notes
• Samsung Support — Google One backup for Galaxy phones: 57-day rule, newer backups cannot restore to older versions
• Synology official site — Hyper Backup features: destinations, scheduling, multi-version, AES-256, integrity checks
• Synology document — backup solution guide: Hyper Backup destinations, pre-transfer encryption
• Symaro — iCloud backup versus computer backup comparison
• Softorino — how to back up an iPhone without iCloud
• PC Build Advisor — backing up an iPhone to a PC, step-by-step guide
• Gadgets360 — WhatsApp passkey encrypted chat backup
• Republic World — WhatsApp passkey encrypted backup gradual rollout
• WebProNews — WhatsApp backup blind spot: unencrypted backups readable by cloud providers
• iDownloadBlog — end-to-end encrypted WhatsApp backup tutorial
• MultCloud — Google Photos versus iCloud: original versus compressed
• How-To Geek — Google Photos lowering photo quality warning
• Newscast — 3-2-1 backup rule and ransomware
• CyberFortress — is a NAS enough for backup and ransomware protection
• EveZone — NAS snapshots: point-in-time recovery and ransomware protection
• NinjaOne — how to run a quarterly backup audit
• CheckFlow — backup verification checklist
• Small Business IT Support London — the 3-2-1 backup rule for small businesses
• dev.to — the 3-2-1 backup rule, a practical guide for people and small teams
• CBL Tech — cloud storage deleted-file recovery windows
• BuyCellFix — erasing data before resale
• Total Security — disposing of a phone without forgetting to clean it
• RedSecureTech — wiping an old phone or computer before selling
• Community Pumpic — is there a way to unlock an encrypted backup without a password
• Aivanet — Apple pulls Advanced Data Protection for new UK users, report
• WunderTech — Synology Hyper Backup tutorial
• Cloudwards — iDrive versus Backblaze comparison (third-party comparison; prices unverified and not cited in this article)