Automated Export of Local Folders?

[LHammonds]

If I am to roll out Zimbra Desktop as a replacement for Outlook for our Windows XP and Windows 7 workstations, one of the major factors is the ability to backup a user's "local" mail storage.

Currently, we do this by simply copying their local .PST file(s) to their private network drive. They typically have a PST file per year.

From what I have read, it is not recommended to simply copy Zimbra's local data folders.

Is there a way to automate the export process of the local folders?

Does this automation require Zimbra Desktop to be running or shut down?

If the export can create a file similar to C:\Users\username\zimbrabackup\username.tgz, I can configure our Login scripts to pull the current user's archive from the local system to their private drive.

However, the ideal situation would be a local storage folder structure that I could "sync" with a network location. New messages would be new files (or at least minimized such as all messages for a day going into a single file for the day, etc.) and thus, only changes would be copied rather than copying a potentially HUGE archive over and over. A single archive for every user, every day could put considerable strain on bandwidth for data synchronization to remote sites as the data grows.

Thanks,
LHammonds

[ccelis5215]

Hi, yes you can.

Look in Zdesktop Help

Desktop > Managing your Account Content > Backing up your accounts

However, it generate a full backup per account in .tgz file, not a incremental as you wish.

Hope it helps.

[LHammonds]

Originally Posted by ccelis5215

Hi, yes you can.

Desktop > Managing your Account Content > Backing up your accounts

Awesome! Thanks. I don't know how I missed that. The help file was the 1st place I looked.

Originally Posted by ccelis5215

However, it generate a full backup per account in .tgz file, not a incremental as you wish.

hmm...I may be able to get around that by scripting the archive to be extracted BEFORE running a sync on the folder. That "might" allow for just delta backups. I'll need to test this out though.

Originally Posted by ccelis5215

Hope it helps.

It most certainly does.

+1 kudos!

Thanks,
LHammonds

EDIT:

Using 7-Zip 9.20, 64-bit on Windows 7, 64-bit, I am able to uncompress the local@host.local_2011-10-24_145442.tgz file to local@host.local_2011-10-24_145442.tar. However, when I uncompress the tar file to the individual files, I get the following message: "There are data after end of archive"

The uncompressed, individual files are exactly what I am looking for to sync just the delta change on the source computer to the offsite destination repository.

However, this error makes this process useless unless I can uncompress and re-compress the archive in such a way that it can be imported back into Zimbra Desktop without error.

Because of this error notification during extract (I think), the re-compressed tar/gz does not import back into Zimbra Desktop without warnings such as content missing and meta information does not match content. Either 7-Zip cannot handle the format (which documentation says it can) or extracting on top of an NTFS volume cannot retain necessary information.

I even tried the command line version of 7-zip with no success (same warning message):

C:
CD \Users\UserID\AppData\Local\Zimbra\zd_backup
7z.exe e *.tgz && 7z.exe x *.tar

EDIT:

I downloaded the GNU Tar 1.13-1 binary for Windows along with the require dependency DLLs and ran tar -xvf *.tgz but it got mad and closed with this message:

tar: Only read 6835 bytes from archive local@host.local_2011-10-24_145442.tgz
tar: Error is not recoverable: exiting now

EDIT:

Also tried the tar utility in UnxUtils but got the exact same error message as the above.

I'm starting to wonder if there is something special done to the archive upon creation.

EDIT:

Well, I'm giving up on the method of extracting the archive for delta backups.

If anyone knows how to properly extract and re-create the archive (on a Windows machine), please let me know.

Thanks,
LHammonds

[ccelis5215]

Hi,

I transfer the file to the Linux Box, gunzip and tar xvf worked well, that means that's it's nothing rare with the files.

I mean, give a try in Linux and achieve your goal!

Of course, you have to transfer every file to Linux... i forgot your considerations about remote sites.

Regards.