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.)
