Backup is not sync—and that is sometimes the point

The cloud icon next to a file feels reassuring. It suggests that the file exists somewhere else and will return when needed. But “somewhere else” can describe several very different systems. A synchronized folder, an incremental backup, an archive, and a selective recovery copy may all display a cloud while promising different behavior.

The distinction is not academic. If you delete the wrong file, does the deletion propagate? If ransomware rewrites a folder, are clean historical versions retained? If a laptop disappears, can you rebuild the library? If you edit on a second device, which version wins? You cannot answer those questions from the presence of a second copy alone.

Three tools, three primary jobs

Sync is designed for continuity. Its job is to keep selected locations aligned so that current files are available across devices or collaborators. Changes—including renames and deletions—often propagate. Conflict handling and version history may soften mistakes, but the central promise is sameness.

Backup is designed for recovery. Its job is to preserve enough independent state to restore data after loss, damage, or an unwanted change. Good backup systems define retention, version history, deletion policy, and a restoration process. A backup may run continuously, but it should not simply mirror every mistake without a way back.

Archive is designed for retention. Its job is to preserve a record that is no longer changing frequently. Archives may be offline, append-only, or managed according to legal and organizational rules. An archive is not automatically a backup of current work, and a backup is not automatically a well-governed archive.

Ask what failure the second copy is meant to survive. “It is in the cloud” is a location, not a recovery plan.

Test the words with scenarios

Product vocabulary is inconsistent, so test any service against concrete events. Start with accidental deletion. In a sync system, the disappearance may be copied everywhere. A trash or version-history feature could allow recovery, but only within its retention window. In a backup system, the expected behavior is that a retained state remains available even after the primary copy vanishes.

Next consider unwanted modification. A document is overwritten with a bad edit, or malicious software transforms many files. Current-state sync distributes the transformed files efficiently. Recovery requires previous versions or a separate backup whose history is not immediately replaced.

Now consider device replacement. Sync may reconstruct the latest synchronized set after sign-in. That is useful continuity, but local-only files, application state, excluded folders, and unsynchronized changes may be absent. A device backup may restore more context. A selective file backup may restore only the items you deliberately included.

Finally, consider work on several devices. A selective encrypted backup may place recoverable objects in remote storage without allowing live editing on another Mac. That is not a broken sync feature; it is a different promise. The problem begins only when the product or the user describes recovery storage as though it were continuous multi-device mirroring.

Privacy changes the design

For private files, a remote copy adds another security boundary. You need to know whether file content is encrypted before transfer, who controls the keys, which metadata remains visible, and what happens during restoration. A provider may need account and billing information even when it cannot read the file payload. Names, sizes, timestamps, and access patterns may receive different protection from content.

Encryption also raises the cost of lost credentials or damaged key material. A recovery system that cannot decrypt is not a recovery system. Store required secrets in a way that survives the loss of the original Mac. At the same time, avoid scattering recovery keys in unprotected notes or email drafts. The correct method depends on your threat model, but the decision must be explicit.

Selective backup can be a privacy advantage when only some Vaults or files need an off-device copy. It can also create a coverage risk: the files you forgot to select are not protected from device loss. Clear status and periodic review matter as much as the encryption algorithm.

What selective encrypted backup means in DeskVault

DeskVault treats iCloud as an encrypted recovery location for selected Vault content. Backup eligibility is chosen rather than assumed. The stored object remains encrypted, and the application includes behavior for restoring missing local files. The intended workflow is recovery, not editing the same Vault from several devices in real time.

This distinction affects expectations. Adding an item to a backup set does not promise that every Mac will immediately display a current editable copy. Deleting or moving a local file should be evaluated through the documented restore behavior, not through assumptions imported from a synchronized folder. Separate Vaults can carry different choices: a replaceable media collection may remain local, while irreplaceable personal documents receive an encrypted recovery copy.

Build a recovery plan in four questions

1. What event are you preparing for?

Name the event: accidental deletion, failed SSD, lost Mac, corrupted library, stolen credentials, or a regional disaster. Different events require different independence. A second folder on the same drive does not survive drive failure. A synchronized remote copy without history may not survive mass deletion. A local external disk in the same bag may not survive theft.

2. How much history do you need?

Current files may be enough after hardware loss. They are not enough after you discover a mistake made three months ago. Decide how long prior versions or deleted items must remain available. Check whether the service’s retention window matches that need and whether storage limits silently remove older states.

3. What must remain private?

List the data and metadata that the recovery location should not expose. Confirm when encryption happens and what credentials are required to restore. Remember that the restored readable copy will again depend on the destination device’s security.

4. Who can perform the restore?

A plan that only works when you remember a rarely used password is fragile. Use a password manager or another appropriate recovery method. If a trusted person may need access during an emergency, document the process without casually revealing the content itself.

Run a small restore drill

Use synthetic or non-sensitive sample files for the first test. Include different sizes and types if the system handles them differently. Record the time of backup, confirm status, and then follow the supported method for simulating a missing local file. Restore it to a clean location and verify that it opens and matches the original.

During the drill, pay attention to ambiguity. Did “uploaded” mean safely retained? Was the copy encrypted before leaving the device? Did restoration preserve the expected name and metadata? Could you tell which version was current? Were there warnings that would be easy to miss during an emergency?

Repeat the drill after major changes: a new Mac, a new account, a significant application upgrade, or a change in Vault location. For irreplaceable material, keep more than one independent recovery route. The familiar 3-2-1 idea—three copies, two media types, one off-site—remains a useful starting point, but independence and successful restores matter more than counting icons.

A decision matrix

Your main need	Look for	Watch for
Same current files on several devices	Explicit multi-device sync, conflict handling, version history	Deletions and corruption propagating quickly
Recovery after device loss	Independent encrypted backup and a tested restore	Unselected files and lost credentials
Recovery from bad edits	Historical versions with a suitable retention period	Short or unclear retention
Long-term records	Stable formats, retention policy, integrity checks	Assuming a live sync folder is an archive
Private selective recovery	Client-side protection, per-item choice, clear status	Metadata exposure and incomplete coverage

The best system may combine tools: full-disk encryption for the device, a working Vault for selected private files, sync for collaborative material, and independent backup for recovery. Clear roles prevent one convenient feature from being asked to solve every problem.