Published: 06.10.2026
rsync copies files and transfers only the parts that have changed since the last run. Combined with SSH, it is a simple and well-established way to send a folder to remote storage. Cloud Drive supports rsync as one of its access methods, so the same commands work for offsite copies. This article covers the most useful options, how to test a command safely and how to schedule the job.
The basic command
The basic form is the rsync command, followed by its options, the source folder and the destination. A trailing slash on the source matters. With a slash, rsync copies the contents of the folder; without it, rsync copies the folder itself. The destination is written as USER@HOST, a colon and the path on the remote storage, using the connection details from your customer area. For example, rsync -avz followed by a source folder with a trailing slash and then USER@HOST:PATH/TO/BACKUP/ copies a website folder. Replace the capitalised words with your own values.
Useful options
- -a keeps permissions, timestamps, symbolic links and ownership, where your account is allowed to set them.
- -v shows what is being transferred, which helps the first time you run a job.
- -z compresses data during transfer. It helps on slow connections and is less useful for photos and archives that are already compressed.
- --delete removes files at the destination that no longer exist in the source. It makes the copy match the source exactly, so use it deliberately.
- --exclude skips files or folders, such as caches or temporary directories.
- -e passes an SSH command with options, which you need when the connection details name a port other than the default.
Dry run first
Always test a new command with the dry-run option, which you can write as -n or as --dry-run. rsync then reports what it would copy or delete and changes nothing. Read the list carefully, especially when --delete is in use. Only after the list looks right should you remove the dry-run option and run the real copy.
Login with an SSH key
rsync runs over SSH, so key-based login works for it as well. A scheduled job cannot type a password. Create a separate key for the backup job, place only that public key in the backup account, and keep the private key on the source server with strict file permissions. A Cloud Drive subaccount that can reach only its own folder is a good fit for this job, because a leaked key then exposes only that folder.
Scheduling the job
Schedule the copy with cron, and use the full path to rsync, which the which command shows. A line made of the schedule 0 3 * * * followed by the rsync command runs the copy every night at 03:00 in the server's time zone. Redirect the output to a log file, so that you can check the result the next morning. A lock tool such as flock prevents a second run from starting while the first is still going, which matters when transfers take longer than expected.
Checking the result
- Read the log after the first run and after every change.
- Compare file counts and total sizes on both sides.
- Restore a few files into a test folder and open them.
- Check that files disappear from the destination only when you expected them to be removed.
Frequently asked questions
Is rsync a backup? It is a copy. A copy made with --delete mirrors deletions too, so an accidental removal is copied as well. Keep snapshots or versioned backups for history.
Why is the second run so much faster? rsync compares file sizes and modification times, and sends only the files that changed, so repeated runs take less time.
Does rsync encrypt the transfer? Yes, when it runs over SSH the connection is encrypted. The files are stored as plain files at the destination unless you encrypt them separately.
