Solução de Backup Mysql

1

Eu gostaria de fazer backup do meu servidor mysql remotamente. Eu tenho três problemas e um requisito.

  1. Eu não tenho espaço suficiente no meu servidor. Eu só posso manter uma cópia de backup no servidor local
  2. Eu não tenho boa conexão. Eu só posso fazer upload de 1 MB por segundo.
  3. O tamanho do meu banco de dados é de 9 GB.
  4. Se meu servidor remoto for invadido, ele não poderá prejudicar o servidor principal.

Eu tentei usar o script automysqlbackup, mas ele está bloqueando tabelas e, como a conexão é lenta, ela está demorando e o site cai.

Eu não quero usar a replicação, meu segundo servidor também tem seu próprio aplicativo e há muitas gravações no outro servidor. Eu não tenho recursos suficientes.

Eu não quero usar xtrabackup (não é resolver o problema principal além do problema de travamento de qualquer maneira) Eu tive uma experiência ruim.

O backup deve ser armazenado localmente primeiro, depois GZIPed e depois transferido.

O servidor principal deve manter apenas uma cópia (ou, preferencialmente, o limite de tamanho do arquivo; portanto, se algum dos backups falhar, ele ainda manterá o antigo) O script Automysqlbackup não tem limitação que eu possa definir. (Então, eu poderia usar o automysqlbackup para backup local e limitar o espaço total em disco alocado)

Eu posso usar SFTP e chroot o usuário e recuperar o backup.

O servidor de backup deve manter um número ilimitado (ou 100) de arquivos. Não deve apagar os arquivos como o servidor principal.

Eu tenho que escrever um roteiro? Ou existe alguma solução pré-fabricada? (e possivelmente com mais recursos)

    
por myton 06.08.2011 / 20:37

4 respostas

4

Parece que seus requisitos são suficientemente personalizados para que você precise escrever seu próprio script. Algumas notas sobre esse assunto:

  • Você não precisa descarregar tudo no disco e então compactá-lo. Use um dump / gzip pipe e ele salvará uma pilha de espaço em disco:

    mysqldump ... | gzip -c >/var/backups/mysqldump-$(date +%Y-%m%-d).sql.gz
    
  • Você pode fazer com que a maioria dos seus problemas de bloqueio desapareça se você usar todas as tabelas InnoDB e despejar em uma transação, com a opção --single-transaction para mysqldump .

Todo o script de despejo / envio deve ter cerca de cinco linhas. É bem trivial.

    
por 07.08.2011 / 01:06
1

Você terá que escrever seu próprio roteiro.

Considerando que você não deseja o bloqueio estendido e parece que há espaço no servidor principal, recomendo que você inicie uma segunda instância do mysql para replicação no servidor principal e faça o backup do escravo de replicação.

Não é recomendado usar apenas uma única cópia. Há muitos serviços que permitem um espaço de backup por um custo muito baixo. Por exemplo, você pode usar o Amazon AWS para backup ou encontrar outro provedor de espaço. Ele custará menos de US $ 10 / mês, mas permitirá vários backups (uma semana ou mais) e, como resultado, você não terá nenhum dos problemas que você tem agora.

Outras variantes: obtenha hetzner.de ou outro VPS de baixo custo e replicação de configuração + backup.

    
por 06.08.2011 / 23:47
0

Se a maioria de seus dados estiver em innodb, então, procure em Xtrabackup

O benefício de usá-lo se você tiver um banco de dados innodb é que ele não bloqueará as tabelas enquanto você estiver fazendo um backup.

    
por 07.08.2011 / 02:44
0

Mares.

Eu faço meus mysql-backups com

  • xtrabackup
  • rdiff-backup

Se você realmente não gosta de xtrabackup , use mysqldump (talvez mk-parallel-dump da suíte maatkit) ou o que for. Depois disso, você poderia lançar seus backups através do rdiff-backup, que deveria apenas copiar as partes alteradas dos arquivos - também, ele pode ser usado na rede.

Então, na máquina 'pequena', você pode manter seus despejos noturnos e, na máquina remota 'grande', você pode manter todos os backups do rdiff, atualizados todas as noites depois que seus mysql-dumps estiverem sendo usados.

Seria fácil criar scripts (= = escrever seu comando de despejo e a chamada rdiff-backup no seu crontab) isto ...

Ciao

    
por 08.08.2011 / 14:14