mainstoreBackup - Support: sr #107887, problems with recovering blocked...

 
 

sr #107887: problems with recovering blocked file and errors reported by StoreBackupCheckBackup

Submitter:  None
Submitted:  Wed 23 Nov 2011 06:55:54 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 31 May 2012 09:31:44 PM UTC, comment #3: 

corrected in 3.2.1

 Heinz-Josef Claes <hjclaes>
Group administrator
Wed 23 Nov 2011 10:21:35 PM UTC, comment #2: 

Thanks for your speedy reply.

The number of files listed in .md5CheckSum matches the number of 00*.bz2 files in .../archive.pst/. I've checked this for a few backups and the numbers of files all match.

Running bzcat / diff as you suggested indicates that there is no problem with the blocked file backup (well, at least not with the most recent one).

I checked the file system and I didn't see anything obvious. I've copied the fsck output below.

Also I have tried restoring another blocked file (for which storeBackupCheckBackup didn't report any errors) and again the restored file was way smaller than the original. Perhaps I have a problem with both storeBackupRecover and storeBackupCheckBackup?

Please let me know if you are interested in seeing any log files or screen output.

thanks,
Matt


matt@matt-X201:~$ sudo fsck -yvf /dev/mapper/usb_disk2
fsck from util-linux-ng 2.17.2
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

  167732 inodes used (1.10%)
    2525 non-contiguous files (1.5%)
     234 non-contiguous directories (0.1%)
         # of inodes with ind/dind/tind blocks: 66272/4344/1
55117154 blocks used (90.28%)
       0 bad blocks
       4 large files

  133048 regular files
   34644 directories
       0 character device files
       0 block device files
       0 fifos
  366281 links
      31 symbolic links (31 fast symbolic links)
       0 sockets
--------


Anonymous
Wed 23 Nov 2011 08:21:13 PM UTC, comment #1: 

Hi,

I cannot remember about such a bug ...

Can you run a file system check?

storeBackupCheckBackup in your version is far away from being perfect ;-) . I have a better one. Please send me an email, so I can mail you a better version.

I do not believe the output of storeBackupCheckBackup.
Can you double check file .md5CheckSum in .../archive.pst ? Are these lines really missing? I expect the files are missing.

If these files are simply missing, then it's not a problem to link to them. A hard link to a missing file cannot be done and storebackup then creates a new copy. This is NOT true, if you use lateLinks. But you should get error messages from storeBackupUpdateBackup in that case.


Please run fsck and send me an email with the answer to my question above.


The easiest way to double check if a blocked file in the backup is stored correctly should be:

cd <backupDirOfBlockedFile>
bzcat * | diff - <originalFile>


Heinz-Josef Claes <hjclaes>
Group administrator
Wed 23 Nov 2011 06:55:54 PM UTC, original submission:  

Hi,

I recently tried to recover a blocked file to check it was being stored properly. StoreBackupRecover recovered the file and reported no errors, however the recovered file was much smaller than the original. I ran StoreBackupCheckBackup and it reported a lot of blocks were missing from the md5Checksum. Here are few lines:

ERROR     2011.11.23 18:02:28  8216 <outlook_files/archive.pst/0000000036.bz2> is not listed in .md5CheckSum
ERROR     2011.11.23 18:02:28  8216 <outlook_files/archive.pst/0000001293.bz2> is not listed in .md5CheckSum
ERROR     2011.11.23 18:02:28  8216 <outlook_files/archive.pst/.md5BlockCheckSums.bz2> is not listed in .md5CheckSum
ERROR     2011.11.23 18:02:28  8216 <outlook_files/archive.pst/0000001235.bz2> is not listed in .md5CheckSum
ERROR     2011.11.23 18:02:28  8216 <outlook_files/archive.pst/0000001090.bz2> is not listed in .md5CheckSum

I am also getting an error message relating to line 846 in StoreBackupCheckBackup:

INFO      2011.11.23 18:03:05  8216 checking </media/woolly/snaps/matt-x201/2011.06.18_10.50.31> ...
Use of uninitialized value $rel in hash element at /usr/bin/storeBackupCheckBackup line 846.
Use of uninitialized value in numeric eq (==) at /usr/bin/storeBackupCheckBackup line 846.
Use of uninitialized value $rel in hash element at /usr/bin/storeBackupCheckBackup line 846.
Use of uninitialized value in numeric eq (==) at /usr/bin/storeBackupCheckBackup line 846.
INFO      2011.11.23 18:07:20  8216 checking </media/woolly/snaps/matt-x201/2011.06.24_19.59.41> ...
Use of uninitialized value $rel in hash element at /usr/bin/storeBackupCheckBackup line 846.
Use of uninitialized value in numeric eq (==) at /usr/bin/storeBackupCheckBackup line 846.
Use of uninitialized value $rel in hash element at /usr/bin/storeBackupCheckBackup line 846.
Use of uninitialized value in numeric eq (==) at /usr/bin/storeBackupCheckBackup line 846.

I am running version 3.2 of storebackup. I am using linux and storing on an ext3 external HDD. How can I fix these errors? Do I need to delete the blocked file from affected backups so that they are not linked to by future backups? Is there a way to delete individual files / directories from backups so that the md5checksums are updated and StoreBackupCheckBackup won't report missing files / directories?

Many thanks,
Matt



Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hjclaes (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-05-31 hjclaes StatusNone Done

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-3b9d.
    Corresponding source code