rdiff-backup vs. Back-In-Time
Thanks for your posting Kshitij, you give us yet another backup program
to consider - back-in-time.
If it ain't broke, don't fix it:
If your backup routine works for you, why change to rdiff-backup?
Back-in-time (according to the website) is a GUI and under the hood it
uses rsync, diff, cp and hardlinks to take snapshots. To rdiff-backup
users this sounds a bit like reinventing the wheel and it may well be
much less space-efficient than rdiff-backup. It's not clear to me
whether a small change in a large file leads back-in-time to store the
whole file twice; if so, these types of files (databases, mailboxes)
could eat up a huge amount of space (in theory 24 x their original size
per day). rdiff-backup only stores the diffs or deltas which in such
cases are comparatively small. But if you have plenty of space or are
happy to delete snapshots older then a certain limited period (1 week? 1
month?) then even in this scenario the space considerations may not be
important.
bug-free = not yet thoroughly tested:
I do think however that anyone reading this mailing list should bear in
mind that people post here when they have difficulties. For the most
part rdiff-backup works very well and has proved a reliable backup for
many years - for me and for others. I recently had to recover an old
version of a database file from about 9 months ago (i.e. about 230
reverse-diffs) - rdiff-backup worked perfectly (albeit the recovery was
quite slow). I mention this not because it is any kind of record but as
a real-world situation where rdiff-backup saved my bacon.
For users who find the command line too alarming but still like the
power of rdiff-backup, there is jBackup
http://sourceforge.net/projects/jbck/, while for Windows users I would
naturally say that TimeDicer
http://www.timedicer.co.uk (which I
maintain) is the way to go. For restoring, rdiffWeb
http://www.timedicer.co.uk/rdiffweb/index * works nicely from your browser.
Dominic
* static version of the wiki; the dynamic one is prone to spammer attacks
On 10/06/12 03:28, Kshitij Kotak wrote:
Dear rdiff-backup Experts
Pardon my naïve query, but need to understand what is the difference between rdiff-backup approach and the following steps:
1) we take the remote sync of primary data store on a mirror server using rsync. This is automated for every 1 hour using cron.
2) to get a point-in-time restore, we use back-in-time on mirror server to get the data stored locally in time slots to recover. My back-in-time runs once every day and is cronned using Back-In-time internal switch that allows me to define schedule.
This approach has worked flawless (so far). Plus back-in-time has a fantastic GUI which, for a non-expert like me is a great relief.
From what gather on this group, rdiff-backup saves much larger amount of space than my approach. Is that correct? Considering the complexities of command line approach, restore issues and the kind of problems you guys report... I am petrified to try out rdiff-backup.
Does rdiff-backup offer me any significant benefits over my novice approach? If so, is there a better, less complex, more reliable way to implement backup (and guarantee restore
) for a novice like me?
Await your replies...
Cheers
Kshitiz
Sent from BlackBerry®
Xcuze typos if N E
_______________________________________________
rdiff-backup-users mailing list atrdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
