Running an Apache/PHP/MySQL server

Discussions related to using VirtualBox on Linux hosts.
Post Reply
Stellar7
Posts: 10
Joined: 2. Mar 2020, 00:06

Running an Apache/PHP/MySQL server

Post by Stellar7 »

I have a computer with 16GB of RAM running Linux Mint 19.1.

I wanted to run another Linux VM on the host using VirtualBox. The VM will be used to run Apache/PHP/MySQL. The intent is that by running it in a VM, there can be more resiliency in the event of a host hardware failure. Also it will allow me to create backups.

Questions:
1) Can VirtualBox run for months and months reliably or are there bugs or known issues that prevent this? The reason I ask is because I've had freezes/crashes with VB in the past doing something similar but I could not specifically determine it was a problem with VB. Perhaps others have had success running for extended periods without issues?

2) Is there a way to shutdown the VM from a commandline, run a backup of the VM to another location on the network, then restart the VM?

3) Is it a trivial affair to run the VM on a second computer if the first host computer fails? e.g. I can pick up from the VM backup.

Thank you
scottgus1
Site Moderator
Posts: 20965
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: Running an Apache/PHP/MySQL server

Post by scottgus1 »

Stellar7 wrote:Can VirtualBox run for months and months reliably
My best experience was the office server-class host running Windows 7 and Virtualbox 4.y.x & 5.y.x for several years, hosting 5 VMs including the office domain controller & file/print server, email server, anti-spam filter, office app servers and 2 backup work environments if a workstation went down. It had a weekly reboot and automated backup routine. Was plenty stable.

I would go with earlier versions that were stable. FWIW 6.0.14 did not have a lot of forum posts about it as I have seen.

My ideas are: Run something older, don't upgrade unnecessarily, do a test on a different host before upgrading the production host, etc. Don't be an early adopter with the production host, watch the forum to see how things are going. If it ain't broke don't fix it.
Stellar7 wrote:Is there a way to shutdown the VM from a commandline, run a backup of the VM to another location on the network, then restart the VM?
Yes. Become familiar with "vboxmanage" in the manual, section 8. Everything the main Virtualbox window can do, and quite a bit more, can be done with vboxmanage commands.

My backup routine mentioned above would shut down the VMs, monitor for the rare shutdown hang, back up the VMs' files, FC-file-compare the backups to confirm integrity, SHA256-hash the originals, then restart the VMs. The backup script then copied the first backup to two other hosts that could stand in if the main host died, two other USB drives in the server room, and rsynced to my boss's and my houses, for offsite backups. Onsite backups in the other hosts and USB drives were FC'd against the primary backup, and offsite backups were hashed to compare with the originals' hashes. Each offsite backup was automatically copied to second media at each site, with an FC after the first offsite copy had passed hash check. 9 automated copies of a complete backup weekly. Also, in-the-VMs backups run nightly and half-hourly, stored on the alternate hosts and offsite, with FC and hash confirmation. Total destruction of the building would leave us with only a half-hour's data loss max.
Stellar7 wrote:Is it a trivial affair to run the VM on a second computer if the first host computer fails?
Very trivial, as long as the new PC is not bleeding-edge, such that the Virtualbox developers might have a rare glitch or two to find. A couple years' old hardware should be perfect.

The best backup of a Virtualbox guest is a full file & folder copy of a completely shut-down (not save-stated) VM folder, containing all the files therein, as well as any disk files that may reside outside the folder. The backup can be FC file-compared, or hashes can be taken and compared for off-site backup where FC would not be practical. If the disk file(s) are inside the folder right next to the guest's .vbox file, then that backup can be restored with the main Virtualbox window's Machine menu Add command to any capable Virtualbox host running any supported host OS. (If a disk file is outside the guest folder, then the .vbox file contains an absolute path to the disk file, and that path must be re-created on the new host, or the .vbox file needs to be manually edited).

Snapshots and clones are not backups, and export/import is for transferring the VM to another hypervisor, like VMware or Hyper-V.

Virtualbox does not have a built-in method for backing up a live VM. Some folks have developed a method of snapshotting a live VM, copying the disk files, then deleting the snapshot on the fly. This method leaves the VM backup in the same state as if the power plug was pulled, with dirty databases and scrambled writes. For live backups, run inside-the-VM 3rd-party backup software compatible with the programs the VM will be running. A backup of just the disk file is not a full backup of the VM: the whole folder must be backed up.

It would probably be a good idea to keep the same CPU manufacturer for the new computer if possible. If your host now is an Intel, get an Intel for the replacement host, etc. Switching CPU manufacturer won't be hindered by Virtualbox, but the VM's OS may complain.
Stellar7
Posts: 10
Joined: 2. Mar 2020, 00:06

Re: Running an Apache/PHP/MySQL server

Post by Stellar7 »

Thank you for the detailed writeup. That helps tremendously.

Why are you restarting the VMs weekly? Do you find the need to do that from instability or are you shutting it down for backups?
scottgus1
Site Moderator
Posts: 20965
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: Running an Apache/PHP/MySQL server

Post by scottgus1 »

The shutdown was only for full backups. I never tried a 'how-long-will-it-run' test, it was my boss's data. :shock:

BTW I turned off auto-update on the host OS so unexpected reboots wouldn't kill the VMs. I ran updates some weeks after they came out, since the host OS wasn't running any web-connected services, so I could check if Microsoft's Patch Tuesday held unexpected surprises. Update running was handled during the weekend backup script, so all I had to do was set a flag and it would update during the host reboot.
Post Reply