Encrypted Container and Backup Target Comparison

What this five-entry comparison covers

VeraCrypt, the macOS encrypted disk image, and Cryptomator represent local container or disk-image paths, while Backblaze B2 and rsync.net represent remote backup targets, with every row limited to its accepted cells.

The mixed roster is deliberate, but the product categories are not interchangeable. A local encrypted-container tool, an operating-system disk-image feature, and a hosted storage target create different documented objects, access paths, account surfaces, custody relationships, and jurisdiction questions. The matrix keeps each entry visibly typed and does not infer a local-container property for a hosted target or a hosted-target property for a local tool.

Each entry has thirteen current persisted cells, producing a sixty-five-cell evidence set. A printed value comes only from the exact entry and attribute shown. Product, plan, region, platform, claim type, source class, source URL, capture date, and observation version remain attached to the cell. A value from one column does not fill another column, and a category label does not supply a fact the accepted source packet did not establish.

The page describes documented differences. It does not turn encryption language, portability, source availability, an assessment record, operating jurisdiction, or a concealed-container mechanism into an overall privacy or security verdict. No account was created and no product behavior was independently tested for this comparison. Inclusion and administrative ordering are not a recommendation, preference, or superiority claim.

Use the privacy-tool comparison methodology and corrections hub for claim labels, capture dates, typed-unknown treatment, and corrections. Full-Disk and Container Encryption explains the boundary between an encrypted object and full-device coverage, while custody and recovery remain separate questions.

Encryption boundary and cross-system portability

The documented encrypted object and access model must be read before portability, because a container, disk image, full-device claim, and hosted target describe different boundaries even when data can move between systems.

The boundary column records the documented boundary, encrypted object, mount or access model, any full-disk claim, any hosted-target role, platform, and limitations. Those fields identify what the accepted source says is covered. A file or directory container does not become full-device encryption, a disk image does not become a hosted backup service, and a hosted target does not inherit a client-side container claim.

The portability column separately records where the same encrypted data can be created, opened or mounted, synchronized or restored, along with its format, interoperability requirements, plan, and limitations. Create support and open support are not assumed to be the same. A synchronization path does not automatically establish a restore path, and a platform named for one action does not automatically support every other action.

The hidden-volume column records whether the documentation describes a hidden-volume or equivalent concealed-container mechanism, the vendor term, mechanism scope, platform, creation or access locator, and limitations. A not-applicable or not-established value stays attached to the product and attribute pair. It is not inferred from the row's category, and silence is not rewritten as no support.

Read the three columns together without merging them. A documented portability path does not widen the encryption boundary. A documented concealed-container mechanism does not establish cross-platform use. A hosted target's access model does not answer whether a separate client-side encrypted object is portable. The matrix preserves the exact field relationships rather than assigning a common architecture to all five entries.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Signup, later verification, retention, deletion, and request reporting

An accountless or local path has a different records surface from a hosted account, so identifiers, later verification, operating identity, retention, deletion, and request reporting remain separate documented fields.

The signup column reports identifier type, requiredness, collecting actor, plan, region, and platform. The later-verification column reports a later trigger, requested identifier, collecting actor, retained-by field, plan, and region. A local or repository-documented path may establish a different account surface from a hosted service, but the matrix prints only what the exact cells say. It does not infer accountlessness from a category label or assume a signup identifier predicts every later request.

The operating-entity column records the legal or project name, incorporation jurisdiction, governing law, hosting jurisdiction, and public document locator where the evidence supports them. A project identity is not silently converted into a company jurisdiction. Governing law, incorporation, hosting, and storage are not treated as synonyms, and a documented name does not supply an unstated jurisdiction.

Retention records a data category, trigger, duration, exceptions, and controller. Deletion separately records the initiation path, completed-erasure statement, exceptions, timeframe, and controller. A deletion instruction does not prove immediate erasure of every category, and a duration attached to one category does not become a schedule for every local file, account record, backup object, billing record, log, or legal record.

Request reporting records the period, jurisdiction, unit, scope, count, and absence reason supplied by the accepted cell. Requests, orders, accounts, objects, identifiers, and disclosures are not interchangeable units. A process statement is not a count, and the absence of a report is not zero requests. For a local or operating-system path, a typed unknown remains a scoped evidence result rather than a claim that a request can never occur elsewhere in the user's storage chain.

These six attributes preserve actor and scope. A local deletion behavior does not describe a remote target. A hosted account policy does not describe the lifecycle of a separate encrypted container placed there. Reading the columns together can show documented boundaries, but it cannot make the five entries equivalent or establish an outcome beyond their accepted source packets.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Source availability and published assessment history

Source availability, a current assessment record, and a published assessment history are separate evidence types, and their existence or absence does not create a quality conclusion.

The source-availability column records the repository URL, license, component, version, and release locator established by the current cell. A public repository supports a claim about the named artifact and scope. It does not by itself establish a hosted target's legal jurisdiction, remote retention, encryption-at-rest practice, completed erasure, or the source status of an undocumented component.

The assessment-record column reports an assessment date, assessor, scope, access, and report locator. The assessment-history column records dated entries with the assessor, scope, covered component or service, access, and report locator. A single record and a history answer different questions: one identifies a captured disclosure, while the other preserves the published sequence and component scope the source supplies.

Recording an assessment does not endorse its method or turn its existence into a security grade. A report covering one component, release, service, or period is not generalized to every client, hosted system, policy, or future version. Access conditions remain part of the record; a named locator is not rewritten as an independently reviewed result.

Typed unknowns stay exact. Not established means the accepted source packet did not establish the preregistered field. It does not mean no repository, license, component, assessment, or history exists, and it is not rewritten as closed source, unaudited, none, or unavailable. Each value retains its source class and capture date so repository evidence and vendor-stated evidence keep their different limits.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Backup-target jurisdiction and encryption-at-rest statements

This attribute concerns a documented hosted backup target, so operating jurisdiction, storage regions, region selection, and encryption-at-rest language are not inferred from a local container feature or transport-security statement.

The backup-target column records the operating jurisdiction, storage regions, whether a region is selectable, the exact encryption-at-rest claim, covered data, key-control statement, plan, and exceptions. Those fields stay attached to the accepted product scope. A storage-region statement is not an operating-jurisdiction statement, and an operating jurisdiction does not by itself identify every storage location.

Encryption at rest is reported in the source's own bounded terms. The matrix does not infer it from transport security, a client-side encrypted container, an encrypted disk image, or a general security label. Covered data and exceptions remain part of the claim. A statement about provider-controlled storage does not establish who controls a client-side key unless the same cell says so.

For entries that are not documented hosted backup targets, a not-applicable or not-established value remains scoped to this attribute and product pair. It is not a general statement about whether the entry can be copied, synchronized, mounted, or stored somewhere else. The row category alone cannot supply a remote jurisdiction, storage region, at-rest claim, or key-control answer.

This separation keeps two storage layers visible. A local encrypted object can have its own boundary and portability fields, while a remote target can have its own jurisdiction and storage claims. The matrix does not combine those layers into one assurance, assume that one substitutes for the other, or decide which arrangement fits a reader's threat model.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

How to read the matrix

Each cell is a dated source record rather than a recommendation, and a typed unknown means the accepted source packet did not establish that preregistered field.

Rows appear alphabetically by the operating entity or project identity recorded in the cells. That is an administrative order, not a ranking. Inclusion, row position, source detail, and the number of populated subfields do not express a preference, endorsement, or conclusion that one entry is more private or secure.

Read every value with its vendor or project ID, product, plan, region, platform, attribute, source class, source URL, capture date, and observation version. A capture date records when the source was read; it does not promise that a product, policy, repository, report, region, feature, or limitation has stayed the same since.

The source label identifies the kind of evidence. Public-record evidence can establish repository-published implementation, platform, component, license, release, configuration, or documented behavior within its scope. Vendor-stated evidence records what the vendor's own documentation, terms, policy, guide, or report says at the captured date. Neither label becomes an independent test.

A typed unknown is not a negative answer. Not established means the accepted packet did not establish the field. Not applicable is limited to the documented product and attribute pairing. Neither may be rewritten as yes, no, zero, none, absent, unavailable, unsupported, or proof of the opposite value. The twelve typed-unknown cells on this page retain their reasons and source locators.

Use the privacy-tool comparison methodology and corrections hub for the shared claim labels, capture-date meaning, typed-unknown treatment, and correction path. A correction belongs to the exact entry and attribute whose source record changes; it does not authorize silently copying a neighboring value or category assumption into the cell.

Limits of the evidence

The twelve typed unknowns do not establish opposite values, not-applicable findings stay product-and-attribute scoped, vendor statements are not independent conclusions, and the matrix supplies no universal threat model or preferred entry.

The page is bounded to the accepted source packet. It does not infer a local-container capability for a hosted target, a hosted-target property for a local tool, or a company jurisdiction for a project or operating-system feature when the cell does not state one. Product scope is part of every comparison, not a label that can be discarded after the table loads.

Encryption language remains attributed and scoped. A documented boundary is not a guarantee that every device, file, key, backup, transfer, or recovery path is covered. Portability is not proof of confidentiality. A hidden-volume mechanism is not a universal outcome. A hosted at-rest statement is not a client-side key-control claim unless the exact cell establishes both.

Evidence availability is also limited. A public repository for one component does not establish source availability for every component or hosted service. An assessment record or history establishes the published date, assessor, scope, access, locator, and covered component or service that the cell supplies. It does not establish a quality score, complete coverage, or present behavior outside that scope and capture date.

Lifecycle and request fields remain actor-specific. A local deletion statement does not establish remote deletion, and a hosted retention statement does not establish the lifecycle of a separate encrypted object. An absent report is not zero requests. An accountless or local path does not eliminate other actors elsewhere in a storage, synchronization, backup, custody, or recovery chain.

This comparison therefore supports a narrower decision: identify which documented boundary, platform, account, record, evidence, and hosted-target questions remain relevant for a particular storage design. It does not select an entry, promise anonymity, certify security, give legal advice, or determine which product or service is appropriate for a particular reader now or later.

Frequently asked questions

Related research

• Full-Disk and Container EncryptionA concept page separating full-device and encrypted-container boundaries
• 3-2-1 Backups and Border Crossings: Copy Separation and Cloud ExposureCopy count, media diversity, storage separation, and recovery testing are distinct controls
• Password Manager and Authenticator ComparisonIt compares four password-manager paths on documented signup, retention, deletion, audit, source, and request-reporting attributes.
• OS Hardening and Outbound Firewall ComparisonIt compares five hardening paths on identity requirements, change scope, outbound-rule models, source availability, and audits.