Default Bug? in how Ispconfig 3 does upgrade installs. Not going to go hunting the bug tracker, at least right now. Still trying to rebuild information from backups and accessory files. When Ispconfig does an upgrade, it apparently performs an SQL dump, then wipes the database, and restores the dump. However, there is _no_ error checking during the dump process. IF an error occurs, such as a 'crashed table' (which wasn't a crashed table. Repair tools found nothing wrong, but the system kept reporting it anyway), then the tables below that don't get backed up (in this case, the sys_user, web_database, web_domain, and web_traffic tables - VERY IMPORTANT ONES) get wiped clean during the reload. The upgrade process SHOULD error out and _stop_ if the database backup fails for any reason. It should never decide that bad data is adequate data. ---- End result? A number of web sites that are functioning, with working ftp users and databases, but that don't actually exist in ispconfig. (neither sites, nor databases). So, I get to recreate them in the correct order on another machine, export the tables, then import them back in, and hope that everything goes back to normal. (it's too bad you can't tell ispconfig to work backwards from the actual files on the server to rebuild what should be in the database) Thanks Reply With Quote Multi-Quote This Message Quick reply to this message
1) ISPConfig checks for errors in the dump process. If your table was crashed and even mysql reported is as not broken, how shall ispconfig know that it is broken. 2) The whole topic applies only to versions < ispconfig 3.0.3 as ispconfig 3.0.3 and 3.0.3.1 do incremental database updates and not dumps anymore.
