Add redundancy when you need another copy

1. Choose a target

Use storage that is separate from the SyncVisor server disk. Supported target types include S3-compatible storage, Google Cloud Storage, and Azure Blob Storage. Create the bucket or container with your provider before configuring SyncVisor.

2. Keep credentials narrow

Use credentials limited to the bucket or container used for SyncVisor backup. Record the account owner and keep recovery credentials outside the SyncVisor data directory.

3. Configure the target on the server

Backup targets cannot currently be created or edited in the WebUI. For Server Manager installations, add a target under cloud_backup_targets in the platform config file:

• macOS: ~/Library/Application Support/SyncVisor/config.yaml
• Windows: %APPDATA%\SyncVisor\config.yaml
• Linux: ~/.config/SyncVisor/config.yaml

Standalone servers use the config path passed to --config. S3-compatible targets require an endpoint, bucket, access key, secret key, and TLS choice; add a region when the provider requires one. GCS targets require a bucket and credential file or application-default credentials. Azure targets require a container plus a connection string or account name and key.

For an S3-compatible target, add this shape and replace every example value with the bucket and scoped credentials from your provider:

cloud_backup_targets:
  - name: "primary"
    enabled: true
    provider: "s3"
    endpoint: "s3.amazonaws.com"
    region: "us-east-1"
    bucket: "example-syncvisor-backup"
    access_key: "replace-with-scoped-access-key"
    secret_key: "replace-with-scoped-secret-key"
    use_ssl: true
    prefix: "syncvisor/"

Protect the config file because it can contain provider credentials. In Server Manager, choose Stop Server before editing the file, then choose Start Server after saving so Server Manager reloads it. Restart standalone server processes with the same --config path.

4. Check status in the WebUI

Open the WebUI Admin area after restart. The Cloud Backup section shows targets that passed startup validation and provides Backfill, Verify, and Restore Drill actions.

• The configured target appears with the expected provider and bucket or container.
• New chunks are queued and uploaded.
• Failures are visible and retryable.
• The object store shows new backup objects.

5. Prove recovery

• Upload a small test file.
• Wait for backup status to show it has been handled.
• In the WebUI admin area, run backup verify for the target and confirm the sampled chunks pass.
• Use the native app's version history to restore an older version, or use WebUI version history to download a version.
• Open the restored or downloaded file and confirm its contents.

Success check

You can point to the server, the backup target, the recovery credentials, a successful WebUI backup verification result, and a file recovered through native version restore or WebUI version download.