ZCS Backup Report: FAIL

[carlswart]

I have upgraded ZCS from 5.0.18 to 6.0.5 on CentOS4.

Release 6.0.5_GA_2214.RHEL4_20100202202825 CentOS4 NETWORK edition.

The upgrade completed without any errors, or so it seems.

When I try to run full backup, it fails.

The error message is:
Server: zimbra.example.com

Label: full-20100221.080024.698
Type: full
Status: completed (with errors)
Started: Sun, 2010/02/21 10:00:24.698 SAST
Ended: Sun, 2010/02/21 10:09:06.592 SAST
Redo log sequence range: 5744 .. 5744
Number of accounts: 1
Number of errors: 1


ERRORS

email@example.com: Input/output error
java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java: 177)
at com.zimbra.common.util.FileUtil.copyOIO(FileUtil.j ava:204)
at com.zimbra.common.util.FileUtil.copyOIO(FileUtil.j ava:194)
at com.zimbra.common.io.AsyncFileCopier$WorkerThread. copy(AsyncFileCopier.java:155)
at com.zimbra.common.io.AsyncFileCopier$WorkerThread. run(AsyncFileCopier.java:115)


Below is a full backup of one of the problem accounts.

Only the 2 BIG accounts fail with the same error below.

The email@example.com is 4.4GB as per the ZWC.

I tried to export the account using:
/opt/zimbra/bin/zmmailbox -z -m email@example.com getRestURL "//?fmt=tgz" > /backup/email-example-com.tgz

This created a 2185685471 bytes file:
-rw-r--r-- 1 root root 2185685471 Feb 21 08:23 email-example-com.tgz

Testing the .tgz file, it gives me errors:
[root@zimbra backup]# file email-example-com.tgz
email-example-com.tgz: gzip compressed data, from MS-DOS
[root@zimbra backup]# tar tzvf email-example-com.tgz | less
[root@zimbra backup]# mkdir tmp
[root@zimbra backup]# cd tmp/
[root@zimbra tmp]# tar zxf ../email-example-com.tgz
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Does /tmp directory get used by zmbackup?

What else can I try?

[phoenix]

I'm not sure what this has to do with the NE backup nor what you're trying to achieve, perhaps you could explain in a bit more detail. If you wish to export a mailbox then you should do that as root and store it in another directory so you can work on it, the 'tmp' directory should already exist in the /backup dir and the NE backup does use it during a restore.

[carlswart]

I added the error message to the original post to make the post complete. Sorry about that.

Below is hopefully a better explanation.

Goal:
Main: Create a full backup of ZCS after the upgrade to 6.0.5.
Sub Goal: Test the ZCS NE 6.0.5 backup tools.

Action Taken:
Try 1: zmbackup -a example@example.com -d -f -t /backup/tmp/
Try 2: zmbackup -a example@example.com -d -f --noZip -t /backup/tmp/

Results:
Results 1:
Server: zimbra.example.com

Label: full-20100219.230005.554
Type: full
Status: completed (with errors)
Started: Sat, 2010/02/20 01:00:05.554 SAST
Ended: Sat, 2010/02/20 03:42:50.626 SAST
Redo log sequence range: 5743 .. 5743
Number of accounts: 1
Number of errors: 1


ERRORS

example@example.com: Input/output error
java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java: 177)
at com.zimbra.cs.backup.util.ZipUtil.computeCRC32(Zip Util.java:24)
at com.zimbra.cs.backup.util.ParallelZipCopier$ZipCop ierThread.run(ParallelZipCopier.java:185)

Results 2:
Server: zimbra.example.com

Label: full-20100221.080024.698
Type: full
Status: completed (with errors)
Started: Sun, 2010/02/21 10:00:24.698 SAST
Ended: Sun, 2010/02/21 10:09:06.592 SAST
Redo log sequence range: 5744 .. 5744
Number of accounts: 1
Number of errors: 1


ERRORS

example@example.com: Input/output error
java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java: 177)
at com.zimbra.common.util.FileUtil.copyOIO(FileUtil.j ava:204)
at com.zimbra.common.util.FileUtil.copyOIO(FileUtil.j ava:194)
at com.zimbra.common.io.AsyncFileCopier$WorkerThread. copy(AsyncFileCopier.java:155)
at com.zimbra.common.io.AsyncFileCopier$WorkerThread. run(AsyncFileCopier.java:115)

Conclusion:
The problem does not have anything to do with the zip compression.

Solution?
None that I know of at present.

--
Regards,
-Carl

[phoenix]

Is your /opt/zimbra/backup folder actually on a local disk, is it mounted elsewhere or is it a link to another mountpoint?

BTW, why are you trying to use this folder /backup/tmp/ for the backup and is that in the normal /opt/zimbra directory?

[carlswart]

/opt/zimbra/backup is locally mounted on /dev/md3. Actually / is mounted on /dev/md3 and /opt/zimbra/backup is only a normal sub directory on /dev/md3. /dev/md3 consists of /dev/sda5 and /dev/sdc5, which are local disks.

I first noticed the backup is not completing while backing up to /opt/zimbra/backup.

I am setting the target for the backup to /backup/tmp because I am trying to debug the problem. /backup is mounted on /dev/sdb1 which is a 400GB local disk.

So to answer your questions:

Is your /opt/zimbra/backup folder actually on a local disk, is it mounted elsewhere or is it a link to another mountpoint?

/opt/zimbra/backup is mounted on a local disk.

BTW, why are you trying to use this folder /backup/tmp/ for the backup and is that in the normal /opt/zimbra directory?

I am using /backup/tmp during the debugging phase. The initial problem appeared while backing up to /opt/zimbra/backup. No /backup/tmp does NOT form part of /opt/zimbra.

________________
Carl