I've got a client running Zimbra Network Edition v6.0.13 on Ubuntu 8.04.
They're interested in freeing up extra space on the server, and ideally want to do this by moving the Zimbra server backups off of the server and onto another server, ideally via a mounted network drive. Is this possible?
Store Zimbra Backups Off Server
Store Zimbra Backups Off Server
[quote user="eatickets"]I've got a client running Zimbra Network Edition v6.0.13 on Ubuntu 8.04.
They're interested in freeing up extra space on the server, and ideally want to do this by moving the Zimbra server backups off of the server and onto another server, ideally via a mounted network drive. Is this possible?[/QUOTE]
Yes very much so. You can symbolic link the /opt/zimbra/backups or change the backup location in the admin console. I current have my backups going to a Samba share, works like a charm.
They're interested in freeing up extra space on the server, and ideally want to do this by moving the Zimbra server backups off of the server and onto another server, ideally via a mounted network drive. Is this possible?[/QUOTE]
Yes very much so. You can symbolic link the /opt/zimbra/backups or change the backup location in the admin console. I current have my backups going to a Samba share, works like a charm.
Store Zimbra Backups Off Server
My apologies, I mis-spoke: are there any solutions aside from a network-mounted backup? (i.e. an FTP solution or a Zimbra plugin that will let us save the backups off-server without forcing us to keep the backup server space connected regularly) The solution must be integrated with Zimbra in such a way that if the backup drive space is not connected, Zimbra will still function regularly and not create a new full backup just because it can't find the full backup it just moved to the remote storage space. My client doesn't want NFS or external physical drive options.
Store Zimbra Backups Off Server
I don't see any way to accomplish this short of a network connected drive of some sort (NFS/iSCSI). You may be able to mount a remote drive via SSH (sshfs or something similar) but that's just the same animal with different stripes.
-
lytledd
- Outstanding Member
- Posts: 536
- Joined: Sat Sep 13, 2014 12:54 am
- ZCS/ZD Version: Release 9.0.0.ZEXTRAS.20221203 FOSS
Store Zimbra Backups Off Server
We use a 2TB usb mounted Western Digital drive (I have 4), when the first 1 fills up, I unmount it, tag it and send it over to our offsite facility. I then mount a fresh one, making sure the permissions are set to zimbra:zimbra and continue on.
Our fulls are on a Saturday, so I swap out on a Friday afternoon. When I need to restore, I grab the correct drive and re-mount it.
Works very well!
Doug
Our fulls are on a Saturday, so I swap out on a Friday afternoon. When I need to restore, I grab the correct drive and re-mount it.
Works very well!
Doug
Store Zimbra Backups Off Server
[quote user="eatickets"]My apologies, I mis-spoke: are there any solutions aside from a network-mounted backup? (i.e. an FTP solution or a Zimbra plugin that will let us save the backups off-server without forcing us to keep the backup server space connected regularly) The solution must be integrated with Zimbra in such a way that if the backup drive space is not connected, Zimbra will still function regularly and not create a new full backup just because it can't find the full backup it just moved to the remote storage space. My client doesn't want NFS or external physical drive options.[/QUOTE]
You can rsync your backups to another location. That should fill the bill.
Another possibility would be a network backup solution. We use Retrospect because we already owned it and it is hard-link-aware, which is useful when you do backups using --noZip. See also Ajcody-Backup-Restore-Issues - Zimbra :: Wiki
Basically you would still do your backup to the local drive, but you could set your deletion horizon to a shorter period--as short as one day if you don't care about hardlinking across full backups using --noZip. If you do this, though, you want to make damn sure that your rsync (or whatever) is copying each backup before it gets deleted. Probably the way to do this would be to take the backup deletion out of the zimbra crontab and instead call zmbackup -del as part of clean-up after shipping the backups to the remote storage.
If you want to absolutely minimize the local space used by backups over any time period, then you'll need a script that only calls zmbackup when the remote storage is available. Then, if you want, you could backup directly to the remote storage. Or you could create the backup locally and then immediately rsync (etc.) it, then delete it. (zmbackup -del 0d may or may not work; if not, you can probably get away with rm -R /opt/zimbra/backup/sessions/* . But don't hold me to that.)
You can rsync your backups to another location. That should fill the bill.
Another possibility would be a network backup solution. We use Retrospect because we already owned it and it is hard-link-aware, which is useful when you do backups using --noZip. See also Ajcody-Backup-Restore-Issues - Zimbra :: Wiki
Basically you would still do your backup to the local drive, but you could set your deletion horizon to a shorter period--as short as one day if you don't care about hardlinking across full backups using --noZip. If you do this, though, you want to make damn sure that your rsync (or whatever) is copying each backup before it gets deleted. Probably the way to do this would be to take the backup deletion out of the zimbra crontab and instead call zmbackup -del as part of clean-up after shipping the backups to the remote storage.
If you want to absolutely minimize the local space used by backups over any time period, then you'll need a script that only calls zmbackup when the remote storage is available. Then, if you want, you could backup directly to the remote storage. Or you could create the backup locally and then immediately rsync (etc.) it, then delete it. (zmbackup -del 0d may or may not work; if not, you can probably get away with rm -R /opt/zimbra/backup/sessions/* . But don't hold me to that.)