Rsync Internet Backup FAQ
In theory, there’s no real limit to the number of files or directories that you can Rsync – apart from the practical limitation of RAM.
We have run tests on several different file systems – a typical file system of 70,000 files and 24 GB with under 50 MB of daily changes can be synced in around 10 minutes. The largest file system we've tested is of 200,000 files and 100 GB, which took 20 minutes to sync.
You can configure your Rsync job to compress and encrypt data stored on the Rsync server with AES-256 bit encryption for military-grade security. This reduces the amount of disk space used on your Rsync host, and means that your data safe is "in the cloud", making external hosting a safe and secure option.
File names are also obfuscated on the Rsync server, which means that anyone looking at the data on the Rsync data host cannot determine what the data is, nor read its contents. All encrypted Rsync jobs automatically have file name obfuscation applied.
Restoring from BackupAssist backups located on an Rsync Server is made simple with the BackupAssist Restore Console. The Restore Console eliminates you having to manually search through catalogues to find the specific backups or even individual files that you need.
Using the Restore Console you can retrieve files and entire applications (Exchange, SQL, SharePoint, etc) from an Rsync backup.
Rsync performs best on the file system directly - backing up normal files and directories. It performs far better than if you were to use Rsync to synchronize a backup file offsite.
Let's look at example to see why that's the case.
Scenario 1: File system with 50,000 files, 50 GB total; 50 files of total size 50 MB have changed.
Rsync is able to identify which of the 50 files have changed, and for those files, it determines the in-file deltas. It calculates checksums on 50 MB of data, and the backup can complete in a matter of minutes. The amount of data transferred will be around 20 MB for typical documents.
Scenario 2: The file system is backed up via NTBackup, which results in a 50GB bkf file.
Rsync will detect that the single bkf file has changed, and needs to determine the in-file deltas. It needs to calculate checksums on 50 GB of data, which may take hours. Additionally, we have found that even if the underlying file system changes very little, about 10% of a bkf file changes from day to day and needs to be transferred. Thus, about 5 GB will be transferred.
We see here that it is highly preferable in terms of both bandwidth and CPU time that the underlying file system is selected for Rsync, not a backup of that file system.
With the 'Back up NTFS metadata' option enabled in the rsync options tab (shown below) the following file system attributes are preserved at the backup destination:
|File attributes at backup destination||Preserved?|
|Windows File Attributes|
|Last access time|
|Last modified time|
|NTFS security (ACLs)|
|NTFS alternate data streams (ADSs)|
This option be checked by default for new jobs created in v6. If enabled, NTFS streams, such as alternate data streams and security data will be saved to a separate file on the destination and then added back to the file as part of the restore process when using the BackupAssist Restore Console. So while these attributes are not "preserved" on the files backed up to your Rsync destination, they will still be restored.
Because rsync works on top of the Cygwin Unix emulation layer, it doesn't know anything about other Windows file attributes (e.g. readonly, hidden, system, creation time, last acces time, etc) so it is not able to transfer any of these to the backup destination.
Yes. BackupAssist v6 includes fully integrated support for VSS application backup and restore. Microsoft applications such as Exchange Server, SQL Server, SharePoint and Hyper-V are fully supported, as well as any other VSS-aware application that uses standard VSS restore methods.
With this new feature, local VSS-aware applications can be safely backed up and restored without you having to manually choose the correct files. All running VSS applications will be automatically detected and listed for selection. Simply choose the VSS application that you want to back up from the 'Files and Folders' tab and BackupAssist will back up the application in a consistent state. VSS application backup is supported in File Replication, Zip, Rsync and Windows Imaging jobs.
Following from the discussions above, We recommend that you select the underlying file system for Rsync, not a backup of the file system.
However, having said that, drive images can be more suitable for Rsync than other types of backup, provided they are uncompressed and unencrypted. However, the checksum process will be CPU intensive. We have found on typical servers that checksums can be performed at a rate of about 100-120GB per hour, during which time the server's CPU is at about 30% on a single core. [Note: on multi-core processors, this means that CPU usage is not particularly high.]
So the time to backup via Rsync can be approximately calculated as:
2 * checksum time (one checksum for each end) + network time
So the short answer is: if you really really want to do it, you can, but we believe there are better ways to achieve what you want to achieve.
Remember - that the purpose of doing multiple backups is redundancy. That means protecting your data in different ways, to different locations. If you synchronize a drive image offsite, you run the risk that if that drive image is bad for whatever reason, you have just lost your data. However, if you back up your underlying file system using Rsync instead, if your image goes bad, you still have your files and folders at your remote site.
Rsync is an open-source program, with an open-specification protocol, so the number of Rsync compatible devices is always growing.
Any typical Linux or Windows machine can be configured to run Rsync. Additionally, several NAS devices are Rsync enabled - please see how Rsync White Paper for more details.
BackupAssist uses several Open Source components, which are licensed under the GPL, BSD license or MIT license. The following table summarises the open source software that we use:
|Rsync||3.0.4||Rsync license||Free to use (GPL)||Download source|
|Cygwin and GNU tools||1.5.25-15||CYGWIN license||Free to use (GPL mostly)||Download source|
|OpenSSH||5.1p1||OpenSSH license||Free to use (BSD)|
|OpenSSL||0.9.8h||OpenSSL license||Free to use (BSD)|
|cwRsync (the rest!)||2.1.5||cwRsync license||Free to use (MIT License)|