FWIW, my script(s) run "df -h" on the volume (as suggested in the FAQ
entry) before and after so I can see the effect of my "remove increments
--older-than 1Y" and "backup --print-statistics" invocations, so I knew
was down to 5% free, but I also (thought I) had a good idea of the rate
of
Thanks Eric,
Idea #1 didn't help (none of the .gz files where corrupt), but the
diagnostic messages I got running idea #2 helped me realize that I
needed to remove a(nother) current_mirror, and after I did that the
regress succeed, and a subsequent backup also succeeded. After that,
Hi,
too late for Peter's issue, but I created an example on how to avoid the
issue (or at least reduce the risk):
https://github.com/rdiff-backup/rdiff-backup/pull/947
Review welcome.
BTW, check also
Anyone have any suggestions?
If nothing else, is there some way I could remove appropriate files from
the rdiff-backup-data directory to get my backups working again?
thanks,
Peter
On 2023-11-13 13:01, Peter Canning wrote:
Here's the command I've been using, with -v 6 added, followed by the
Here's the command I've been using, with -v 6 added, followed by the
output it produced:
C:\Users\pcanning\rdiff-backup-2.2.2-64\rdiff-backup.exe -v 6 backup
--print-statistics `
--exclude "H:/Lightroom/Processing Catalog/Backups" `
--exclude "H:/Lightroom/Processing
Hello Peter,
I apologize for the inconvenience you've experienced in recovering your
backup after encountering space issues. Typically, rdiff-backup can handle
recovery seamlessly following an increase in disk space. However, it seems
that the manual changes you made might have caused
Using rdiff-backup 2.2.2 on Windows 10 Pro 22H2, I have a scheduled task that
runs my system backup PowerShell script at 2 AM every morning. The script runs
rdiff-backup several times to backup several different directories. A few days
ago one of the backups failed because the NAS volume
