Virtualmin Backup and restaure (28/07/2020)


I am working on a dedicated server (Intel Xeon E5-1630v3
4c / 8t 3,7GHz 64GB DDR4 ECC 2133 MHz SoftRaid 4x2TB SATA), Centos7, Webmin (1.953) / Virtualmin (6.10). I host 25 virtual servers (25 domains). I have a domain that is taking up a lot of disk space. Every day I perform an automated backup of all my servers through the Virtualmin backup option which is sent by Ssh to another server. The backup file for my “big” domain is 280GB.

On 07/25/2020, the backup is made. The server does not work any more => change of several disks, inability to restore the Raid => complete reinstallation.

This morning, I transfer the backup file from the backup server to the new server by Ssh (scp) in order to avoid connection and bandwidth problems. I start, then, the restoration by the intermediary of the option of restoration of Virtualmin. I start the process at 1:00 p.m. and at 10:00 p.m. tonight the process stops. I restart the process and I continue my wait.

Can you tell me how long do you think the restoration will take?

If the restoration does not work, do you have a solution to recover my data in order to reassemble the site?

please thank you

good night


What RAID level?

Also, is it possible the RAID controller was the culprit? Literally every time I’ve ever had to suffer through an unplanned, complete reinstall / restore on a production server, the reason was a flaky RAID controller. When they go, they can take down the entire array with gusto.

As for recovery, depending on how the drives were handled after the failure and whether a bad controller hosed the whole array, the chances are very good a recovery lab can recover from RAID 6 or RAID 10. With RAID 0, practically no chance whatsoever. With RAID 1 or 5, maybe.

Personally, I’d replace the controller before trying again, unless it’s integrated on the mobo or (gasp) software RAID.



Thank you for that answer. My problem is not the recovery of files from the old hard drives (I was in RAID 5 but the old drives are unrecoverable) but the restore on Virtualmin.

But my problem is the following:
On my new system (whose description is at the beginning of my first post) I transferred the backup file from one of my servers which was running on my old virtualmin on the new system, therefore on the new virtualmin. This file is 280GB and is of the type

Virtualmin does not seem to be able to restore it with its automatic function.

I am looking for advice on restoration (by virtualmin) or a solution to “recover” the files contained in the archive in order to manually rebuild the server and in fact the site (site which worked under drupal).

Can you help me ?

please thank you



Ah, okay. So this is a new machine and all you want to do is get the data from the backup file.

Let me download one of my backups file and try to manually extract it. It sounds like that’s what you’re trying to do.


Downloading the archive onto my Windows machine did allow me to extract the files using 7-Zip, but did not reassemble the file structure, probably because of filesystem differences. The files were scattered throughout a whole bunch of numbered directories. But they appeared to all be there.

I was able to successfully extract the backup onto the CentOS machine, however, with all the files and file structure intact. I simply cp’d the archive into a temporary directory I created in /home/[user] as root, chown’ed it to the user, logged back in as the user, and gunzipped / untarred it. Everything was there and in the right place.

Have you tried doing that?

My backup file for the site was only 117MB; so it took about a second, maybe less, to extract. Yours obviously would take much longer.

If you’re not adept in the terminal, by the way, all of this can be done with WinSCP.


Just to clarify, I created a temporary directory in /home/[user] because this was just a test. If I were actually restoring, I would have:

  1. As root, created the user (that is, create the Virtual Server).
  2. As the user, created a temporary directory outside /public/html (or create it as root and chown it to the user).
  3. As root, cp the backup archive into that directory and chown it to the user.
  4. As the user, extract the archive into the temporary directory.
  5. Decide which files I wanted to move into /public_html/ and move them there, as well as any other files I wanted to try to restore.

I’d keep them to the bare minimum to avoid conflicts. If all I really needed were the Web files, then that’s all I would move.

I suppose there are ways to manually restore mail, stats, and the like; but unless I really needed to recover those things, I wouldn’t bother. I could run into the same problem that prevented Virtualmin from restoring them. So unless I really needed them, I would sacrifice them and start them anew.


Thank you for these responses.
I am trying this procedure and I will keep you posted as soon as possible (but indeed it may be long because the restore file is 280GB …)

Thanks again for this help.

If you have other avenues of research, comments or advice on this problem, I am still interested, please thank you



I just learn as I go, Raphael. I’ve only been using Virtualmin for a little over a year and haven’t had enough problems with it to become any sort of expert. That’s actually a good problem to have, when you think about it.

I’m actually an aircraft mechanic and avionics technician by training. I received my first FCC radiotelephone license in 1976, and my FAA aircraft mechanic license in 1980.

Aviation having its ups and downs (see what I did there?), I wandered into hardware computer repairs when that was a hot market. Then I decided to learn Web design when I got tired of driving all over five counties to make a living.

In short, I’m no sort of Virtualmin expert. We have them here, but I’m not one of them. I’m just a fast learner.


Raphael, the documentation for migration is here:

I’m not sure if you are restoring through the browser interface, but it may be timing out. Command line instructions are in the above link. Let us know how you get on.