Hi. When thinking about restoring ISPConfig on a new server, the general course of action would be (as far as I got it) - installing exactly the same version of ISPConfig - restoring the full MySQL dump - restoring the /etc dir - [...] (steps like restoring the dirs with actual data, like, website / Maildir dirs) The trouble is, restoring /etc dir may break things. Consider doing it on system with different disk - RAID - mountpoint configuration? Who knows what else may go wrong... So, I was thinking, instead of restoring the /etc dir, may it be possible that we compile an exhaustive list of the relevant /etc items? If this is anywhere near to be possible, maybe you can help me with this list: /etc/shadow /etc/passwd /etc/group /etc/postfix,dovecot,apache2,mysql,fail2ban,default(?),php*,named,amavis, [...]? Please let me know if this is doomed from the start.
Use the ISPConfig migration tool to migrate all necessary configs and user data: https://www.ispconfig.org/add-ons/ispconfig-migration-tool/
Thanks for answer. But, correct me if I'm wrong, ISPConfig Migration Tool may only used on live instances? It cannot do job when, for example, the server is dead and you do have backup of /etc, mysqldump + files?
Yes, this is true. If the system is dead, set up a new system and do the necessary modifications. When restoring a raw backup, it can cause more issues in the short and long run.
Other than the official, there are unofficial backup restore scripts which should cover what to backup and what to restore. The key is you need to have full knowledge and understanding on how to perform the same.
Most certainly I don't have full knowledge but also it's very likely that I do know the fundamentals: ISPConfig consists of 1. configured services (/etc), 2. mysql database, and 3. the files [sites - maildirs, ...]. (Failed ISPConfig upgrade is resolved by restoring /etc/ dir and mysqldump.) I'd rather avoid unofficial backup-restore tolls, unless you were referring to ./remoting_client, what I could develop myself for my specific needs?
Understandable, though there is no official tool to restore. The installer backs up /etc/, /usr/local/ispconfig/ and dumps the ispconfig database, which can be used to recover the master ispconfig node - note that it does not back up any user data. If you want to work on testing and documenting the recovery process, that could be quite useful, though as mentioned you need to understand how a system works, recovering a working system from backup isn't something a novice user can likely do armed with only a howto article, as systems vary, things change over time, etc. You should not blindly copy the old /etc/ files over your new ones, but only select things as you mentioned in your initial post. You will need to manually merge your old passwd/shadow/group files with your new system, as it's almost guaranteed that system accounts created by installing software will have some different id's on your new system, so you don't want to change those to what the old system was using; you will need to copy the info from the web# accounts and client# groups, any shell users (including the sshusers group), and in a system I just checked I see ispapps, ispconfig and ispconfigend users which should be copied. Most services (postfix, apache, etc.) can be configured by re-running the installer and reconfiguring services after /usr/local/ispconfig/ is restored. You'll have to restore your dbispconfig database manually, and I don't know if you need to recreate the mysql users and grant access to that db manually, or if the installer will do that (provided your mysql root password matches /usr/local/ispconfig/server/lib/mysql_clientdb.conf). On multi-server installs, you will definitely need to add root mysql.user entries for your slave nodes to access the master db. One other note is ensure you have the same software installed on the new system as on the original; in particular right now you should know what letsencrypt client the original had, as you will have issues restoring certificates from a certbot system into one running acme.sh. You will need to restore /etc/letsencrypt/ from the /etc backup if using certbot. If using acme.sh, probably /root/.acme.sh/ is where your config and certificates live, so restore that from backup (note I believe that is currently not backed up by the installer). By the time you get all this worked out and documented, you may even find yourself writing or adding to one of the third-party backup/restore scripts, so that this process is reproducable and efficient (you'll likely be doing it several times to test that your instructions are correct).
Luckily I'm far from a "novice user armed with only a howto article" . This is important point: "You will need to manually merge your old passwd/shadow/group files with your new system, as it's almost guaranteed that system accounts created by installing software will have some different id's on your new system, so you don't want to change those to what the old system was using" I wasn't even considering the UIDs and GIDs created during installation to be (possibly) arbitrary values; most setups I've seen, for example, creates vmail:vmail (5000:5000) for email systems, so does ISPConfig. I get your point: all this is rather better-to-avoid, monumental task, with difficult to control outcomes. So, in order to be able to restore server via Migration Toolkit (the official way to do it), one has to ensure restoring entire currently working server at least to the point when it may act as live & running backup source. That's too bad, IMHO. And a great to consider feature in the future. One good example is Virtualmin's out-of-the-box tool to backup and restore plain everything you have done under the panel.
well, assuming you already have backups in place for websites, databases, emails. and the only major concern is the system drive. one option, probably not ideal due to time/disk requirements etc. is to image the system drive using dd. maybe install s3cmd or awscli and image the system drive directly to an s3 bucket? might take a lot longer to create each system backup in the first place, but at least you'll know on restoration that every uid,gid and installed package versions etc are exactly what they were before.
