Mensagens Recentes

Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina.

Com DD é possível extrair o conteúdo de um disco todo, ou de
toda uma partição, ou de parte de uma partição, ou disco. É possível fazer a cópia da tabela de particionamento, fazer cópia da MBR, entre outras coisas.

DD nao reconhe sistemas de arquivos, tampouco reconhece
arquivos. A cópia é feita Bit por Bit. É lenta, porém extremamente confiável. Através de um sistema
operacional com DD, é possível criar uma imagem, ou clonar discos, fazer backups de qualquer outro
sistema operacional, independente de seu sistema de arquivos, o que o torna uma ferramenta
excepcional, e praticamente indispensável para quem visa segurança de seus dados.

Como DD faz uma cópia bit a bit dos dados, nem os clusters em branco do disco são perdoados. Logo, se você tem uma partição com 20Gb, e deseja fazer um backup dela, se prepare para gastar 20Gb de outro disco.

 
Veremos agora, a sintaxe do DD para uma cópia entre discos.
Suponhamos que a origem, seja o hda, e o destino, o hdb
dd if=/dev/hda of=/dev/hdb
Este comando, realiza a cópia de todo conteúdo do disco hda para o hdb. O disco de destino, precisa
ser igual, ou maior que o de origem, obviamente.

É possível copiar partições de um disco para outro também
dd if=/dev/hda1 of=/dev/hdb1 (ou hdb2, ou qualquer particão de destino já presente no disco. )

Podemos também extrair para um arquivo, e criar uma imagem do disco.
dd if=/dev/hda of=/backups/backup_17­04­2006.img
É este o caso, onde é interessante comprimirmos a imagem

Caso não seja passado nenhum parâmetro de entrada ou de saída dos dados para o DD, ele assume
stdin e stdout respectivamente. ( Entrada e saída padrão ). Neste caso, podemos manipular para onde
serão destinados os dados
Podemos assim, criar facilmente uma imagem compactada no tempo de sua criação.
dd if=/dev/hda | gzip > /backups/backup_17­04­2006.img.gz
dd if=/dev/hda ­ origem dos dados
| ­ Desviando a saída diretamente para uma aplicação no caso o gzip, que compactará os dados
> ­ Desviando a saída do Gzip para um arquivo local, que será a imagem compactada.

Para restaurar a imagem faremos o processo inverso.
gzip ­dc /backups/backup_17­04­2006.img.gz | dd of=/dev/hda
gzip ­dc ­ descompacta a imagem e joga a saída em stdout
| direciona a saída para o DD
dd of=/dev/hda ­ A saída dos dados, sera o disco hda.

Utilizando dos pipes, abrimos varias outras possibilidades. Poderemos até dividir as imagens, em
arquivos de tamanho de nossa escolha, evitando assim, problemas com o sistema de arquivos onde
serão armazenados. Para isso utilizamos o aplicativo Split.
dd if=/dev/hda | gzip ­c | split ­b 2000m ­ /backup/backup_17­04­2006.part.
gzip -c  para ir compactando e jogando a saída na stdout. Com pipe, redirecionaamos para o split, que fará arquivos de 2000Mbytes. O sinal de ” ­ ” antes do arquivo de

destino, serve para que o split colha os dados da stdin, se não, tentaria obtê­los do

arquivo de destino ( que nem existiria ainda ).

Para extrair a imagem, basta o invertermos o processo, porém, vamos usar o cat para ler os arquivos e
direcionarmos a saída para o gzip descompactar, e enviar ao DD, que restaurará no disco.
cat /backup/backup_17­04­2006.part.* | gzip ­dc | dd of=/dev/hda
Os arquivos serão abertos em sequência, enviados ao gzip que enviará ao DD, e assim, será restaurada
a imagem.
Assim teremos mais maleabilidade no trabalho com ima gens no DD. Um sistema excelente,
combinado com outras ferramentas, para ficar ainda melhor.

Para fazer uma imagem da MBR do sistema com DD:
dd if=/dev/hda of=/backups/hda.boot.mbr bs=512 count=1
para restaurar
dd if=/backups/hda.boot.mbr of=/dev/hda bs=512 count=1


fonte: You are not allowed to view links. Register or Login

Hoje vou ensinar como facilitar um pouco um tipo específico de restauração: a de bancos de dados. Infelizmente é comum empresas e clientes precisarem restaurar apenas um banco de dados e o administrador restaurar toda a conta por que não tem conhecimento de fazer uma restauração específica.

Vamos lá! Primeiro passo é identificar onde seus backups são gravados no servidor, geralmente isso é feito em /backups, então agora devemos definir se vamos restaurar o backup diário (daily), semanal (weekly) ou mensal (monthly), mas note que os backups só estarão disponíveis se você tiver configurado para que eles sejam gerados em seu WHM root.

Em nosso exemplo iremos presumir que temos o backup diário e o cliente deseja a restauração justamente do backup mais recente, neste caso nós devemos restaurar o banco de dados com o seguinte comando:


mysql usuario-cpanel_banco-de-dados < /backup/cpbackup/<strong>daily</strong>/usuario-cpanel/mysql/usuario-cpanel_banco-de-dados.sql
Se o arquivo de backup existir a restauração será realizada com sucesso. Caso deseje consultar os backups disponíveis basta listar o diretório:

ls -al /backup/cpbackup/<strong>daily</strong>/usuario-cpanel/mysql/
E agora vamos ver como também é simples gerar um backup em .sql de um banco de dados, basta usar o comando abaixo dentro da pasta onde deseja salvar o backup:

mysqldump usuario-cpanel_banco-de-dados > backup-usuario-cpanel_banco-de-dados.sql
São procedimentos relativamente simples que podem salvar o seu relacionamento com cliente ou horas de trabalho

This warning should be disregarded. It is due to how Munin versus MySQL handle tablespace for InnoDB. By default, Munin throws a warning at 2GB free tablespace and critical alert at 1GB free tablespace. However, MySQL defaults to creating a 10MB autoexpanding tablespace. The tablespace can be verified with:


mysql -e "SHOW VARIABLES LIKE 'innodb_data_file_path'"
This means InnoDB will perpetually show <10MB of space (resulting in a permanent Munin warning) yet will always seamlessly autoextend as needed. The only "limit" in such a configuration is the partition that /var/lib/mysql is stored on. This render's the InnoDB free tablespace useless in an "autoextend" configuration.

The way to resolve is simply to disable the alerts. Create this file:


vi /etc/munin/plugin-conf.d/mysql_innodbPlace the following inside the file:

Code:
[mysql_innodb]
env.warning 0
env.critical 0
At that point, run the following commands:

Code:
/etc/init.d/munin-node restartsu munin -c /usr/bin/munin-cron
Also, if you use innodb_file_per_table, there is no point even running this plugin. It is safe to:

Code:
# mv /etc/munin/plugins/mysql_innodb  /rootThis doesn't delete the actual plugin, only the symlink to the plugin. The actual plugin resides at:

/usr/share/munin/plugins/mysql_innodb.

Do not delete that one.

EDIT: after you've deleted the plugin, make sure you # service munin-node restart

Bem vindo cara,  bom saber que as coisas estão caminhando por ae...

Abraco

Fala Alexandre,

Bacana te ver aqui,  estamos no inicio, mas acredito que logo vai ter bastante material..

Seja Bem vindo..

Abraço!