It’s the third part of saving the zimbra email system from collapse because of insufficient space as explained at the first part. On the second part, I try to explained how to reserved some free space on emergency situation so we got some time/space privilege to carefully find solutions with minimum risk and minimum downtime.
After do some googling, I finally decide to add new hardisk on the server and move ‘zimbra greediest space part’ to the new hardisk.
The ‘greediest space’ part of zimbra is on /opt/zimbra/store which store the blob email message. So we will move the /opt/zimbra/store to the new hardisk. To minimize down time, we will use rsync to move the data.
Let’s dig deeper how I add the hardisk to the server and how to make it work seamlessly with current system.
- Assume we already put hardisk that already ext4 formatted and located in /dev/mapper/VolGroup-lv_data, we will mount it into temporary place let say /data
– Prepare directory for the new partition% mkdir /data
– Change ownership of the directory to zimbra# chown zimbra:zimbra – Change permission of the directory to 755# chmod 755 /data– Check read/write/delete on the new directory for user zimbra
% su - zimbra $ cd /data $ touch testfile $ rm testfile $ exit- Mount the partition to the /data % mount -t ext4 /dev/mapper/VolGroup-lv_data /data
- Ensure that your drive is already mounted in /data
% df -h
- Now we copy the /opt/zimbra/store to /data, as stated before, we will use rsync to minimize problem and downtime.
% rsync -avzHS /opt/zimbra/store/ /data
This action will take time depending on how big is your data. After the sync finished, we will execute the last part, change the /opt/zimbra/store with the /data, this should be done carefully yet quickly.
- Stop zimbra service
% su - zimbra $ zmcontrol stop
- Rsync /opt/zimbra/store to /data, why we have to do another rsync? Because after we did the first sync, there is a big possibility some email in/out from/to the zimbra, and we have to ensure that those data will also moved. We do the second rsync AFTER we stop the zimbra service so the data on /opt/zimbra/store is final.
% rsync -avzHS /opt/zimbra/store/ /data &
- Move the current /opt/zimbra/store to another folder and create new /opt/zimbra/store as container to the new partition
% mv /opt/zimbra/store /opt/zimbra/store_bak % mkdir /opt/zimbra/store % chown zimbra:zimbra /opt/zimbra/store % chown 755 /opt/zimbra/store % sudo - zimbra $ touch /opt/zimbra/store/testfile $ rm /opt/zimbra/store/testfile $ exit
- Unmount /data than mount it to /opt/zimbra/store
% umount /data % mount -t ext4 /dev/mapper/VolGroup-lv_data /opt/zimbra/store
- Check that the mounting process is done
% df -h
- Start the zimbra service
% su - zimbra $ zmcontrol start
That all step we need to move the /opt/zimbra/store, after some time, and you already ensure that the system is stable, you may delete /opt/zimbra/store_bak to reserve another ‘huge’ free space.. DONE
[…] Move the data to the new drive with minimize downtime.(third part) […]
Pingback by Zimbra store drive is full?? -First- | simplify this complex world — December 14, 2015 @ 4:39 am |
[…] Huff.. finally I got 2G freespace to keep the engine running. We now have privilege to find the real solution like I posted on the third part. […]
Pingback by Zimbra store drive is full?? -Second- | simplify this complex world — December 14, 2015 @ 4:43 am |
Hi, thanks for this!, used it to migrate my store to a new bigger drive. There’s an error in point 6, chown instead of chmod. Also, might want to add an /etc/fstab to mount the now store on boot.
Comment by Richard Bertouche — February 3, 2016 @ 7:50 am |