Restore confusion on migration, 3.65gpl

The is some wrong logic in Restore Virtual Server regarding Inbox mail files if they are not in the default /home/<virtservadmin>/homes/ directory.

Mine are in /var/spool/mail/.

The Restore Virtual Server handles such case.

But here is the problem:

If I backup a virtual server with explicitly checking the option to backup mail files too, the backup file correctly contains both Sent mail (/home/<virtservadmin>/homes/<virtservuser>/mail/ for all virtservusers ) and Received mail (Inbox) ( /var/spool/mail/<virtservuser> ).

Now when I use Restore Virtual Server to migrate/move a virtual server to a pristine new physcial/vps server and I restore with the default restore settings, I get the Sent mail restored, but not the Inboxes.

I played a bit to get to the root of the problem and found the following:

By default, Restore Virtual Server has its Features and settings section not expanded.
When expanded, it shows that by default radio-button Restore all features is chosen.

Next to it sits its alternative radio-button - Only those selected below.

Underneath them is a list of checkboxes - per feature, none checked by default.

When I see that and restore, I logically expect everything from the backup file to be restored since Restore all features is chosen.

But as I pointed above, in this process Sent mail files get restored, but Inbox mail files not in "home" dir, do not get restored.

I found that get the Inbox restored to, I need to check the designated checkbox Restore mail files.

But that goes contrary to the logic that Restore all features is chosen: why after that I need to check a specific checkbox underneath it?

I would highly recommend improving VM code as follows:

  1. In case of restoring on the same server (not my case of migrating/moving), obviously there are legitimate reasons to prevent mail files restore. The logic is that the existing mail files might contain newer mail, arrived between the backup and restore times.
    We might be restoring because we screw up something else (not mail).
    But in that case, the logic for both Sent and Inbox should be the same: I either want to restore both, or not restore neither one.

  2. Based on #1, the Restore mail files should not be underneath the alternative options to restore all or only chosen features.
    It should be placed separate, e.g. before the alternative for choosing scope of restored features.
    And by default, it might be good to be not checked.
    Thus there won’t be confusion if they get restored for neither operation - restore to an existing virt.server, or to a pristine new one.

  3. Another logic to handle this might be on checking the presense of the mail files: if not present, restore them anyway. Means they either got deleted or this is a move/migration to another physical server.

If the behavior still exists in 3.66, file a bug.

Sounds like a clear case of incorrect behavior…so, no need for discussion in the forums, just file a bug and it’ll get fixed.

I just verified that this bug still exists in version 3.66, did anyone file it as a bug yet? I haven’t filed Virtualmin bugs before, so I don’t know how the bug system works here.

By the way for anyone else who found this thread on Google as I did, here’s a quick synopsis of what you need to do to avoid this bug:

- When backing up a server you must expand “Features and settings” and click “Include mail files” or else the user’s inbox won’t be copied even when “Backup all features” is selected.

But that’s not all, also…

  • And then when restoring it you must again expand "Features and settings" and click "Restore mail files".

This is a major bug that will cause data loss to people counting on their Virtualmin backups, and it will cause confusion and frustration for people using it to move websites to a new server. Hopefully it will be fixed quickly.

Since you saw it in 3.66, go ahead and file a bug report regarding it.

It doesn’t have to be anything fancy, just click the Bugs and Issues link below, and mention what you’re seeing, and the fact that you’re seeing it in version 3.66.


Ok, I added this bug report: