Como você costuma fazer backup de seu banco de dados?


8

Eu estou usando mysql

Com que frequência você faz backup do seu banco de dados?

Como você normalmente faz backup do seu banco de dados?

Exportar todos os dados para o formato sql ou cvs e mantê-los em uma pasta?

Respostas:


11

Se você deseja fazer backups do MySQL corretamente, sem tempo de inatividade, você deve replicar o banco de dados em um servidor sobressalente. Ele não precisa ser extremamente poderoso, só precisa lidar com a carga de gravação do seu banco de dados mestre. Você não deve usar este servidor na produção. Se a replicação nunca continuar, você precisará de um servidor mais poderoso. Você pode verificar comparando o arquivo de log e a posição da saída de

 > SHOW MASTER STATUS\G

no mestre e

 > SHOW SLAVE STATUS\G

no escravo. Eu acho que o MySQL5 mostrará o atraso de SHOW SLAVE STATUS.

Quando você está feliz que seu escravo está acompanhando, você pode fazer backups fazendo

  1. Pare a replicação com SLAVE STOP;no escravo
  2. Faça um mysqldump --optno servidor escravo.
  3. Inicie a replicação novamente com SLAVE START;no escravo

Se você fizer isso, terá um backup consistente de seus bancos de dados. Esse método evita que bancos de dados diferentes ou, pior ainda, tabelas diferentes no mesmo banco de dados estejam fora de sincronia e evita o tempo de inatividade bloqueando tabelas para gravações enquanto você faz o backup.

Um bom benefício dessa configuração é que você tem uma cópia do seu banco de dados que pode ser usada para executar consultas longas e caras que não afetarão seu serviço ativo.

Algumas dicas aleatórias:

  • Não fique tentado a fazer um backup baseado em arquivo dos arquivos de dados mysql. É mais complicado do que vale e os dumps do MySQL são mais flexíveis.
  • Cuidado com as tabelas de bloqueio do mysqldump durante o dumping.
  • Cuidado com inconsistências nos lixões, a menos que você bloqueie todas as tabelas durante o lixão
  • Use mysqldump --opt, pois geralmente é a maneira mais rápida de importar o SQL resultante
  • Despejar o mais rápido possível. Despejamos diariamente porque temos mais de 40 GB de dados.
  • Teste seus dumps em um servidor sobressalente ocasionalmente para garantir que eles funcionem.

2
Seconds_Behind_Master de SHOW SLAVE STATUS está disponível no 4.1.9 e posterior.
22811 Dan Carley

+1 em replicação e despejos regulares. Achei relativamente indolor começar a trabalhar pela primeira vez (sem muita experiência mysql anterior). Não concordo totalmente com os backups de arquivos. Se você tiver espaço para fazer as duas coisas, será mais fácil reconstruir um novo servidor com base em arquivos, se o servidor do banco de dados se esgotar, os despejos sql individuais para cada banco de dados serão mais útil se você precisar restaurar dados perdidos por alguém.
theotherreceive

3

Eu uso um script que usa mysqldumppara extrair os dados / esquema para um arquivo para cada banco de dados. Os dados são armazenados em backup pelo backup de netbackup normal em fita. Obviamente, você pode adicionar mais sinos e assobios, mas isso faz um despejo básico do simpe.

#!/bin/sh
# Find out what databases are in mysql and back them up
# Delete old backups


STARTTIME=` date +%Y%m%d-%H%M `

#BACKUP_DIR="/usr/local/db_backups"
BACKUP_DIR="/var/local/db_backups"
LOGFILE="/var/log/db_backups.log"
USER="root"
PASSWD="<password>"
KEEP="7"

(
echo
echo " ---MySQL backups start ${STARTTIME} ---"
#delete any backup written more than ${KEEP} days ago
echo "Removing files over ${KEEP} days old from ${BACKUP_DIR}:"
/usr/bin/find  ${BACKUP_DIR} -mindepth 1 -mtime +${KEEP} -print -delete



echo
echo "Performing today's dumps"
#find each database running in this instance of mysl
for DB in ` echo "show databases;"|mysql -u${USER} -p${PASSWD} mysql |awk " NR>1 {print $1} " `
do
        #generate a backup file name based on the data base name
        BACKUP_FILE="${BACKUP_DIR}/${DB}-${STARTTIME}.sql"
        echo "Processing database ${DB} into file ${BACKUP_FILE}"
        # dump the database data/schema into the backup file
        mysqldump -u${USER} -p${PASSWD} --add-drop-table ${DB} > ${BACKUP_FILE}
        gzip ${BACKUP_FILE}
done

ENDTIME=` date +%Y%m%d-%H%M `
echo
echo " ---MySQL backups complete ${ENDTIME} ---"
echo
) >>  ${LOGFILE} 2>&1

1

Geralmente, os backups dos bancos de dados são feitos uma vez por dia, se eles tiverem que ser interrompidos, e os backups são transferidos para uma área de armazenamento para consolidação, e então eles são gravados.

Os backups de banco de dados são feitos com as ferramentas nativas fornecidas com o mecanismo de banco de dados na maioria das vezes.

Os backups não devem ser mantidos nos servidores com os dados em caso de falha de hardware.

É bastante recomendável ter réplicas atualizadas dos servidores de banco de dados, quando possível, melhor ter um macanismo de failover para bancos de dados de produção.

Para o software, você pode, por exemplo, dar uma olhada em bacula ou zmanda


1

Nossa configuração padrão é um cluster de alta disponibilidade com dois bancos de dados, um replicando no outro, que é somente leitura.

Fazemos um backup completo uma vez por dia e, em seguida, temos uma política por cliente de eliminar backups antigos; geralmente mantemos 4 últimos backups diários (para sobreviver ao fim de semana;), 4 últimos domingos e 4 últimos primeiros domingos em um mês. Depois disso, um ou dois depósitos de lixo por ano vão para o arquivo para serem mantidos para sempre.

Também mantemos os logs de replicação por quanto tempo pudermos poupar o espaço em disco. Eles também são bastante úteis como ferramenta de depuração, pois registram exatamente quem mudou o que e quando.

Teoricamente, tudo o que você precisa é de um backup completo e de todos os logs de replicação para poder fazer uma restauração pontual, mas os backups completos mais frequentes irão acelerar a restauração.

Um truque interessante com o backup é usar tabelas innodb e - única transação paramater para despejo mysql, para que o backup não bloqueie o banco de dados enquanto ele é executado.



1

Todo o objetivo do backup é poder restaurar.

Eu não defenderia um despejo de CSV como uma solução de backup; tudo o que você fornecerá são os dados brutos. Há muito mais além disso, principalmente com um banco de dados. Descrições de tabelas, visualizações, procs armazenados, o nome dele. Se você também não os tiver, não poderá recuperá-lo com sucesso. Há também o aplicativo e a configuração do RDBMS a serem considerados. Você pode ter um grande número de correções, que também serão necessárias no ambiente de recuperação para obter o mesmo nível. Você pode estar executando uma configuração especial ditada pelos requisitos de seus aplicativos. Você pode até ter um conjunto específico de configurações do sistema operacional necessárias para que o banco de dados seja executado da melhor maneira possível. Tudo isso também precisará ser recuperado e, a menos que você tenha uma solução de backup capaz de executá-los, haverá mais atrasos no tempo de recuperação,

Para backups de banco de dados (e backups em geral), eu sempre preferiria usar um software de backup "real" que possa lidar com tudo isso.


0

Mais recentemente, eu gerenciei servidores MySQL no EC2. Configuramos os snapshots do EBS em uma tarefa cron de 15 minutos, e foram mantidos 3-5 snapshots.

Quando criamos servidores MySQL 'tradicionais', fazemos backup diariamente via MySQl-ZRM. Os backups são essencialmente mysqldumps, que são enviados para fita, SAN, etc, dependendo das necessidades do cliente.

Ambos os métodos podem ser feitos sem parar o banco de dados.



0

Fazemos backups duas vezes ao dia e também executamos backups de log a cada 10 a 15 minutos.

A vantagem desse método é que você pode restaurar a partir de um dos backups duas vezes por dia e aplicar os arquivos de log até os últimos 15 minutos, o mais tardar. Dessa forma, você está minimizando a quantidade de dados que pode perder.

A frequência com que você faz backup de seus dados depende de você. Quantos dados você se sente confortável em perder? Se você pode perder dados em um dia, faça backup uma vez por dia. Os dados nunca mudam? Então você só precisa de uma cópia!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.