Identify source paths, destination, exclusions, required ownership/ACL metadata and recovery objective. Use a dedicated SSH credential with the least required access and verify the server fingerprint. For databases, create a native consistent backup or stop writes through an approved procedure before copying their recovery files.

1. Create a destination outside the source filesystem and preferably outside the same failure domain. Restrict who can read the backup because it can contain the full application and credentials.
2. Prepare the rsync command with explicit source and destination paths. Understand the source trailing slash: copying a directory and copying its contents produce different layouts.
3. Run a dry run with itemized changes. Review every intended path and exclusion before enabling writes. Leave deletion options out of the first backup unless an exact mirror with verified recovery versions is deliberately required.
4. Run the reviewed transfer over SSH and capture the exit status and bounded log. Choose archive, ACL, extended-attribute and numeric-owner options according to the source, destination and intended restore environment rather than assuming archive preserves everything.
5. Verify selected files and metadata, then restore a sample to a separate test location. Establish retention and monitoring before scheduling unattended transfers.

Run this on the Linux source server after verifying the backup host fingerprint. Replace the source path, account and destination with your approved backup locations. The --dry-run option makes this a preview and --itemize-changes shows what a real transfer would change.

rsync -a --dry-run --itemize-changes \
  -e "ssh -p 22" \
  /srv/example-site/ [email protected]:/srv/backups/example-site/

Read the result: The source trailing slash means copy the contents of example-site into the destination directory. Review unexpected file paths and permission errors before arranging a real transfer. This sample deliberately has no deletion option, so it is not a request to remove destination files.

Create a consistent database backup separately rather than copying an actively changing database directory. Verify the intended metadata requirements, storage retention and a sample restore. After the preview is approved, use the reviewed backup workflow to perform and monitor the actual copy.

Not as a universal consistency guarantee. Use the database's supported backup method or a coordinated consistent snapshot/shutdown, and verify that the resulting files can recover the database.

Confirm the copied tree contains required configuration, uploads and consistent database recovery files. Test an actual restore under the intended user permissions. Monitor nonzero exit codes, inaccessible files and destination capacity instead of treating any copied bytes as success.

For permission failures, correct the specific access path without granting unrestricted root to every backup job. If a dry run proposes unexpected deletions or an empty source, stop and check mounts and path syntax. Never run a destructive mirror command against the only remaining recovery copy.

• Installing an SSH key without losing existing server access
• Testing a Linux server restore before an emergency
• Testing a persistent filesystem mount before reboot
• Running a maintenance job with a systemd timer

• download.samba.org: Rsync
• man.openbsd.org: SSH