[Borgbackup] what do I do with inconsistencies?
Thorsten von Eicken
tve at voneicken.com
Wed Jun 22 11:57:08 EDT 2016
Yet another test run, same backup on ARM but using zlib compression and
I get an inconsistency.
# borg check -v usr-local3
Starting repository check
Completed repository check, no problems found.
Starting archive consistency check...
Enter passphrase for key /big/h/usr-local3:
Analyzing archive usr-local-2016-06-20 (1/1)
Archive consistency check complete, no problems found.
# borg init usr-local4
Enter new passphrase:
Enter same passphrase again:
Do you want your passphrase to be displayed for verification? [yN]:
# borg create --show-rc --stats -v -e .cache -C zlib
usr-local4::usr-local-2016-06-20 /big/usr-local
Enter passphrase for key /big/h/usr-local4:
------------------------------------------------------------------------------
Archive name: usr-local-2016-06-20
Archive fingerprint:
ab47bdebc8cbed2a04194139a5d0bd8ce5ec639d578cd65276e51fba043fac41
Time (start): Wed, 2016-06-22 06:23:23
Time (end): Wed, 2016-06-22 07:19:26
Duration: 56 minutes 3.31 seconds
Number of files: 354059
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
This archive: 5.86 GB 2.10 GB
1.63 GB
All archives: 5.86 GB 2.10 GB
1.63 GB
Unique chunks Total chunks
Chunk index: 190159 359426
------------------------------------------------------------------------------
terminating with success status, rc 0
[root at backup h]# borg check -v usr-local4
Starting repository check
Index object count mismatch. 190160 != 190162
Completed repository check, errors found.
On 6/21/2016 9:55 PM, Thorsten von Eicken wrote:
> Yet another test. BTW, would it be better if I opened a github ticket
> with all this info? I'm fine either way as long as it leads to a fix :-)
>
> I did the same backup as previously (rsync'ed the data to the ARM box
> and ran a local backup with lzma resulting in insonsistencies) but
> this time I chose lz4 compression. Guess what... no inconsistency. OK,
> sample size is one, so who knows... It can't be the lzma code itself
> since that runs on the x86_64 box when doing a remote backup, so it
> must be something else around it? Unless it's just chance...
>
> The log of the test is:
>
> # borg init usr-local3
> Enter new passphrase:
> Enter same passphrase again:
> Do you want your passphrase to be displayed for verification? [yN]: n
> # borg create --show-rc --stats -v -e .cache -C lz4
> usr-local3::usr-local-2016-06-20 /big/usr-local
> Enter passphrase for key /big/h/usr-local3:
> ------------------------------------------------------------------------------
>
> Archive name: usr-local-2016-06-20
> Archive fingerprint:
> 7cef44fb78c14ac908b50d4f407e660f680fe95386431c9900fcb6d05d8c23a5
> Time (start): Tue, 2016-06-21 16:15:25
> Time (end): Tue, 2016-06-21 16:56:37
> Duration: 41 minutes 11.83 seconds
> Number of files: 354059
> ------------------------------------------------------------------------------
>
> Original size Compressed size Deduplicated
> size
> This archive: 5.86 GB 2.81 GB
> 2.24 GB
> All archives: 5.86 GB 2.81 GB
> 2.24 GB
>
> Unique chunks Total chunks
> Chunk index: 190022 359242
> ------------------------------------------------------------------------------
>
> terminating with success status, rc 0
> # borg check -v usr-local3
> Starting repository check
> Completed repository check, no problems found.
> Starting archive consistency check...
> Enter passphrase for key /big/h/usr-local3:
> Analyzing archive usr-local-2016-06-20 (1/1)
> Archive consistency check complete, no problems found.
>
> How can I help from here on?
>
>
> On 6/21/2016 9:15 AM, Thorsten von Eicken wrote:
>>
>> More tests, looks like borg 1.0.4 with lzma doesn't work on ARM, or
>> the Arch build is broken. I narrowed the backup that fails to about
>> 6GB of /usr/local. I did a remote backup x86_64->ARM and got the
>> usual inconsistency. I then rsync'ed /usr/local to the ARM box and
>> did a local backup there and got the same inconsistency. Something I
>> haven't mentioned before is that I run two other backups x86_64->ARM
>> nightly and they do not produce inconsistencies, but they also do not
>> use any compression (they're all compressed media files).
>>
>> I can continue testing various combinations but maybe one of the borg
>> maintainers has an rPI or ODROID or other ARM box and can run some
>> tests as well? As far as I can tell you need a dir structure of some
>> minimum size (I tried something tiny and it worked fine) and then
>> perform a borg create with lzma.
>>
>> Here's the log:
>>
>> # borg init usr-local2
>> Enter new passphrase:
>> Enter same passphrase again:
>> Do you want your passphrase to be displayed for verification? [yN]: n
>> # borg create --show-rc --stats -v -e .cache -C lzma
>> usr-local2::usr-local-2016-06-20 /big/usr-local
>> Enter passphrase for key /big/h/usr-local2:
>> ------------------------------------------------------------------------------
>>
>> Archive name: usr-local-2016-06-20
>> Archive fingerprint:
>> c2bc42a6f7837cf44ca3e4182ebe2e01437876b3c24a8551668b19dcd9b14ce8
>> Time (start): Tue, 2016-06-21 02:54:38
>> Time (end):�� Tue, 2016-06-21 08:17:51
>> Duration: 5 hours 23 minutes 13.95 seconds
>> Number of files: 354059
>> ------------------------------------------------------------------------------
>>
>> ����������������������
>> Original size����� Compressed size��� Deduplicated size
>> This archive:��������������� 5.86
>> GB������������� 1.80
>> GB������������� 1.35 GB
>> All archives:��������������� 5.86
>> GB������������� 1.80
>> GB������������� 1.35 GB
>>
>> ����������������������
>> Unique chunks�������� Total chunks
>> Chunk index:�����������������
>> 190030�������������� 359279
>> ------------------------------------------------------------------------------
>>
>> terminating with success status, rc 0
>> # borg check -v usr-local2
>> Starting repository check
>> Index object count mismatch. 190031 != 190041
>> Completed repository check, errors found.
>>
>>
>> On 6/20/2016 5:42 AM, public at enkore.de wrote:
>>> On 06/20/2016 09:27 AM, Thorsten von Eicken wrote:
>>>> I'm wondering what to test next. Some thoughts:
>>>> - rsync the data to the ARM box and perform a local create/check there
>>>> - nfs mount the data onto the ARM box and perform a local create/check
>>>> this way
>>>>
>>>> Suggestions?
>>>> Thorsten
>>> Try (1) first to see whether it's a networking-related issue or happens
>>> even with local files.
>>>
>>> Cheers, Marian
>>>
>>> _______________________________________________
>>> Borgbackup mailing list
>>> Borgbackup at python.org
>>> https://mail.python.org/mailman/listinfo/borgbackup
>>
>>
>>
>> _______________________________________________
>> Borgbackup mailing list
>> Borgbackup at python.org
>> https://mail.python.org/mailman/listinfo/borgbackup
>
> _______________________________________________
> Borgbackup mailing list
> Borgbackup at python.org
> https://mail.python.org/mailman/listinfo/borgbackup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/borgbackup/attachments/20160622/907fc052/attachment.html>
More information about the Borgbackup
mailing list