Além de usar o mysqldump, eu tenho feito backup do meu servidor mysql com o tar / up / lib / mysql para redundância e conveniência. Esse diretório inclui ibdata, ib_logfile0 e ib_logfile1, bem como alguns outros arquivos e um subdiretório para cada um dos meus bancos de dados. (Eu também faço backup do my.cnf.) Agora preciso segmentar o backup em duas partes: (1) o banco de dados "h" contendo apenas tabelas myisam compacted (readonly) e (2) todos os outros bancos de dados no servidor mysql.
Assumindo que eu não estou mudando as versões do servidor, é seguro e confiável usar tar / var / lib / mysql / he separar separadamente todo o resto no diretório / var / lib / mysql? Se "todo o resto" continuar a mudar, posso ainda restaurar a base de dados "h" do seu arquivo TAR mais antigo? Se eu restaurar todo o resto, exceto o subdiretório "h", os outros bancos de dados ainda serão utilizáveis e o único efeito será que o banco de dados "h" estará faltando?
A razão pela qual eu quero fazer isso é que o banco de dados "h" é muito grande e só muda uma vez por ano. Todo o resto é comparativamente pequeno e muda o tempo todo. Se essa abordagem funcionar, eu poderia fazer arquivos anuais do banco de dados "h" e arquivos semanais de todo o resto.
Estou usando o MySQL Server 5.5.31 em execução no Debian 7 (Wheezy).
Sim, em teoria, a maneira como você planeja seus backups deve funcionar.
Mas se os dados valem alguma coisa, você deve ter outro servidor - ou sua estação de trabalho, qualquer coisa - onde você tenta realmente restaurar seus dados e ver o que acontece, e fazer isso regularmente. Dessa forma, você pode ter certeza de que pode restaurar seus backups quando necessário.
Supondo que você parou de escrever / alterar os arquivos no diretório DB, uma idéia seria fazer o backup do sistema db (mysql) duas vezes. Uma vez no backup H e uma vez no backup de todo o resto. Dessa forma, o banco de dados H pode ser restaurado da mesma forma quando foi feito o backup.
Costumávamos criar nosso MySQL offline, parar o banco de dados, mover os arquivos para o servidor de produção e, em seguida, iniciar o banco de dados de produção. Isso nos permitiu atualizar uma tabela multi-GB sem as horas que o MySQL levaria para carregar os dados usando SQL.