I have no experience with mail servers, but am soon to be indoctrinated.

I am interested in hearing from mail server admins about the pros and cons of virtualizing a mail server. Enterprise perspective only please.

At the small company where I work we are looking at virtualizing the mail server. We are using postfix/dovecot/maildir on CentOS 6. We are in the process of testing the system on CentOS 7. We use rack servers for virtualization hosts.

We have about 800 accounts and about 100GB of mail files at any one time. Some customers use mail clients, others use web mail. The latter customers are the ones with most of the mail data on the server. We expect those numbers to increase at a gradual rate.

Second, what is common practice for backing up mail servers? I am more interested in disaster recovery than restoring a single mail. To be able to restore bare metal with minimal customer complaints. Currently the owner is using a tar backup script, which takes hours. I have had good success with rsync/rsnapshot, but perhaps there are more optimal backup approaches for mail servers. We are not interested in cloud services. We have our own infrastructure and plenty of space for backups.

Thanks much.

Your question isn't really about mail but it is about using VM's. If one has access to multiple modern servers and they wanted to use the advanced features that vm's are getting great at then yes, you could use them successfully. Plenty of sales pitches and good web articles on the value in server farms when using vm's. There still are a number of advantages when using a single server.

Many vm choices and each one has different features and ways to use them. The most advanced can replicate on the fly, move to different hardware on the fly, maintain real time backup and more. Some vm's are made to be baremetal but that isn't exactly what you have on a client of a host.

Every day new hardware and software features go into vm technology.

http://searchdatabackup.techtarget.c...best-practices

http://www.tecmint.com/linux-system-backup-tools/

http://techgenix.com/pros-cons-server-virtualization/

Mail > Zimbra > AWS. done.

You virtual mail server will run just like it's bare-metal counterpart, though perhaps a bit slower. Jefro points above are an excellent place to start.

The second question is complicated by the definition you're using for "disaster recovery".

Do you want a live mirror that comes on-line with a DNS redirect ( Automated Disaster Recovery) ?
Do want to be able to install a copy of the mail-servers virtual image in another data-center within a reasonable period of time ( Survivors Disaster Recovery ) ?
A note:
Both those questions lead you to "storage" i.e. where is it? Are you replicating it to another location? Regardless of what you do with rolling the mail-server itself, you'll still need its original storage in order to preserve business continuity.

Thanks for the replies.

We currently have about 20 virtual systems running on rack server hardware. My original post was about virtualizing the mail server only. I was hoping for shared experiences with moving a mail server to virtual.

We started testing Friday. The biggest challenges thus far are pruning old mails and copying gobs of GBs of data to the new location, which simply takes a very long time.

Benefits of virtualization:
- very easy recovery if you have backups
- easy management of virtual machines, you can duplicate machines on the fly, move them to another virtualised node, create/delete easily without the need of being in the datacenter and fiddling with the console.
- possibility of using shared storage on virtualization nodes (but make sure you have redundancy here too!)

What you need to check when moving to virtualized solution:
- to allocate sufficient resources to your VM
- use the best I/O drivers available - in case of KVM based solution use VIRTIO devices for networking and storage (built in the Linux kernels). This is very importand especially if you use servers that need frequent reads/writes.

Transferring from a hardware machine to a virtual one can be done in multiple ways:
- slower path is to create a new virtual machine and copy files/settings to it over the network
- faster (but needs downtime) is to create a block image from your HDD for example DD and use this image either dirrectly to boot from or transform this image in another format such as qcow fot KVM that permits easy snapshotting.
A variation of this is to
- create a virtual machine, create a sufficiently large virtual HDD for it, set up networking
- boot both the hardware machine and the virtual machine with a live linux image
- transfer the hardware machine's HDD via network using basic netcat or dd or whatever (netcat usually works well since it uses TCP, just make sure the network has no problems). Here you can do copy by partition if you are concerned that the disk metadata may pose issues (i personally never had issues even when i used this method on hardware machines on both end).
- boot the VM using the virtual drive that has the hardware machine's HDD image on it.

Now for best "experience" you could use a virtualization solution that has specialized interface, i would say a web interface is the nicest and easiest to use (it's a cross platform frontend also).

What i write below not to be taken as a commercial for a certain virtualized solution, everything i write there is based on my experience. You can use any solution you want, most solutions (both free and commercial) are mature and they do work in basically the same way functionality-wise (some are more efficient than others in certain areas).

We for example use Proxmox internally for various purposes (servers for our developers, infrastructure servers etc). I have to say that i "stumbled on it" accidentally when i was given the task of researching another virtualization solution like OpenStack or CloudStack instead of our existing XCP infrastructure that was using a dedicated management solution on Windows that was giving us headaches (inconsistent functioning, very frequent errors etc).
Our requirements were the possibility of consistent and reliable automated backups, clustered setup and basically a free solution since we did not have a dedicated budget for this. Proxmox filled these and did much more by providing a very easy management of the VMs via an intuitive web interface.
Now Proxmox as any virtualization solution has it's quirks (mainly the quorum system may be annoying if you have few nodes in a cluster and sometimes some errors can only be solved by rebooting a node) and some functions are implemented only in CLI (but the CLI management tends to be very simple). But for us it is working very well and it is stable even if we currently use basically consumer hardware (Dell Optiplex workstations).

Proxmox is a free distribution that is based on Debian but has specific components specifically for virtualization (uses kvm as virtualization backend). It has
- a very, very good web management interface with most options available through it
- very good virtual machine backup/restore system (backups can be scheduled to take place automatically, can specify the number of backups retained, automatically delete older backups etc). Restore from backup is a 2 click affair. Backups use block copy of the virtual drive not file system based copy which is a world of difference if you have many small files (note that this is true in pretty much all virtualized solutions that implement backups). Also the backup process is done runtime without the need of stopping the machines (it does slow down if I/O operations are in progress but it produces valid backups).
Note that Proxmox backups are a gzipped image of a current full disk image and some metadata files and can be recovered over the existing machine overwriting its contents or you can even create a new virtual machine from a backup (in this case the MAC address and certain UIDS will be changed to avoid conflict with the existing machines).
- very easily set up cluster solution (you add a new machine by running 2 CLI commands)
- HA - if one node fails, VMs can migrate automatically to another node - this needs shared storage. Also note that Proxmox' implementation is not a "hot standby" one - it takes a minute or so to start the machine on another node - this is to make sure that indeed the previous node+instance is really dead and prevent "split brain" scenarios - the node that failed connection to the cluster will be rebooted in this time by it's watchdog to bring it back into a consistent state - that is if the outage was caused by something else than hardware failure.
- live migration (needs shared storage)
- built in firewalling
- CLI with simple commands - note that pretty much everything done in the web interface minus the graphical console view can be set up via CLI too. Some functions can be done via CLI only but most are integrated into the web interface.
etc etc

I think that if you want to clone or copy or move or replicate the current mail VM then you need to tell us what VM tech you are using. It may also be tied to the hardware a bit.

If you have a physical machine then you either need to use a live migration P2V app or clone it live or drop it and move it.

My bad for not mentioning we are using Proxmox.

Current hardware mail server is dovecot/postfix on CentOS 6. We are migrating systems to CentOS 7.

We have adequate experience with Proxmox and existing virtual systems. I was asking only about pros/cons of moving a mail server to virtual. Thus far we have been focusing on pruning old mail and stale accounts to reduce the overhead of copying the data files to the virtual container. Once we get the initial data files copied we'll just use rsync to keep things current on the test container until ready to go live. When ready to go live we will inform customers of a planned mail server outage, probably sometime around O'Dark Thirty. At that time we'll do a last sync of the data and go live.

At least that is the plan. There are always unforeseen glitches and issues that arise with any migration or update.

Be advised:
There are, in many jurisdictions, legal constraints regarding the retention of corporate email. Additionally, if you find yourself in court, telling a judge "we know what the email said but we can't produce it because we deleted it" that will be roughly akin to saying " I am a lying idiot".
Storage is cheap and litigation is not.
That said, please disregard this post if you have fully considered this aspect your mail migration

Another post similar to the above -- beware those users "filing" email in the "deleted items". I was on the perifary of a team doing mailbox migrations and there were a small but significant number of call from users who wanted their "deleted items" back.

Kind of a lot changed between 6 and 7 so that may be the bigger issue than the VM part I'd think.

If you have modern hardware with enough resources and better still a few servers, I don't seen any downside to running a VM. Proxmox is free and offers some great features. Might be worth it to start looking at VMware stuff too.

Guess looking at containers too would be of help.

There are so many features to OS's and VM's now it is almost too much information to select. Jails and such and the list goes on.

We are aware of the restraints. Thankfully, the requirements do not apply in this case.

Fascinating filing system!