Offsite copies

A fire, a theft or water damage take the Mac and the disks next to it. The offsite copy is the one that survives. The Offsite screen (group Copies) sends your .obf archives to:

• S3 or compatible storage: Amazon S3, Backblaze B2, Cloudflare R2, MinIO, or another S3-compatible service;
• a remote folder: a NAS, a network disk or an external disk mounted on the Mac;
• a synced folder: the local folder of Google Drive, Dropbox, OneDrive or iCloud Drive, which the service then uploads to its servers.

Sending offsite requires a licence. Adding a destination, testing it, listing its archives, verifying a copy, downloading it and restoring it are free: after losing a Mac or when a licence ends, your copies always come back. The number of destinations you send to may be limited by your plan (see Licence and settings).

Add an S3 destination

1. Click Add Destination › S3 or Compatible Storage….
2. Fill in:
   • Name: your own (“Backblaze atelier”);
   • Provider: Amazon S3, Backblaze B2, Cloudflare R2, MinIO or Autre service compatible S3 (Other S3-compatible service). Vault suggests the region and addressing that suit it;
   • Service address (endpoint): for any provider other than Amazon S3 (an example is shown in the field). It is a host name, followed by its port when the service does not listen on the usual HTTPS port (for example minio.example.com:9000), without https:// or a path;
   • Bucket and Region;
   • Access key ID and Secret access key, created at your provider;
   • Storage class (Amazon S3 only): Bucket default, Standard – infrequent access or Glacier – instant retrieval. Only the archive’s content takes this class; the manifest and the signature stay in the standard class. The archival classes Glacier Flexible Retrieval and Deep Archive are not offered: an archived object can be neither read back, verified nor restored until thawed at the provider;
   • Path-style addressing (MinIO and compatible) if your service requires it;
   • Prefix (folder): the bucket folder where this library’s archives go (empty: the root);
   • Destination enabled.
3. Click Test Connection: “Connection succeeded” says whether the destination already holds archives.
4. Click Save.

Access keys are kept in the Mac’s keychain, never in the database or in the archives. When editing, leave the secret key empty to keep the stored one.

Add a remote folder

1. Click Add Destination › Remote Folder….
2. Give a Name, then choose the Folder with Choose….
3. Test Connection, then Save.

Vault refuses to send if the folder is not mounted: connect the disk or the network volume first.

Add a synced folder (Google Drive, Dropbox, OneDrive, iCloud Drive)

If Google Drive for desktop, Dropbox, OneDrive or iCloud Drive is installed on the Mac, its local folder can be a destination, with no account to connect in Vault.

1. Click Add Destination › Synced Folder….
2. Give a Name, then choose, with Choose…, a folder inside the service’s folder: usually ~/Library/CloudStorage/GoogleDrive-…, ~/Library/CloudStorage/Dropbox, ~/Library/CloudStorage/OneDrive-…, or iCloud Drive in the Finder.
3. Vault recognizes the service and names it (“Google Drive folder detected”). Another service that publishes a folder in the Finder (Proton Drive, Box…) is recognized as “the sync service”.
4. Test Connection, then Save.

A folder chosen from the Remote Folder… menu is recognized the same way: what counts is the folder, not the menu.

What Vault knows, and what it does not. Vault writes the copy into the folder, on this Mac; the service then uploads it, later, or never if its quota is full or its account signed out. Vault reads the state the service publishes for each file and shows it next to each archive at the destination:

• Written, waiting for sync: the copy is on this Mac, the service has not uploaded it yet;
• Synced: the service reports every file of the copy as uploaded;
• Sync cannot be verified: the service publishes nothing about these files; Vault does not guess;
• Sync conflict: the service reports a conflict, or duplicated a file or the folder of the copy (manifest (1).json, … (conflicted copy …)); keep the original, remove the duplicates, then verify the copy;
• Sync failed: the service could not upload the copy (its message is in the badge’s help);
• Online only: the files are no longer on this Mac, only at the service.

Until a copy is Synced, it does not count as an offsite copy: the archive’s row shows its state instead of Offsite, the dashboard says “copies waiting for sync, no confirmed offsite copy”, and the archive’s certificate does not list it.

Verify, Download… and Restore… first ask the service to bring the copy back to this Mac if it is no longer there; the progress bar says “Downloading the copy from …”. If the service does not bring it (offline, client stopped), Vault says so: nothing was read, and the copy is never counted as altered. Stop ends the wait.

Verification reads the copy on this Mac, not the one on the service’s servers. For proof that the copy reached the service, rely on the Synced state, and keep the folder available offline if you can.

Send an archive

1. Choose the destination in the list.
2. Library Archives lists your library’s archives, newest first. For an archive kept elsewhere, click Choose Archives… and choose an .obf package or the folder that holds several; Library Archives goes back to the default list.
3. Click Send on the archive’s line. An archive already present at this destination carries the Offsite badge and the Send Again button.

From the Archives screen, an archive’s Send Offsite… button (also in its context menu) opens Offsite with that archive at the top of the list, marked To send: one click on Send is enough.

Before sending anything, Vault verifies the local archive (signature and content fingerprint): a damaged local archive is never sent, and the copy already at the destination stays intact. This is what protects the offsite copy the day the Mac’s disk degrades.

A bar follows the send: “Checking the local archive…”, then “… sur …” (… of …), then “Verifying the copy sent…”. Stop stops it; a stopped upload to S3 storage resumes where it stopped when you start it again. If the service has meanwhile forgotten the stopped upload (a bucket lifecycle rule), it starts over at once. During a send, the other Send buttons stay disabled, even if you visit another screen: the progress and Stop are still there when you come back.

After sending, the copy is verified before the send is declared successful. To a folder, the new copy is written alongside, read back and compared with the local archive before it replaces the old one. To S3, Vault reads back the manifest and the signature and checks the content’s size and, on Amazon S3, its SHA-256 checksum, without downloading the content again; a multipart upload whose bytes do not match the manifest is never completed. A copy that differs makes the send fail: a wrong copy is worse than no copy.

Archives are stored at the destination under prefix/project/archive (for example atelier/Mariage Dupont/Mariage Dupont-v2/), with their files: content, manifest.json, signature.ed25519 and, when the archive has one, the inventory annex (inventory.json and inventory.ed25519), and nothing else the package folder might hold. The annex goes to every destination (folder, synced folder, S3), is read back with the manifest in the check that follows the send, and comes back with the archive when downloaded. An encrypted archive stays encrypted at the destination.

Send an incremental revision

An incremental revision holds only the files changed since the revision before it: it can only be restored with its whole chain, from the last full revision up to it. Sending an incremental revision therefore first sends the revisions of its chain missing at the destination, oldest first, then the revision itself. Each is verified before sending, like any archive, and its copy is verified afterwards. The progress bar covers them all, and its line names the revision in progress and its place in the send: “Package 2 of 3: Mariage Dupont-v2 · …”.

• A revision already at the destination, with the same manifest, is not sent again.
• A revision no longer on this Mac but still at the destination does not prevent the send.
• If a revision of the chain is neither in the same folder on this Mac nor at the destination, nothing is sent: sent alone, the revision could not be restored from there.
• The rule “another archive with the same name is never overwritten” applies to every revision of the chain: if one of them would take the place of another archive, nothing is sent.

Verify an offsite copy

In Archives at This Destination, click Verify: Vault checks the remote manifest’s signature with your archive keys, then downloads the copy’s content, recomputes its fingerprint and compares it with the manifest. The result: “The offsite copy of … is verified”, or damaged or incomplete (missing, manifest missing, signature missing, signature not recognised, content missing, different fingerprint). A copy whose manifest and content were replaced together is never reported verified: the signature no longer matches.

A copy the service refuses to read (permissions, outage, archived object) is “not verifiable”, never “damaged”.

Verification downloads the archive’s whole content: it takes time for a large archive. Stop interrupts it; a stopped verification proves nothing. After a send, the line “Verifying the copy sent…” replaces the bar while Vault checks the copy.

Refresh re-reads the list of archives present at the destination; only the destination’s prefix is read, never the whole bucket.

Restore from offsite

1. Click Restore… on the archive’s line.
2. Choose where to restore, then Restore Here.

Vault downloads the package into a temporary folder, then restores it exactly like the Archives screen (see Archives): signature and fingerprint verified before extracting anything, decryption if needed, files restored into a new subfolder named after the archive (-2, -3… if the name is taken), without overwriting an existing file, then every file read back and compared with the manifest; the banner says if any file differs. The library’s Archives folder and the inside of an archive are refused as a destination, before any download. The temporary folder is deleted afterwards. A project folder is pointed out before anything is downloaded, as in Archives (Restore Anyway).

An incremental revision (holding only the files changed since its base revision) is never restored alone: Vault looks for its chain at the destination, downloads it whole into the temporary folder, then restores it like the Archives screen (see Restore an incremental revision): every revision of the chain is verified before anything is extracted, and the project is rebuilt as it was at that revision, deleted files excluded.

• If a revision of the chain is missing at the destination, the restore is refused before anything is downloaded, without writing anything in the chosen folder; the message names the revision and the destination. Send the revision again from this Mac: the send completes the chain.
• For an Obscura Flow chain (without inventory), Vault first warns that files deleted between two revisions are not known and will be restored; Restore Anyway merges the chain.
• In both cases, the banner also offers Extract Only This Revision’s Files…, which downloads the package again and extracts only those files into a new <archive>-changed-files subfolder of the same folder. This is not the whole project.

The signature is accepted if it comes from this installation’s key or from a trusted key (Obscura Flow’s included, if you imported it). An encrypted archive opens with the first known key that opens it. See Keys and security.

Download… only fetches the .obf package, without restoring it: useful to verify it or restore it later in Archives. The package is downloaded under a hidden name, verified (signature and fingerprint), and only appears in the chosen folder once complete and verified; a copy that fails verification is not kept. A package of the same name already there is never replaced: the download takes the next name (-2, -3…). The library’s Archives folder and the inside of an archive are refused.

For an incremental revision, Download… also brings back the revisions of its chain, each in its own folder beside it: the chosen folder can then be restored from Archives. All of them are verified before any appears; a revision of the chain already in that folder, with the same manifest, is not downloaded again. The banner says which revisions are beside it. If the destination does not hold the whole chain, only the package asked for is downloaded, and the banner warns that it cannot be restored from that folder (only its files can be extracted).

Delete a copy

Delete Copy… (the bin icon on a copy’s line, also in its context menu) deletes the package at the destination, after a confirmation: there is no bin at the destination. The archive on this Mac and the copies at other destinations are not touched. The deletion is recorded in the audit log (“Offsite copy removed”).

Vault refuses to delete a revision that an incremental revision kept at this destination depends on: “Revision 1 cannot be removed from the destination “NAS”: revisions 2, 3, at that destination, depend on it.” First delete those revisions, newest first, or send a newer full revision there (see Understanding verdicts).

Edit or delete a destination

Edit… and Delete… are on the destination (and in its context menu). Deleting a destination makes Vault forget the destination and its access keys: archives already copied stay at the destination. For a connected account, Vault also withdraws its access to the account, like Sign Out.

Tracking transfers

Recent Transfers lists recent sends, verifications, restores and downloads with their result. Each transfer is recorded in the audit log. Copies sent or verified by Vault appear on the archive’s certificate (see Preservation certificates); a copy whose verification failed no longer appears.