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
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
while for Windows users I would
naturally say that TimeDicer http://www.timedicer.co.uk
maintain) is the way to go. For restoring, rdiffWeb
* works nicely from your browser.
* 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...
Sent from BlackBerry®
Xcuze typos if N E
rdiff-backup-users mailing list atrdiff-backup-users < at > nongnu.org
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki