Thanks for the responses. I am slightly lost in all the technical discussion. My requirement is simple. I do backups over a WAN using rsync over SSH. I have over 100 GB of files to be synced over the WAN. Transferring a couple of GB of data over WAN is fine but 100 GB of data might take a really long time.
Generally when transferring data using rsync, it compares the remote files with the local files using some checksum algorithm and transfers it only when they are different. From what I know, comparison using the checksum uses only a fraction of the bandwidth required to transfer the whole file. So while Backuppc performs a full backup, does it compare it with the local file stored during previous full backup? Or just blindly copy the entire file. Also, from your response, it seems that going with more frequent incremental backups is what you suggest. However is there any downside to this? For instance, let us say the full-backup is about 6 months old, and some file in it gets corrupted. Then will this be identified by the incremental backups? Thanks, Rahul. On Saturday 24 December 2011 08:18 AM, [email protected] wrote: > On Sat, Dec 24, 2011 at 9:34 AM, Les Mikesell<[email protected]> wrote: >>> Thanks Les. So my snip above does hold when trying to conserve >>> bandwidth (say over a WAN), but at the potential cost of increasing >>> the time the backup session requires. In a high-speed local >>> environment, processing time can be reduced by always using >>> "differential" between fulls (by not enabling the "incremental" >>> option). >>> >>> This only becomes a question if I got it wrong 8-) >> The more significant difference may be the wall-clock time time for a >> full rsync run, which always does a full read of all the data on the >> remote side for a block checksum comparison, and may need to >> read/uncompress on the server side. If that isn't an issue you can >> just do frequent fulls and not worry about doing rsyncs against >> incremental levels. If it is an issue, or you want to use the least >> bandwidth possible, then you might use incremental levels and less >> frequent fulls. > Yes, in my current usage, I've only been doing fulls since figuring > out it didn't impact storage space usage. I just wanted to clarify > understanding the trade-offs between the "other flavors" for future > reference in possible other contexts. > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > BackupPC-users mailing list > [email protected] > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users > Wiki: http://backuppc.wiki.sourceforge.net > Project: http://backuppc.sourceforge.net/ ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
