Posts by flames

what is the exact error message when mysql doesnt start? post log

edit: since you are getting the problem after copying ibdata1 file (innodb namespace) this might be helpful http://egil.biz/how-to-recover-mysql-data-from-innodb/

then reinstall mysql-server cleanly, uninstall with purge, and remove /var/lib/mysql then install it again and install imscp
create every customer database manually with exact names like they were before
now stop mysql and copy only the /var/lib/mysql/databasename-folders but not /var/lib/mysql/mysql and the files in /var/lib/mysql/ from backup
start mysql again and you have all your databases with old data
now you can restore database user bindings, also manually

and think about a better backup strategy

hello, really, this is not related to imscp, you probably need to update joomla, here is their site http://www.joomla.org/ for more info.

since this is not critical, just switch php error reporting to error_reporting = E_ALL & ~E_STRICT or disable it. login as customer, go to domain, php settings... this feature need to be enabled by reseller/admin

you also need the old /etc/mysql/debian.cnf file

after reinstalling your server, you also installed same version of mysql-server as on the old os?

try to run mysqld with following command: mysqld_safe --skip-grant-tables &

if that works, you can create a dump of your databases, and reinstall newer mysql version of mysql-server and restore from dump.

1. this is not a contribution nor a howto, so i moved this topic to support / migration. next time think.

2. i bet you copied the folder without preserving atributes. so fix permissions on /var/lib/mysql (chown + chmod) then restart mysqld.

because i moved it here

how you feel this topic could belong into security advisories category? moved

und rdiff-backup könnte interessant sein, es nutzt rsync, erstellt allerdings zusätzlich diffs, so dass man nicht nur inkrementell sichert, sondern man kann zu jedem zeitpunkt zurück gehen. ähnlich wie shadow copy und mac time machine. der overhead gegenüber reinem rsync backup ist relativ gering.

bei sowas würde ich eher empfehlen das eingebaute backup zu deaktivieren und eine eigene, auf die situation angepasste strategie zu überlegen.