I-MSCP disaster recovery plan

  • Well, I did, but for these two plugin did not work.

    Because the dependencies for these plugins were not installed on new server (SpamAssassin, OpenDKIM)... as clearly stated in the errors you did received.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • Yes. This is why I have said that better to install the plugin via IMSCP first, which will also install all required dependencies, and then restore the backup.


    I think it is much easier that way.


    One thing is still strange.


    Files under /var/www/virtual/domain/htdocs/ are not matching user and group


    As an example I see that everything in /var/www/virtual/domain/ is for vu2005:vu2005 but the files inside htdocs are for vu2008:vu2008 (which is the old user from backed up system)


    I can change that for sure, but should the re-config process take care of that?


    My backup was created with TAR and option -p to keep the permissions. So I see the permissions was kept, but new setup did not changed it.


    Or should I create the backup without keeping the permissions?

  • Files under /var/www/virtual/domain/htdocs/ are not matching user and group


    As an example I see that everything in /var/www/virtual/domain/ is for vu2005:vu2005 but the files inside htdocs are for vu2008:vu2008 (which is the old user from backed up system)

    Because you miss two things:


    When restoring, and just before running the installer, you need run the following SQL query:

    SQL
    1. UPDATE admin SET admin_sys_name = null, admin_sys_uid = 0, admin_sys_gname = null, admin_sys_gid = 0, admin_status = 'ok';

    and regarding the installer, you need to run it with the --fix-permissions option to fix the permissions recursively:

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • Hello Laurent,


    Thank you. I did run the SQL query, but as per your suggestion, --fix-permissions did fix owner/permission issue under htdocs.


    Now I have a quite nice process to restore the server, and I only encounter one issue:


    My real server have its network card interface named as 'ens3' however my testing server having this network interface called 'ens33'


    So when I import the database dump, it surely add an entry into server_ips table with the IP and Network Interface name of the real server.


    The fact that IP is different, not a big deal, since we can reconfigure it. However, during the last step when we run the setup again, the network interface causing an error, because as per my observation, setup script create a new entry in that table with correct IP and Network Interface, however it still want to process the first one too. And since ens3 interface not exist, setup exist with an error.


    To fix it, I re-imported the database, and before running the setup, I have updated the entry in server_ips table by renaming ens3 to ens33. I did not changed IP manually.


    I run the setup again, and all went fine this time.


    Thank you for the help on this topic. I tested all and my restored test server is working fine.

  • To fix it, I re-imported the database, and before running the setup, I have updated the entry in server_ips table by renaming ens3 to ens33. I did not changed IP manually.

    That is exactly how it should be done. We could make the installer a bit more smart at this regard. A ticket for enhancement is welcome.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206