Return to Answer

Edit: Rsync does an end-to-end check: after the file is transfered it calculates the checksum of that file on the destination and compares it to the checksum on the source. When the the checksums match, only then it declares the transfer successful. This is reflected in the final exit status code - if ALL transfered files passed the test then the exit code will be 0 (Success).

In a similar setup I scripted-up my own solution based on rsync.

Addressing your 4 concerns:

• Rsync never modifies anything on the source side (unless you tell it something like --remove-source-files).
• Yes - rsync will not remove or modify the source. Ever.
• If the network goes down for a long time Rsync will give up and give an appropriate exit status. I check this in my script and for specific exit codes (which I observed in practice by logging) I have the script re-try the rsync command up to 3 times.
• Yes, your script should log as much as possible. Timestamp, Total Running time, Rsync exist status, Rsync --stats output (amount transmitted). I also run find at the end of the transfer to count the number of files and du * to get sizes of directories and log that.

Basically you need to take care of a few things in the script. Mainly: Gathering the exit status, some statistics, and removing source files on a successful transfer.

You can trust rsync's exit status that all the requested files were transfered but you should think about how much do you trust your script to provide rsync with the right files (source directory) before you delete them on the source machine. Maybe counting the files with find on the source and then on the destination (and then checking if those numbers match) would be a good final check before your script deletes the files automatically.

Give it a 10 to 20 tries to develop and test your script. You would need to install Cygwin with rsync and ssh clients on the Windows machines.

It's good to feel confidant about a application like that by knowing exactly how it works. I never used a commercial backup software - but if you can find a rock-solid one and trust it - then go for that - it could save you a lot of time.

Edit: Rsync does an end-to-end check: after the file is transfered it calculates the checksum of that file on the destination and compares it to the checksum on the source. When the the checksums match, only then it declares the transfer successful. This is reflected in the final exit status code - if ALL transfered files passed the test then the exit code will be 0 (Success).

In a similar setup I scripted-up my own solution based on rsync. It was for nightly backups and we do not delete files automatically.

To address some of your concerns:

• Rsync never modifies anything on the source side (unless you use the --remove-source-files option).
• If the network goes down for a long time Rsync will give up and give an appropriate exit status. I check this in my script and for specific exit codes (which I observed in practice by logging) I have the script re-try the rsync command up to 3 times.
• Yes, your script should log as much as possible. Timestamp, Total Running time, Rsync exist status, Rsync --stats output (amount transmitted). I also run find at the end of the transfer to count the number of files and du * to get sizes of directories and log that.

Basically you need to take care of a few things in the script. Mainly: Gathering the exit status, some statistics, and removing source files on a successful transfer.

You can trust rsync's exit status that all the requested files were transfered but you should think about how much do you trust your script to provide rsync with the right files (source directory) before you delete them on the source machine. Maybe counting the files with find on the source and then on the destination (and then checking if those numbers match) would be a good final check before your script deletes the files automatically.

Give it a 10 to 20 tries to develop and test your script. You would need to install Cygwin with rsync and ssh clients on the Windows machines.

It's good to feel confidant about a application like that by knowing exactly how it works. I never used a commercial backup software - but if you can find a rock-solid one and trust it - then go for that - it could save you a lot of time.

In a similar setup I scripted-up my own solution based on rsync.

Addressing your 4 concerns:

• Rsync never modifies anything on the source side (unless you tell it something like --remove-source-files).
• Yes - rsync will not remove or modify the source. Ever.
• If the network goes down for a long time Rsync will give up and give an appropriate exit status. I check this in my script and for specific exit codes (which I observed in practice by logging) I have the script re-try the rsync command up to 3 times.
• Yes, your script should log as much as possible. Timestamp, Total Running time, Rsync exist status, Rsync --stats output (amount transmitted). I also run find at the end of the transfer to count the number of files and du * to get sizes of directories and log that.

Basically you need to take care of a few things in the script. Mainly: Gathering the exit status, some statistics, and removing source files on a successful transfer.

You can trust rsync's exit status that all the requested files were transfered but you should think about how much do you trust your script to provide rsync with the right files (source directory) before you delete them on the source machine. Maybe counting the files with find on the source and then on the destination (and then checking if those numbers match) would be a good final check before your script deletes the files automatically.

Give it a 10 to 20 tries to develop and test your script. You would need to install Cygwin with rsync and ssh clients on the Windows machines.

It's good to feel confidant about a application like that by knowing exactly how it works. I never used a commercial backup software - but if you can find a rock-solid one and trust it - then go for that - it could save you a lot of time.

Edit: Rsync does an end-to-end check: after the file is transfered it calculates the checksum of that file on the destination and compares it to the checksum on the source. When the the checksums match, only then it declares the transfer successful. This is reflected in the final exit status code - if ALL transfered files passed the test then the exit code will be 0 (Success).

In a similar setup I scripted-up my own solution based on rsync.

Addressing your 4 concerns:

• Rsync never modifies anything on the source side (unless you tell it something like --remove-source-files).
• Yes - rsync will not remove or modify the source. Ever.
• If the network goes down for a long time Rsync will give up and give an appropriate exit status. I check this in my script and for specific exit codes (which I observed in practice by logging) I have the script re-try the rsync command up to 3 times.
• Yes, your script should log as much as possible. Timestamp, Total Running time, Rsync exist status, Rsync --stats output (amount transmitted). I also run find at the end of the transfer to count the number of files and du * to get sizes of directories and log that.

Basically you need to take care of a few things in the script. Mainly: Gathering the exit status, some statistics, and removing source files on a successful transfer.

You can trust rsync's exit status that all the requested files were transfered but you should think about how much do you trust your script to provide rsync with the right files (source directory) before you delete them on the source machine. Maybe counting the files with find on the source and then on the destination (and then checking if those numbers match) would be a good final check before your script deletes the files automatically.

Give it a 10 to 20 tries to develop and test your script. You would need to install Cygwin with rsync and ssh clients on the Windows machines.

It's good to feel confidant about a application like that by knowing exactly how it works. I never used a commercial backup software - but if you can find a rock-solid one and trust it - then go for that - it could save you a lot of time.

Rsync is very powerful. In a similar setup I scripted-up my own solution based on rsync. Adressing your 4 points:

• Rsync never modifies anything on the source side.
• Yes - rsync will not remove or modify the source. Ever.
• If the network goes down for a long time Rsync will give up and give an appropriate exit status. I check this in my script and for specific exit codes (which I observed in practice by logging) I have the script re-try the rsync command up to 3 times.
• Yes, your script should log as much as possible. Timestamp, Total Running time, Rsync exist status, Rsync --stats output (amount transmitted). I also run find at the end of the transfer to count the number of files and du * to get sizes of directories and log that.

Basically you need to take care of a few things in the script. Mainly: Gathering the exit status, some statistics, and removing source files on a successful transfer.

Give it a 10 to 20 tries to develop your script.

It's good to feel confidant about a application like that when you know exactly how it works. I never used a commercial backup software - but if you can find a rock-solid one and trust it - then go for that - it could save you a lot of time.

In a similar setup I scripted-up my own solution based on rsync.

Addressing your 4 concerns:

• Rsync never modifies anything on the source side (unless you tell it something like --remove-source-files).
• Yes - rsync will not remove or modify the source. Ever.
• If the network goes down for a long time Rsync will give up and give an appropriate exit status. I check this in my script and for specific exit codes (which I observed in practice by logging) I have the script re-try the rsync command up to 3 times.
• Yes, your script should log as much as possible. Timestamp, Total Running time, Rsync exist status, Rsync --stats output (amount transmitted). I also run find at the end of the transfer to count the number of files and du * to get sizes of directories and log that.

Basically you need to take care of a few things in the script. Mainly: Gathering the exit status, some statistics, and removing source files on a successful transfer.

You can trust rsync's exit status that all the requested files were transfered but you should think about how much do you trust your script to provide rsync with the right files (source directory) before you delete them on the source machine. Maybe counting the files with find on the source and then on the destination (and then checking if those numbers match) would be a good final check before your script deletes the files automatically.

Give it a 10 to 20 tries to develop and test your script. You would need to install Cygwin with rsync and ssh clients on the Windows machines.

It's good to feel confidant about a application like that by knowing exactly how it works. I never used a commercial backup software - but if you can find a rock-solid one and trust it - then go for that - it could save you a lot of time.