В дополнение к использованию mysqldump, я делал резервную копию своего сервера mysql, сохраняя архив / var / lib / mysql для избыточности и удобства. Этот каталог включает в себя ibdata, ib_logfile0 и ib_logfile1, а также некоторые другие файлы и подкаталог для каждой из моих баз данных. (Я также создаю резервную копию my.cnf.) Теперь мне нужно сегментировать резервную копию на две части: (1) база данных «h», содержащая только сжатые myisam (только для чтения) таблицы и (2) все другие базы данных на сервере mysql.
Предполагая, что я не меняю версии сервера, безопасно и надежно ли tar up / var / lib / mysql / h и отдельно затирать все остальное в каталоге / var / lib / mysql? Если "все остальное" продолжает меняться, могу ли я восстановить базу данных "h" из ее старого tar-архива? Если я восстановлю все остальное, кроме подкаталога «h», будут ли по-прежнему использоваться другие базы данных, и единственный эффект будет заключаться в том, что база данных «h» будет отсутствовать?
Причина, по которой я хочу это сделать, заключается в том, что база данных "h" очень большая и изменяется только раз в год. Все остальное сравнительно мало и все время меняется. Если этот подход сработает, я мог бы делать годовые архивы базы данных "h" и еженедельные архивы всего остального.
Я использую MySQL Server 5.5.31 под управлением Debian 7 (Wheezy).
Да, теоретически то, как вы планируете резервное копирование, должно работать.
Но если данные чего-то стоят, у вас должен быть другой сервер - или ваша рабочая станция, что угодно, - где вы пытаетесь восстановить данные и посмотреть, что происходит, и делать это регулярно. Таким образом, вы можете быть уверены, что действительно сможете восстановить свои резервные копии, когда это необходимо.
Предполагая, что вы прекратили запись / изменение файлов в каталоге БД, одна из идей - сделать резервную копию системной БД (mysql) дважды. Один раз в резервной копии H и один раз в резервной копии всего остального. Таким образом, можно восстановить базу данных H в том виде, в котором она была при резервном копировании.
Раньше мы создавали MySQL в автономном режиме, останавливали БД, перемещали файлы на рабочий сервер, а затем запускали производственную БД. Это позволило нам обновить таблицу размером в несколько ГБ, не тратя времени на загрузку данных MySQL с помощью SQL.