You could try using rdiff-backup --no-compression (or
--no-compression-regexp). This will make backups bigger but should speed
up backups and restores.
The only built-in compression offered by rdiff-backup is gzip, but if
you run rdiff-backup --no-compression to a file system using
ZFS-with-LZ4-compression it will be much faster than gzip for backup and
for restore, and the compression will be almost as good. Patrik has
written about this and other benefits of using ZFS, just google
'rdiff-backup zfs advantages'.
Do you often need to restore files? Is there some other change you could
make that would reduce the need for frequent restores? In my case
restores might be slow but they are rare and are lifesavers - so I don't
mind waiting...
BTW, make sure you are using latest'n'greatest rdiff-backup (currently:
stable 2.0.5)...
On 14/10/2021 00:03, billy noah wrote:
Hello,
The older snapshots in my backup scheme take very long to restore as they
are database dumps over 15GB and stored on a rotational drive (which is
more cost effective as a backup volume). I noticed that this is partially
due to the fact the rdiff-backup needs to apply each increment as a patch,
stepping backwards until the desired state is achieved.
Is there a simple way around this? I wouldn't mind taking up the space
needed for a full snapshot if there is some argument that can accomplish
this, but I'm trying to avoid the need to build some complex snapshot
directory rotation in to my script logic. Currently I'm simply doing:
mysqldump --single-transaction --lock-tables=false my_database >
/mnt/mirror/daily/dump/my_database.sql
rdiff-backup --no-eas --no-acls --no-file-statistics
/mnt/mirror/daily/dump/ /mnt/mirror/daily/diff/
rm /mnt/mirror/daily/dump/*sql
rdiff-backup --force --remove-older-than 10D /mnt/mirror/daily/diff/
/dev/null 2>&1
We'd like to keep up to 30 days of increments here but the time needed to
restore something that old would be a bit absurd. I'm thinking something
like 4 full backups with 6 increments each.
I hope this makes sense. Thanks!
