Five parts of a backup

  1. The data: encrypted photos, videos, files, notes, and required metadata.
  2. The encryption key: the secret that makes ciphertext readable.
  3. The recovery method: how an authorized user regains the key on a clean device.
  4. The storage service: the system holding and transporting the encrypted records.
  5. The index and metadata: identifiers, sizes, timestamps, account details, and other information needed to manage the backup.

A claim that “the backup is encrypted” is incomplete unless it explains who can obtain the key and what metadata remains visible.

Encryption does not eliminate provider visibility

A storage provider may be unable to read a properly client-encrypted payload while still observing an account, device connection, record count, approximate sizes, timestamps, network addresses, billing data, or service requests. Some metadata is necessary to operate and defend the service.

This is why local privacy and cloud resilience are separate decisions. A local-only vault reduces remote service exposure but creates a single-device failure risk. An encrypted backup adds a remote dependency but can preserve data after theft, damage, or replacement.

Recovery is the critical boundary

If the provider can reset the vault password and immediately reveal every protected file, the provider—or an attacker who compromises that reset path—has meaningful decryption authority. If only you hold the recovery secret, the provider may be unable to recover the content, but losing that secret can make the backup permanently useless.

Store recovery material offline, legibly, and separately from the phone. Do not photograph it, email it, paste it into support chat, or save it beside the encrypted backup.

A backup is not real until it restores

Test with a low-risk sample before entrusting irreplaceable content:

  1. Create a small vault with known items.
  2. Complete the supported backup.
  3. Restore through the documented clean-install path.
  4. Verify full files, metadata, and large formats—not only thumbnails.
  5. Lock and reopen the restored vault.
  6. Confirm that a subsequent backup still works.

Repeat after major app, operating-system, account, or device changes.

Deletion and retention

Deleting a local item, a vault, the app, or an account may have different effects on remote records. Providers may retain deleted data temporarily for synchronization, fraud prevention, disaster recovery, or legal obligations. Read the product's current deletion and privacy documentation rather than assuming a local gesture instantly destroys every server-side copy.

Encryption can keep retained ciphertext unreadable without the key, but key lifecycle matters. “Crypto-shredding” a key is not the same as proving every storage block has been physically overwritten.

How NullVault approaches backup

NullVault for Android creates a portable encrypted backup that you explicitly save to a compatible storage location. The exported backup remains encrypted and requires its separate backup recovery phrase.

NullVault for iPhone uses encrypted iCloud backup through CloudKit, separate from iCloud Photos. Restore depends on the appropriate per-vault recovery material and a matching authenticated backup generation. See backup details for both platforms; do not assume an Android portable backup and an iPhone cloud backup are interchangeable.

The recovery phrase is not a copy of the files. See recovery phrase versus encrypted backup for the exact distinction.

Questions to ask any vault provider

  • Is encryption performed before cloud storage receives plaintext?
  • Who can derive or retrieve the decryption key?
  • Which metadata remains visible?
  • What happens after password reset, account recovery, or support contact?
  • Can a user verify backup freshness and restore completeness?
  • How are deletions and retention handled?
  • What happens if the service or app disappears?

Guide reviewed: 12 September 2026.