Como as tabelas do MySQL são armazenadas como arquivos, é mais
        fácil realizar um backup. Para obter um backup consistente,
        faça um LOCK TABLES nas tabelas relevantes
        seguido por FLUSH TABLES para as tabelas. See
        Secção 6.7.5, “Sintaxe LOCK TABLES e UNLOCK
        TABLES”. See Secção 4.6.4, “Sintaxe de FLUSH”.
        Você só precisa de um bloqueio de leitura; isto possibilita
        outras threads a continuarem a pesquisar nas tabelas enquanto
        você copia os arquivos no diretório do banco de dados. O
        FLUSH TABLE é necessário para garantir que
        todas as páginas ativas de índices serão escritas em disco
        antes de iniciar o backup.
      
        A partir das versões 3.23.56 e 4.0.12 BACKUP
        TABLE não permitirá que você sobrescreva arquivos
        exixtentes já que isso colocaria em risco a segurança.
      
        Se você desejar realizar um backup ao nível da linguagem SQL
        de um tabela, você pode utilizar SELECT INTO
        OUTFILE ou BACKUP TABLE. See
        Secção 6.4.1, “Sintaxe SELECT”.See Secção 4.5.2, “Sintaxe de BACKUP TABLE”.
      
        Outra maneira de efetuar um backup de um banco de dados é
        utilizar o programa mysqldump ou o
        script mysqlhotcopy. See
        Secção 4.9.7, “mysqldump, Descarregando a Estrutura de Tabelas e
        Dados”. See Secção 4.9.8, “mysqlhotcopy, Copiando Bancos de Dados e Tabelas do
        MySQL”.
      
Fazer um backup completo do seu banco de dados:
shell>mysqldump --tab=/path/to/some/dir --opt db_nameou shell>mysqlhotcopy db_name /path/to/some/dir
            Você também pode simplesmente copiar os arquivos das
            tabelas (*.frm,
            *.MYD) e os arquivos
            *.MYI) quando o servidor não estiver
            atualizando nada. O script mysqlhotcopy
            utiliza este método. (Mas nopte que estes métodos não
            funcionarão se seu banco de dados contém tabelas
            InnoDB. InnoDB não
            armazena o conteúdo das tabelas em diretórios de banco de
            dados, e o mysqlhotcopy funciona apenas
            para tabelas MyISAM e
            ISAM.)
          
            
            Interrompa o mysqld caso ele esteja em
            execução, depois inicie-o com a opção
            --log-bin[=nome_arquivo]. See
            Secção 4.10.4, “O Log Binário”. Os arquivos de log binário
            fornecem a informação necessária para replicar
            alterações ao banco de dados que forem feitas depois do
            ponto em que você executou mysqldump.
          
        Se o seu servidor MySQL é um slave, seja qual for o método de
        backup que você escolha, quando você faz backup dos dados do
        slave, você deve também fazer backup dos arquivos
        master.info e
        relay-log.info que são necessários para
        continuar a replicação depois que você restaurar os dados do
        slave. Se seu slave está sujeito a replicação de comandos
        LOAD DATA INFILE, você também deve fazer
        backup dos arquivos SQL_LOAD-* que podem
        existir no diretório especificado pela opção
        slave-load-tmpdir. (A localização padrão
        desta opção é o valor da variável
        tmpdirse não especificado.) O slave
        precisará destes arquivos para continuar a replicação de
        qualquer LOAD DATA INFILE interrompido.
      
        Se você necessita restaurar alguma coisa, tente primeiro
        recuperar suas tabelas utilizando REPAIR
        TABLE ou myisamchk -r. Isto deve
        funcionar em 99.9% de todos os caso, Se o
        myisamchk falhar, tente o seguinte
        procedimento: (Isto só irá funcionar se você iniciou o MySQL
        com --log-update, veja
        Secção 4.10.4, “O Log Binário”,):
      
            Restaure o backup original feito com o
            mysqldump ou backup binário.
          
Execute o seguinte comando para re-executar as atualizações armazenadas no log binário:
shell> mysqlbinlog hostname-bin.[0-9]* | mysql
            Em seu caso você pode querer re-executar apenas alguns log
            binários, a partir de certas posiçõs (normalmente você
            quer re-executar todos os log binários a partir da data de
            restauração do backup, co exceção de algumas consultas
            erradas). Veja Secção 4.9.5, “mysqlbinlog, Executando as Consultas a Partir de um
        Log Binário” fpara mais
            informações sobre o utilitário
            mysqlbinlog e como usá-lo.
          
Se você estiver utilizando o log atualizado, você pode executar o conteúdo do log de atualização desta forma:
shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql
        O comando ls é usado para obter todos os
        arquivos de log na ordem correta.
      
        Você pode também fazer backups seletivos com SELECT *
        INTO OUTFILE 'nome_arquivo' FROM nome_tabela e
        restaurar com LOAD DATA INFILE 'nome_arquivo'
        REPLACE.... Para evitar registros duplicados, você
        precisará de um chave PRIMARY KEY ou uma
        UNIQUE na tabela. A palavra chave
        REPLACE substitui os antigos registros com os
        novos quando um novo registro duplica um antigo registro em uma
        chave de valores únicos.
      
Se você tiver problemas de performance realizando backups no seu sistema, você pode resolver isto configurando uma replicação e fazendo os backups na máquina slave no lugar da master. See Secção 4.11.1, “Introdução”.
Se você estiver utilizando um sistema de arquivos Veritas, você pode fazer:
            Executar em um cliente (perl ?) FLUSH TABLES WITH
            READ LOCK
          
            Bifurcar uma shell ou executar em outro cliente
            mount vfxs snapshot.
          
            Executar no primeiro cliente UNLOCK
            TABLES
          
Copiar arquivos do snapshot
Desmontar snapshot
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

