|
From: | Dominic Raferd |
Subject: | Re: [rdiff-backup-users] rdiff-backup vs. Back-In-Time |
Date: | Sun, 10 Jun 2012 14:43:50 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
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 :D ) for a novice like me? Await your replies... Cheers Kshitiz Sent from BlackBerry® Xcuze typos if N E _______________________________________________ rdiff-backup-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL:http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
[Prev in Thread] | Current Thread | [Next in Thread] |