1

I'm doing backup with the command like following:

ionice -c3 tar -ch data | lbzip2 -n 4 | ionice -c3 tee /mnt/smb/out.tar.bz2 > /dev/null

and after that I'm trying to restore data from backup:

lbzip2 -cd -n 10 /mnt/smb/out.tar.bz2 | tar -x 

In a hour after start lbzip2 fails due to file integrity error.
/mnt/smb is RAID 1 device on windows machine accessed with SMB protocol.
I suspect errors while writing on disk or sending data with smb but not sure.

So, I've got 2 questions:

  1. Is it any way to check archive integrity during writing on disk and retry to write block if check fails?
  2. Any ideas how to find out actual reason of the fail?

3 Answers 3

2
tar -c ... \
| tee >(md5sum >/tmp/tar.md5) \
| lbzip2 \
| tee >(md5sum >/tmp/bz2.md5) \
> /mnt/smb/out.tar.bz2

Then you can check

md5sum /mnt/smb/out.tar.bz2

and see if it returns the same as what was saved in /tmp/bz2.md5. If so, then you should have no storage problem, and I'd be interested in the exact lbzip2 error message, and whether the saved file can be decompressed by official bzip2. Thanks. (Feel free to contact me in email.)

1
  • Thanks. Checksums didn't match. Probably, the problem is a file storage (or samba), so I've decided to use rsync instead of tar and It's enough for now. lbzip2 is nice and It works for good with another storage, mounted with NFS. Sep 23, 2011 at 6:21
1
  1. With all integrity problems, the first task is to check your hardware. Is your RAID sane ? Are your harddrive throwing S.M.A.R.T errors ?
  2. writing blocks and controlling their integrity is the job of the kernel, not yours. Your job is to ask the kernel to write a file in a coherent way, which leads me to 2.
  3. Your are piping your data over 5 different programs. tar is unlikely to corrupt any data, because the code is widely used and ironed (but you never know), but I'm not so sure about lbzip2 and ionice. Before going to crazy things like checking the integrity of blocks at the FS level, use a bash command that is less complicated. a single "tar" should do. And verify that the created file has no integrity problem. Then go to 3.
  4. If your issue is network related, the best way to diagnose it is to look at the logs (/var/log/* or events logs on windows) and the network packets. I would plug a tcpdump on the linux/unix or a wireshark on the windows, and verifying that the TCP checksums are not corrupted.

But, really, get rid of all those pipes before ...

10
  • ionice doesn't make sense, it just decreases i/o priority. It was tested with another backup storage on linux (with nfs) and worked for good. Sep 13, 2011 at 13:09
  • but your have to pipe the data throught it, and you do it multiple times. so how do you know it doesn't affect data ordering and block writing ? before going for complex, start with a single tar and verify it works ! Sep 13, 2011 at 13:11
  • I've started single tar operation. I hope it will finish in a day. Sep 13, 2011 at 13:27
  • bzip2 is painfully slow. Why dont you use a standard tar czf`?
    – Nils
    Sep 13, 2011 at 20:10
  • @Nils, there are a lot of reasons. On the one hand we compress in multiple threads (and pigz is not good solution). On the another hand we should strictly control i/o priority due to really high server load. For example, for some mad reason tar -czf has made load average increase from 12 to 60 and it was the reason of big set of problems. Sep 14, 2011 at 9:25
0

Since your destination is a CIFS-share on a Windows-box - why don`t you use a Windows-compressed filesystem on the Windows-side and just use plain tar (without compression) on the Linux-side?

That way you can put the compression load on the windows box - and get rid of a lot of complexity.

BTW: Have you checked the network connection to the windows-box? Do you get any network errors?

  • netstat -in
  • ethtool -S eth0|grep -vw 0 (replace eth0 with the network card the CIFS connection uses)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .