zmschedulebackup and Alternate Backup Location

[LMStone]

Running 4.0.1 Network Edition on SuSE 10.0.

Is it OK to replace the directory /opt/zimbra/backup with a symlink pointing to the desired alternate backup location?

The zmschedulebackup command documentation indicates zmschedulebackup does not support the "-t" switch that the zmbackup command does. As a result, the cron jobs set up by running "zmschedulebackup -D" do not specify our desired alternate target backup directory.

My sense is that it is better to symlink the target backup directory than to edit the three cron jobs created by zmschedulebackup, but I'd like to have someone from Zimbra confirm that, please.

In our case, Zimbra runs on a VMware virtual machine. The alternate backup directory is an LVM partition on the VMware host machine. The VMware host machine exports the backup directory via NFS, and the Zimbra virtual machine (as well as the other virtual machines on this host) use NFS to mount the export to a local directory. A separate machine, off site and connected via a VPN, then uses Dirvish to connect to the VMware host and make off site backups of the LVM backup partition.

Anyone see any issues with this configuration?

Thanks,
Mark

[bobby]

sending zmbackup straight to nfs is prone to failure. the best method is to run the backup to the local disk, then move to external storage

as far as the more general question of the target option, the only concern with editing the crontab is that running zmschedulebackup will reset the change

this is Bug 9539 - zmschedulebackup should allow for target specification

[w1nz]

Bump*

I'm looking to do the same thing... it seems zimbra would only allow me to install it on the OS partition in RHEL4 that is only 30 Gigs. My 2nd partition is 200g which is where I moved my mailstore directory to. I want the backups to save in there as well instead of the default /opt/zimbra/backup. Do you have to just create a sym link to get it to save to say.... /raid5/zimbra/backup?

I was thinking that "ln -s /opt/zimbra/backup /raid5/zimbra/backup" would work. I tried without the -s for the hell of it and it said /opt/zimbra/backup is not allowed to do hard links, so I put the -s in to make it a soft link. I guess I'll know in the morning when it tries to backup again if it actually worked. I'd run a zmbackup now but I don't wanna slow down the e-mail server during business hours.

[phoenix]

Why don't you just install some larger hard disks and relocate the whole /opt/zimbra directory to the new hard drive and install Zimbra on that. Under no circumstances (unless you have a very small number of users and even then I wouldn't recommend it) should you use a RAID5 as the backup device - that configuration has poor write performance.

[w1nz]

well i guess i'm screwed. Our old IMAP server crashed on us while I was still testing Zimbra net edition, and I was forced to implement Zimbra earlier than planned. Our old server was using a raid 1+0 for the OS partition and raid5 for the mailstore partition, so I configured the new server just like that thinking it was good. If this mail server has anymore downtime it's gonna be my ass. We only have 58 users anyway, you think the symbolic link will work for now so I don't have to keep doing "mv (/opt/zimbra/backup/whatever) /raid5/zimbra/backup" ?

[SpEnTBoY]

This may be of no help because I can't speak to the symlink option (and I'm using the OS version) but you could just automate rsync's to the raid partition as part of your pre-backup scripting. Yes it has some IO tagged with it but so would having a symlink to a different fs especially if it's RAID5 (why not mirror? RAID5 is not ideal for heavy IO which is all backups are, is none of this being backed up to tape anywhere?).

At least this way you could tie it in to your existing backup schema ..... unless of course everyone is only doing local backup to disk using the Network version's internal backup operations

In that case this wouldn't buy you anything.

</2 cents>

[mmorse]

Is it OK to replace the directory /opt/zimbra/backup with a symlink pointing to the desired alternate backup location?

using a symbolic link for my backups directory currently-works fine
infact i have the store and index also symbolic linked to elseware

Under no circumstances (unless you have a very small number of users and even then I wouldn't recommend it) should you use a RAID5 as the backup device - that configuration has poor write performance.

For storing the backups of the mailboxes? It's not like your calling it much, hopefully just writing to it

[SpEnTBoY]

Originally Posted by mmorse

using a symbolic link for my backups directory currently-works fine
infact i have the store and index also symbolic linked to elseware


For storing the backups of the mailboxes? It's not like your calling it much, hopefully just writing to it

RAID5 writes are slow by comparison to other RAID options especially if there are large numbers of small files. For each write the parity calculation chews up time in overall I/O cost. The more you have to write and the smaller the files, the poorer your performance using any RAID that employs a parity operation on store (as part of the write operation)

Regards,
Lonny

[LMStone]

Originally Posted by SpEnTBoY

RAID5 writes are slow by comparison to other RAID options especially if there are large numbers of small files. For each write the parity calculation chews up time in overall I/O cost. The more you have to write and the smaller the files, the poorer your performance using any RAID that employs a parity operation on store (as part of the write operation)

Regards,
Lonny

If you use fast disks the performance hit for smaller files is mitigated somewhat, especially if the controller has a large cache (battery-backed one hopes) and does efficient write sorting.

For larger files, using a RAID5 or RAID6 array with six or more disks can actually improve performance, since a single large file write is now broken up into several smaller stripes, all of which are written simultaneously.

In any event, mounting /opt/zimbra/backup on a physically separate disk system will help mitigate disk I/O bottlenecks negatively impacting the end-users' experience.

(For that matter, putting amavis's temp files on a separate partition mounted with noatimes will also help improve performance).

Hope that helps,
Mark

[mmorse]

I was pointing out that you should *hopefully* be only writing TO the backup-if JUST the backup was on a raid 5 config for storage it really doesn't matter a ton-I don't care how long it takes to backup