First of all, thank you for the thank yous, messages like that encourage me to go on.
I've been mildly surprised that no-one has asked why I don't use the built-in configuration-restoration instead of a script to restore the modules. My original goal was to use the restore-process not only to restore a complete server, but for "splitting" a server as well, ie. restore only specific functions. (If you run into performance issues on a server for example, you could split the functions it performs between different servers using only the backup.) Part of that plan was to be able to do that live, without downtime and without unplugging any cables. To do that we'd have to be able to restore to a server with a different IP. If I'd used the built-in restoration-process, it would also restore the network-module, and hence, if static ips were configured, we'd get an ip-conflict. I was hoping that Zentyal, upon restoring certain module-settings, would automatically adjust IP/interface-dependent modules like firewall, DNS, DHCP etc. This is not the case. At this time it seems unavoidable to, at one point or another, set the restored server to the original ip-adress (eventually to change it to something else again, which Zentyal will happily do.) Therefore there's no longer any point in not using the built-in, complete restoration.
(A second goal was to make pretty much anyone able to follow the how-to, by generally being very specific about what to do, not how it works, and trying to avoid technical terms. I think most non-geeks will feel much safer using the webconfig instead of the shell where possible.)
So, this is just a heads-up that there will be some changes to the HOW-TO very soon, I need to run a battery of tests first. Good news is that you won't have to change anything if you've already implemented it, the only thing that will change is the text and the last part of the restore-procedure.
::Trym