Rclone Remote Targets
Remote targets are where your offsite backups live. The key is consistency: use predictable remote paths, validate access, and avoid destructive sync operations until you are confident.
Quick Summary
- List configured remotes:
rclone listremotes. - Validate a remote:
rclone lsd remote:andrclone ls remote:path. - Prefer
rclone copyfor backups. - Use
rclone synconly when you intentionally want mirroring (and accept deletions).
List and validate remotes
rclone-list-remotes.sh
rclone version
rclone listremotes
Test a remote root:
rclone-test-remote-root.sh
rclone lsd remote:
Create a remote directory layout
Use a stable layout so restores are predictable.
Example:
remote-layout-example.txt
remote:wp-backups/
site-a/
files/
db/
logs/
site-b/
files/
db/
logs/
Create directories:
rclone-create-remote-directories.sh
rclone mkdir remote:wp-backups/site-a/files
rclone mkdir remote:wp-backups/site-a/db
rclone mkdir remote:wp-backups/site-a/logs
Copy backups to a remote (safe default)
rclone-copy-backups-safe.sh
rclone copy /backups remote:wp-backups/site-a \
--include 'wp-files-*' \
--include 'wp-db-*' \
--include '*.log'
Sync backups to a remote (mirroring)
warning
rclone sync deletes remote files that are not present locally. If your local disk is partially missing, sync can propagate the loss.
rclone-sync-backups-mirroring.sh
rclone sync /backups remote:wp-backups/site-a
Remote verification
rclone-verify-remote-files.sh
rclone lsf remote:wp-backups/site-a/files | sed -n '1,60p'
rclone lsf remote:wp-backups/site-a/db | sed -n '1,60p'
For integrity verification, you can also use rclone check for some remotes:
rclone-check-local-vs-remote.sh
rclone check /backups remote:wp-backups/site-a
Next steps
- Offsite + local redundancy:
opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/offsite--local-redundancy.mdx. - Retention and pruning:
opt/docker-data/apps/docusaurus/site/docs/server/linux-server/10-backup-disaster-recovery/rotation--retention-policies.mdx.