LOOM / 03

Storage & Recovery

A second pathname is not necessarily a second copy. LOOM separates the files you work on, the files it holds, and the evidence that they can be recovered.

Where a file lives matters

Box is the writable workspace. On a workspace node it contains ordinary material, projects and a Lane for deliberate transfers. Main has its own Box, including Topics and Library, and receives accepted Lane batches into Storage Imports rather than another Main-side Lane.

Storage is the custody side: imports, retained watched-root backups and physical archives. A catalog connects identities, lineage, checksums and physical references. Search indexes and other generated views are reproducible outputs, not replacement originals.

Writable source
A person or application edits the original material in its workspace.
Staged transfer
Lane inventories and transfers a selected batch to Main.
Accepted custody
Main promotes the verified payload into configured Storage and commits catalog evidence.
Optional source cleanup
Only the reviewed, still-matching source is eligible. A failed cleanup does not erase the transfer history.

A deliberate Lane transfer. Each transition has its own recorded state; arrival of bytes is not yet a completed custody transfer.

This explains why a transfer may need repair without needing another upload. Persisted evidence distinguishes transport, promotion, cataloging and cleanup. A read-only storage view is useful for inspection, but it is not an alternate editing surface.

Transfer, sync, archive and backup

These words describe different intentions. A transfer hands off a selected batch. Synchronization keeps selected working state aligned. Archiving changes the lifecycle and custody of work that is no longer active. A backup retains recovery material independently of the working copy.

None implies all the others. An archived project is not automatically a cloud backup. A successful synchronization can faithfully propagate an unwanted edit. And finding a retained payload is not enough to conclude that the source can be deleted: identity and fidelity evidence still matter.

Physical project and workspace archiving uses a reviewed plan tied to the source, destination and catalog state. The supported physical move requires a same-filesystem destination and does not silently fall back to a copy. Its manifest and journal preserve an inspectable history of what moved.

Active workspace
Files and declared resources participate in ongoing work.
Archived workspace
The payload moves to archive custody; its identity and history remain inspectable.
Restored, inactive workspace
The files return without silently restarting application behavior.
Explicit reactivation
Review the relevant application and resource state before resuming operation.

Project lifecycle. Restoring the workspace and reactivating its applications are deliberately separate operations.

For research-sync, that means retrieving an old design note need not mean bringing an old WebDAV server back online. Archive-aware Notes retrieval can preserve historical context, subject to current access and source availability. Larger project archive, restore and reactivation scenarios still need further real-use acceptance.

Recovery is more than the user files

Recovering a host also requires the state that makes its files intelligible. LOOM distinguishes local operational recovery packages, Provenance database recovery, and Borg cloud history for selected user data. These are related inputs, not interchangeable names for one backup.

Operations: Restore the system's recorded state
Recovery packages preserve the operational database and selected configuration evidence needed by the supported recovery flow.
Provenance: Preserve the qualified history
Restore checks the package's declared schema state before applying supported migrations to the disposable recovery target.
Cloud history: Retain selected payloads off the host
Borg stores deduplicated archive history. Coverage follows the configured sources and exclusions, not every byte on every machine.

Borg can reuse unchanged chunks, so a new archive does not necessarily upload a whole new copy of the dataset. But the system still has work to do: enumerating files, detecting changes, reading uncached content and performing deeper verification. Growing storage does not make all backup operations constant-time.

Scheduling local package creation before the cloud run can give that run a fresh recovery package. Exact wall-clock times and timezone belong to the operator's policy; they are not a universal installation requirement.

Ask what was actually proved

A creation receipt proves an archive operation completed. Metadata verification checks a narrower property than reading and verifying archived data. A bounded repository check reports progress, not complete data verification. A strict restore exercise goes further by retrieving material and checking recovery into disposable targets.