Hi Eric,
* "Eric L. Zolf" [2021-07-06; 07:31]:
> My recommendation would be to throw away the backup repository and start
> a new one, preferably on a different disk drive if you don't know why
> the file system was corrupted in the first place. You don't want to keep
> your backup on hardware
On 06.07.21 01:46, griffin tucker wrote:
the latest version is v2.0.5 - debian is slow with stable builds so
buster doesn't include v2.0.5 with apt-get
The idea behind Debian stable is that it should be stable. Therefore
Debian stable won't get major software updates.
However:
Hi,
the version 2.0.5 won't help here IMHO, there are two issues:
1. the "Unknown field" errors hint at the fact that the file system
issue has corrupted the metadata of the repository. This will be
difficult to impossible to fix, more on this later.
2. the traceback is actually due to an
Hi,
the version 2.0.5 won't help here IMHO, there are two issues:
1. the "Unknown field" errors hint at the fact that the file system
issue has corrupted the metadata of the repository. This will be
difficult to impossible to fix, more on this later.
2. the traceback is actually due to an
On Tue, 6 Jul 2021 at 07:47, Gregor Zattler wrote:
>
> Dear rdiff-backup users and developers,
>
> lately I had to do a fsck.ext4 -y on the filesystem which
> hosts my rdiff-backup. Then I had tracebacks when I
> attempted the next backup. What to do in such a case?
>
> Is there any hope to
Dear rdiff-backup users and developers,
lately I had to do a fsck.ext4 -y on the filesystem which
hosts my rdiff-backup. Then I had tracebacks when I
attempted the next backup. What to do in such a case?
Is there any hope to revive this rdiff-backup?
This is rdiff-backup 1.2.8 on Debian 10.10
