Ajcody-Notes-ServerPlanning
What About Backups? I Need A Plan
These are just my random thoughts. They have not been peer-reviewed yet.
A. Local disk configuration.
I would have 3 disk subsystems.
1. For OS / - this could be whatever - local mirrored SATA/SCSI drives
A. Make sure /tmp has enough space for operations
2. /opt/zimbra/back - I would make sure the disk I/O is separate from /opt/zimbra . This way you minimize performance hits to your end-users. Do a review the disk i/o | bus is clean as possible to the cpu/memory. Motherboard spec's should tell you want "slots" are on shared buses. Make sure you maximizing your raid/san cards performance to the bus path to the cpu.
A. I would make this a multiple of x4 the /opt/zimbra space that your spec'ing. This would allow for a couple of weeks of full's and the daily diffs.
B. Remember in when you consider you disk chassis infrastructure.
C. As an example, for /opt/zimbra I might go with a 16 disk enclosure that uses very fast & low latency disks which also means "smaller" disks. 16x73GB FB 10000 RPM's. And then fill another 16 disk enclosure with price performance disk for /opt/zimbra/backup. 16xSATA's @ 250GB's and 10,000 or 7200 rpm's (latency is different). [This is more of a price point question]
3. /opt/zimbra - same as #2 considerations
B. Network
A. I would be on GB and have one dedicated port for moving data off of the system and another port (channel-bonded or not) dedicated for production (end-user) use. I would rsync over the backup network port (as shown on wiki - http://wiki.zimbra.com/index.php?title=Ajcody-Notes-ServerMove ). I would actually get two separate dual-port cards and placed in the best "bus" for performance [motherboard spec situation here] For one card, I would channel-bond them for /opt/zimbra/backup. This requires you to map out the network path and switches to the end host the data is being moved to. You'll also need to confirm the network path actually gives you a gain in performance by doing the channel bonding. For the other card, I would setup ip take over for the production port. This is incase of port failure. Your customers most likely will not saturate this port..but if they do, you can also channel bond later.
C. Hot-spare server
Setup along the same lines... though you could cut out some of the HA/performance items if you only see this box being used for "short-term" use. Rsync's will occur over backup network port.
A. I would do an initial rsync of /opt/zimbra (remember to use nice flag to not effect prod to much)
B. I would then setup 2 daily rsync jobs
1. rsync /opt/zimbra/backup
A. This could be intergrated within the backup cron job so it kicks off after the backup is done. You'll need to monitor the times of backups and also the time for sync's so you can make sure you make it within the window of rotation - backup , rsync , next backup. Times will be different on diff and full backups.
2. rsync :
/opt/zimbra/conf /opt/zimbra/redolog /opt/zimbra/log
This will give some "sanity" in case issues arise with the full restore. This part could use some better feedback from more experience Zimbra staff. I can think of some circumstances where his effort would prove useful.
