Skip to main content

Cloud archives: connections and recovery

A cloud copy gives backups another storage location. Verify local backup and restore first, then connect a service, upload one version and test downloading it for recovery.

The cloud form uses an example address and a blank password; no connection has been verified or saved.The cloud form uses an example address and a blank password; no connection has been verified or saved.

The cloud form uses an example address and a blank password; no connection has been verified or saved. Interface version: 1.9.6.

1. Prepare the tools​

Open cloud setup from the project's follow-up actions. Version 1.9.6 reuses verified rclone and OpenList installations where possible. Downloads are checked with SHA-256 and try subsequent sources after a failure. Review dependency status and each failed step.

Tool installation, account authorization and connection testing are separate steps. An installed OpenList does not mean a cloud account is signed in; configure its storage afterward.

2. Configure a connection​

Choose WebDAV, OneDrive, S3 or an OpenList bridge. Set the rclone executable, working directory, configuration file, remote name and RemoteBasePath explicitly.

Authorize OneDrive using option names in rclone config. For WebDAV, enter the server, path and account. Configure OpenList storage before using its WebDAV. Menu numbers vary by version. Credentials in configuration files should not appear in shared screenshots or complete logs.

Test the connection and confirm both browsing and upload permissions. Listing a directory does not prove write access.

3. Upload and recover​

Upload a verified backup. Check archive transfer and history synchronization separately. Before recovery, select a version, prepare it and all dependencies, verify sizes and hashes, then restore to a new test directory.

Read-only cloud recovery does not write remote history, retire replicas or change the current source and workspace. Check the formats supported by the entrypoint; plugin archives also require a compatible materializer.

History and archive files​

History synchronization unions immutable packs instead of overwriting a shared history.json. Work on two devices may create diverging branches that need review. Synchronization alone does not switch the local workspace. A listed record may still lack downloaded archive bytes.

<RemoteBasePath>/_folderrewind/history/<encoded ConfigId>/
├─ repository.json
└─ packs/<first two characters>/<PackId>.frpack

<RemoteBasePath>/_folderrewind/replicas/<ReplicaId>/
├─ manifest.json
└─ payload

Saved object keys determine replica locations. Local indexes and workspace state are not shared history facts. Legacy archives may retain their previous remote locations.

Automation and troubleshooting​

Test upload, download and recovery to a new directory before enabling upload after backup. Distinguish local backup success, transfer failure, history-sync failure, divergence and missing dependencies. After cancellation, check which phase completed before retrying.

Old cloud configuration does not automatically migrate into 1.9. Keep the original remote data and Smart dependencies, then reconnect. See the rclone and OpenList documentation for connection parameters.