Remote mirroring of /opt/zimbra/backup dir using rsync over low-bandwidth link

[ewilen]

For future reference, please put your Zimbra version into your profile. Right now a forum bug makes this a little tricky, but if you refer to the link in my signature you'll see how to do it.

Anyway, with ZCS 6, I believe the default is to use the --zipStore option; see CLI - zmbackup Network Edition Only - Zimbra :: Wiki . So I don't know why your directory structure is unzipped. To verify that there's a hardlink, you can use ls -i on a given subdirectory or file within two full backups. (If it's easier to read you could use ls -il or ls -i1.)

E.g. (partial output):

ls -i1 full-20111029.080012.959/accounts/a0f/a9b/a0fa9bf3-4176-4434-91b9-c7cb4b52468d/blobs/1/0/
190814340 9IZUH6,Zmtm02XCzJZw1JIYqo1M=3354-4719.msg1

ls -i1 full-20111105.080011.376/accounts/a0f/a9b/a0fa9bf3-4176-4434-91b9-c7cb4b52468d/blobs/1/0/
190814340 9IZUH6,Zmtm02XCzJZw1JIYqo1M=3354-4719.msg1

The number in the first column is the inode; since it's the same, the two directory entries are hardlinked.

As for getting --noZip to persist across upgrades, not with ZCS 6, but yes with ZCS 7; see Bug 45634 - add noZip option to zmschedulebackup. However, it's no big deal to just reenter it after each upgrade. The best way is to first do (as zimbra) zmschedulebackup -D to setup the default schedule, then edit the crontab directly with crontab -e. If you don't do this, then not only will the --noZip option be erased, but some of the backup schedule will be gone, too.

WRT setting it in the GUI, they're still working on that: Bug 28199 - Add new zip backup options to admin UI

[Apple_Eater]

Just checked my backups, and in fact they *were* zipped. I hadn't browsed all the way down into the individual blobs, but upon doing so I found the zip files.

I have added --noZip to all my scheduled backup entries in the crontab.

I then ran two full backups and rather than the size being (full backup) * 2 it was roughly (full backup) indicating that the hardlinks are working and reducing the size of each full backup significantly.

I'll try replicating the resulting backups offsite and see what sort of size difference there is, but it looks like this may have solved my issues.

[Apple_Eater]

Just to follow up for others who may stumble upon this post, after implementing the --noZip option for Zimbra backups and the --hard-links option for RSync, our backup is transferring only new data, causing our data transferred to be ~4GB per week instead of ~80GB for every full backup.

Thus we are able to keep many months of full/incremental backups onsite/offsite over the 2MBit link. So this problem is certainly solved!