Virtualmin Pro backup/restore issues.

Hey guys.

I got a new server up and cruising. Was able to do a custom build on Gentoo (When will there be better gentoo support? :wink: ).

Now I wanted to do a transfer of all the virtual-servers and settings. First, I shutdown postfix so that mail would start to queue up on my secondary mail relay. Then ran a full backup to S3. After that finally finished, I then attempted a restore from S3. The restore would spin for a VERY LONG TIME. Eventually one of the perl processes would start eating up tons of memory, until it easts all the swap space and then eventually dies. The restore page on Virtualmin just spins. I tried it even on small sites, thinking that it might be an issue with the vs size, and the same thing happens.

With that a big failure and leaving the virtual servers down for many hours and keeping me very very tired, I had to abort and get the original server back up. The flood of email that came in killed the server with an onslaught of spamassassin and clamscan processes. The utilization got up to 93 before I eventually lost connectivity. Disabling the spam and antivirus services has causes the overrun of processes to come down to a calm 0.34 utilization.

That overload from mail processing is the exact reason I need to move this stuff to the new server.

So today I’d figure I’d just que up some backups to use SSH to the new server. Now I discovered a new bug. If you try to run a backup via SSH, and your account happens to have an @ sign in it, it will fail.

for example, lets say the root account’s password is p@ssword.
it would put this up on the virtualmin page:

[code:1]Starting backup of 25 domains to virtualmin-transfer on SSH server

Failed to connect to SSH server : scp failed :

Permission denied (publickey,keyboard-interactive).

lost connection

Backup failed! See the progress output above for the reason why.

Along with that, If I do make a bunch of backups and transfer them via SSH, is there a way to do a differential backup later containing all the mail and such that occurred after backup?

Well, I guess I can get it going by changing the password, but I thought I’d just give you a holler.<br><br>Post edited by: SeanWolfe, at: 2007/10/15 12:16

Hi Sean,

Looks like there are a few separate issues here :

  1. S3 backups take a long time - this is mostly out of my control unfortunately :frowning: For a machine to machine transfer, I’d recommend using SSH or FTP to transfer the backup files, as it will be faster (no need for a round-trip to Seattle), and more reliable.

  2. Email load when re-activating. I’ve seen this too, and it happens when you have virus scanning enabled but are not using clamd. Virtualmin will then use the ‘clamscan’ program for virus scanning, which takes up a lot of CPU time.
    The fix is to enable clamd on your system, and then configure Virtualmin to use the ‘clamdscan’ scanner which talks to clamd, and uses much less CPU. This can be done (in Virtualmin 3.47) by opening the Email Messages category on the left menu and clicking on Spam and Virus Scanning.

  3. Passwords with an @ in them don’t work, as the backup URL becomes something like :
    which cannot be parsed properly. I will add a warning about this to the next Virtualmin release, but the recommended solution is to change your password :slight_smile:

  1. I figured so much, but I’m not certain why it would cause the perl script to eat all available memory. Also it fails even on a small site of about 2mb. But all of these reasons are really why I’m moving off of S3. Too costly for performance half of what they advertise.

  2. On the Clamd, i tried to activate it. When I first saw the load, I switched spamassassin to spamd. That worked but seemed to cause a lot more clamscan processes to launch. I tried to start clamd but it wouldn’t start due to old version of clamd. Tried to update from yum, but aparently Fedora 4 hasn’t updated its repositories in awhile. I tired to use an RPM that was recommended from the wiki, but that just seemed to make clamav not work at all. Best solution, disable spam services altogether until the move is finished.

  3. One quick rebuttal on this one, it would be easy for you to just urlescape to the password before putting it into the url. It does work. But regardless, my password is now different.

  4. This kinda got buried in here. Is there possibly a way to do a differential backup (take less time than a full) after a full backup has been restored on a new server? Or should I use something else like rsync? Virtualmin cluster copy?

Thanks for your input.

  1. Excessive memory use could be a Virtualmin bug… so did this happen during the restore? And if so, how large was the backup being restored?

  2. Yeah, turning off spam is also an option :slight_smile:

  3. I looked at my code some more, and refined the regexp for parsing backup URLs so that an @ can be used in the password … I’ll include this fix in the next Virtualmin release.

  4. One way to do differential backups is :

  • Backup everything and restore on the target, one time
  • For all subsequent backups, include all features except the home directory, and restore that on the target.
  • Use rsync to copy across home directories.
  1. The first memory leak happened on restore from S3 on a virtual server that was 1.2GB. I did also try with one that was around 100MB and 10MB, same results.

  2. looking forward to the next rev.

  3. Thanks on the differential tip.