Cloud preservation
Avichive preserves canonical archive originals separately from the media it serves and the database packages it transfers. Deduplication gives identical bytes one content identity; cloud storage gives that identity a stable object address. Historical paths remain in the catalog so preservation does not discard where a file was found.
The architecture below is supported by application revision e76e74c, inspected October 13, 2026. Upload totals are dated operational records, not live counts. No new bucket-policy inspection or disaster-recovery exercise was performed for this guide.
Three storage roles
| Storage role | Provider and bucket | What it holds |
|---|---|---|
| Canonical originals | Backblaze B2, private originals bucket | Deduplicated archive source bytes |
| Served media | Wasabi, served-media bucket | Display attachments, variants, converted videos and document cloud copies |
| Database packages | Backblaze B2, database-transfer bucket | Full dumps and incremental transfer packages |
Rails Active Storage manages served media. Canonical originals use the S3 API directly because their identity already belongs to UniqueFile; they do not need a second million-record attachment catalog or display variants. Storage architecture (docs/CLOUD_STORAGE.md:7).
An invented hash abcdef0123456789 maps to originals/ab/cd/abcdef0123456789. Its stable catalog URI is b2://<originals-bucket>/originals/ab/cd/abcdef0123456789. The key is opaque; readable filenames and occurrence paths remain in the database. A later duplicate can reuse the same content object without renaming it. Key derivation (app/services/archive_originals.rb:18).
Verify before recording success
The uploader finds a readable source occurrence and calculates its xxHash64 digest. It tries alternate occurrences if the canonical path is missing or does not match. For a regular PUT, it checks the returned ETag against the locally computed MD5. It then checks the remote object’s byte count with HEAD before recording the canonical URI and uploaded state. Upload verification (app/services/archive_originals.rb:249).
These checks answer different questions. xxHash64 is a fast content identifier, not a cryptographic guarantee. The regular-PUT ETag check does not generalize to multipart ETags. A matching byte count alone does not establish matching content. A separate reader can download and hash the whole object; supervised upload batches also used sampled full-download verification. SDK multipart support exists, but that does not establish durable resume across process failure.
A recorded campaign, not a perpetual migration
The operational guide records a July 24, 2026 checkpoint of 1,185,605 uploaded unique files and five intentionally skipped files, with matching production metadata. The skips comprised two mutable OS-metadata files and three operator-cancelled ScreenFlow captures. Those outcomes are historical observations; they should not be read as today’s completeness report. Recorded checkpoint (docs/ARCHIVE_UPLOADS.md:26).
Earlier documentation still describes cloud reads and larger upload tiers as future work. Current code contains cloud range reads, bounded temporary materialization and short-lived original-download URLs. Source availability must nevertheless be checked for each workflow; an uploaded record does not mean every derivative is ready. Cloud reader (app/services/archive_originals.rb:166).
Recovery needs bytes and their catalog
The bucket cannot explain an opaque hash on its own. Recovery also needs the database mappings, metadata and decisions. Incremental metadata sync does not copy original objects: production reads the same B2 keys with its own runtime credentials. Derivatives are prepared and tracked independently in each environment.
Recovering a selected source tree can use mounted occurrences or cloud originals, but historical dependencies and external services may still be missing. That is why project restoration distinguishes recovered artifacts from reconstructed behavior. Operations explains catalog synchronization and restore boundaries. Cloud preservation is a maintained system of objects, evidence and recovery procedures, not a promise that every disaster is solved by one command.