Re: Why are you using rdiff-backup?

On 26/03/2021 12:44, Reio Remma wrote:
> On 26.03.2021 14:41, Arrigo Marchiori wrote:
>> I would like to add:
>>
>>   * Multi-platform (I have used it on Windows, Linux, FreeBSD)
>>
>>   * Easy to deploy and schedule, because all parameters are given on
>>     the command line
>>
>>   * Command-line interfaces allows easy scheduling and execution on
>>     remote Unix machines
>
> A big plus to me is the ability to do a read-only pull backup.

I have used rdiff-backup since 2008 for daily backups of data from 
Windows and Linux machines on our small business network. I particularly 
like/value:

- Ability to recover very old versions of files from a specific date
- Efficient data transfer and storage [use of rdiffs (deltas)]
- The reverse rdiff approach is so much better than the more 
commonly-used forward diffs (e.g. duplicity)
- Reliability for long-term backup (but see my comments about 
verifications below)
- Runs under python3 (thanks Eric and others - heroes)
- Because it runs daily on our system I can mess with a file (e.g. a 
script) and when I completely break it I can always get back the most 
recent or an earlier backup from the repo

It has saved us several times. An example: auditors asked us to show the 
background data for a report generated eight months earlier and when we 
tried to do this using our current financial database (but 'as at' the 
original date) it came out different and we could not explain why (some 
backdated changes/deletions I guess). I was able to use rdiff-backup to 
recover the database from the time when the report was run (say 240 
backup runs previously) and thus provide the required explanation to 
auditors.

Here are a few cons/limitations/enhancement suggestions - but don't get 
me wrong I thing rdiff-backup is great:
- Verification is laborious and slow, the only way to be 100% confident 
is by frequent verifications of each repository run separately for each 
backup date/time - I have a rolling verification process that verifies 
recent backups and selected older ones (esp. the oldest) - and track 
this in file /rdiff-backupdata/verified.log. This is an area where 
rdiff-backup could be improved I think.
- It is not really suitable for system backups not least because it has 
no concept of partition/volume backup/recovery; I have not tried/trusted 
it for system file backups (either for Windows or Linux). It is not the 
tool for those jobs.
- The size and extended history of [our] repositories means that 
Rdiffweb, the supercool web-based GUI for managing repositories and 
recovering data, is usually too slow and sometimes unstable, so I tend 
to use command line - this is fine for me but means non-techies have no 
chance.
- There is no easy way to rollback one or more recent backup sessions 
(unless it is deemed faulty by rdiff-backup's internal checks) except by 
my rdiff-backup-regress script ;-) - also there is no built-in way to 
know when a new backup session has bloated the repository (e.g. because 
of some new huge temporary folder), again I use my own 
timedicer-bloatwatch script to monitor for this.
- Usage to a Windows destination (or using NFS) seems little tested and 
(based on comments I have seen on the mailing list over the years) 
bugs/problems may exist
- I have encountered problems recovering data (from Linux backup repos) 
to Windows folders where permissions do not inherit properly and have to 
be reset with icacls. (This may not be a bug in rdiff-backup.)