maio 242019
 

PRELIMINARES

 

Um pouco da história sobre este estudo.

Resolvi criar este artigo devido à dificuldade em encontrar material de apoio sobre como utilizar o script “ghettoVCB.sh” para efetuar snapshots de máquinas virtuais de servidores ESXi 5.0, de forma automatizada.

O script ghettoVCB é simples, prático e fácil de configurar na sua forma básica (caminho_destino + número_cópias), que é o que, na prática, todo administrador precisa (efetuar snapshot das máquinas virtuais quentes salvando no destino desejado).

E é com este intuito que escrevi este tutorial. O meu objetivo era montar uma solução *FREE* automatizada para snapshot das VMs, utilizando recursos simples e básicos.

Para isso, utilizei também um servidor (em VM) Ubuntu Server 11.04 64 bits. Neste material, cito a possibilidade de backup através de um servidor NFS na rede, mostrando de forma simples e objetiva, como instalar e configurar este recurso.

Resumindo, este artigo trata da minha experiência na configuração do script, efetuando snapshot das VMs quentes, com agendamento programado em um servidor GNU/Linux com Ubuntu Server 11.04, salvando as snapshots em um case de HD conectado à porta USB da máquina física ESXi e também em um storage com FreeNAS instalado em máquina física através de NFS e iSCSI.

Como abordo de forma simples o script ghettoVCB, sugiro visitar a comunidade VMware para informações específicas sobre o funcionamento da ferramenta:

fev 012017
 

Recentemente precisei criar um script de backup com algumas exigências… não entrarei muito em detalhes sobre os recursos utilizados, a ideia é compartilhar e passar um overview do que faz o script.

As exigências:

  1. Realizar backup logo após que a mídia externa for conectada (HDD externo)
  2. Deletar dados no diretório de backup com 15 dias ou mais
  3. Realizar backup para diretório em servidor remoto
  4. Enviar mensagem de e-mail notificando o administrador dos servidores

As soluções:

1. Existem algumas maneiras de obter informações de um device via Udev … no meu caso utilizei o seguinte:

# udevadm info –query=all –name=/dev/sdc

Obs.: as linhas iniciadas com “P” (PATH) mostram o caminho absoluto do device, “S” (SYMLINK) links simbólicos para o device e “E” (ENVIRONMENT) variáveis de ambiente que podemos usar nas regras do Udev.

/etc/udev/rules.d/90-CustomUdev.rules
ACTION==”add”, SUBSYSTEM==”block”, ENV{ID_SERIAL_SHORT}==”5758323145393436444B4134″, SYMLINK+=”BackupUSB”
ACTION==”add”, SUBSYSTEM==”block”, ENV{ID_SERIAL_SHORT}==”5758323145393436444B4134″, RUN+=”SEU SCRIPT”

Quando plugado o HDD (ACTION==”add”) com número serial (ENV{ID_SERIAL_SHORT}==”5758323145393436444B4134″) e seja um block device (SUBSYSTEM==”block”), crie um link simbólico em /dev com nome BackupUSB (SYMLINK+=”BackupUSB) e execute o script RUN+=”SEU SCRIPT”.

2. Tal comando encontra-se em função dentro do script, mas seguindo a ordem das exigências … o comando é:
Continue reading »

dez 092015
 

CONFIGURANDO O AMBIENTE

 

É fato que devemos ter backups íntegros das nossas aplicações e servidores. Um backup confiável pode ser a diferença entre você ter que trabalhar durante algumas horas ou alguns dias ou até mesmo a diferença entre o sucesso ou a falência de uma empresa. Nada é mais frustrante, desmotivante e caro do que ter que refazer todo um sistema por uma simples falha no seu backup.

Para que o nosso script consiga usar a API, precisamos instalar o curl. O curl é uma ferramenta de linha de comando open source que transfere dados para uma URL, suportando DICT, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMTP, SMTPS, Telnet e TFTP. Suporta certificados SSL, HTTP POST, HTTP PUT, upload FTP, proxies, HTTP/2, cookies, autenticação de usuário e senha (Basic, Plain, Digest, CRAM- MD5, NTLM, Negotiate e Kerberos) , tunneling proxy e muito mais.

Para instalá-lo, basta executar o comando:

# yum install curl

Você precisará do git para efetuar o download dos scripts. Para quem não conhece, o git é um sistema de controle de versão, gratuito e open source. Para você trabalhar com o GitHub ou BitBucket, você precisa ter o git instalado em sua máquina. Então vamos instalá-lo.

# yum install git

Com o curl e git instalados, precisamos configurar o nosso usuário de MySQL que fará os dumps dos nossos bancos via mysqldump. Omysqldump é um utilitário do MySQL que executa backups lógicos, produzindo um conjunto de instruções SQL que podem ser executadas para reproduzir as definições de objeto de banco de dados originais e os dados da tabela. Ele despeja um ou mais bancos de dados MySQL para backup. O comando mysqldump também pode gerar a saída em formato CSV, ou em formato XML.

A configuração do MySQL é rápida e o usuário terá apenas permissão de leitura. Lembrando que por motivos óbvios de segurança, devemos liberar o acesso apenas para localhost ou para o IP do servidor que se conectará e fará os backups.

mysql> GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, RELOAD, SUPER, FILE ON *.* TO backup@localhost IDENTIFIED BY ‘SUASENHA’;

Com o shell e o MySQL prontos para fazer o backup, vamos ao próximo passo, que é o Dropbox!

Continue reading »

set 282015
 

Not to lose mails when main mail server is down, best solution is – mx backup server.

This is configuration to have backup mx server set up and running.

create /etc/postfix/relaydomains with contents:

then to create map for postfix – run:

Continue reading »

nov 072014
 
According to RFC2821 the lowest-numbered records are the most preferred MX for domain. So I’ve a target Postfix backup server to keep the messages in a queue waiting for the primary server to become available. This ensures that if my primary MX goes down I do not loss any emails. However, spammers are connecting to my backup MX to avoid anti spam filters that are running on the primary MX server. This also hides their real IP from my primary MX. How do I configure anti-spam for my backup RHEL / CentOS 5.3 based Postfix mx server?


This is well known issue. Make sure your backup MX runs the same config in terms of spam rejection as your primary server. Try the following to improve backup eMail server anti spam configuration.

If the backup MX acts as a store-and-forward mail server

Consider the following example:

nixcraft.com.	86400	IN	MX 	10 mx01.nixcraft.net.in.
nixcraft.com.	86400	IN 	MX 	20 mx02.nixcraft.net.in.

nixcraft.com email handled by two email servers. mx02.nixcraft.net.in is your backup server. Open main.cf and append the following restrictions on mx02.nixcraft.net.in. Continue reading »

Clonezilla – Gerando e restaurando backups completos

 Clusterweb, Linux, Redes, Segurança  Comentários desativados em Clonezilla – Gerando e restaurando backups completos
dez 222013
 
Clonezilla

Clonezilla é uma poderosa ferramenta open source que permite clonar discos e partições inteiras, assim como gerar imagens dos mesmos para posterior restauração, caso venha ocorrer algum problema com o disco ou partição clonada. O Clonezilla é um software bem flexível, apesar de alguns usuários ficarem meio assustados com a interface do mesmo.

O projeto Clonezilla tem duas soluções para geração e restauração de imagens de partições e disco inteiros, assim como clonagem:

  • Clonezilla Live → A solução Live é uma distribuição que pode ser usada em uma mídia CD/DVD ou um pendrive para inicializar e executar o Clonezilla em modo unicast. O Clonezilla Live só faz uma operação por vez, por isso ele é unicast. Mas permite clonar diretamente partições e discos sem a necessidade de salvar a imagem para poder restaurar no disco ou partição de destino.
  • Clonezilla SE → A solução Server permite gerar imagens de discos e partições inteiras em unicast, multicast e broadcast pela rede – funcionalidades poderosas, pois é possível gravar múltiplas imagens de discos e/ou partições no servidor rodando o Clonezilla Server ao mesmo tempo, assim como restaurá-las.

Nesta primeira parte do artigo, abordarei a solução Clonezilla Live, pois irei mostrar como fazer backups completos, assim como clonagens de dispositivos e como restaurá-los também pela rede local.

Principais características do Clonezilla

1. Possui licença GPL;

2. Suporta uma grande quantidade de sistemas de arquivos. Veja lista completa abaixo:

  • ext2;
  • ext3;
  • ext4;
  • ReiserFS;
  • Reiser4;
  • XFS;
  • JFS;
  • btrfs;
  • FAT2;
  • FAT16;
  • FAT32;
  • NTFS;
  • HFS;
  • UFS;
  • VMFS3 e VMFS5 do VMWare.

3. Veja que você pode clonar distribuições GNU/Linux, Windows, Mac OS X e FreeBSD, NetBSD, OpenBSD, e não importa se a arquitetura do sistema é 32-bits (x86) ou 64-bits (x86-64);

4. Apenas os blocos utilizados do dispositivo de origem são copiados e salvos, assim como restaurados;

5. Suporta LVM2 para distribuições GNU/Linux;

6. Pode restaurar uma imagem em vários dispositivos na rede local, funcionalidade suportada na versão server (Clonezilla SE);

7. Pode gerar várias imagens pela rede usando o modo multicast, para fazer clones em massa, funcionalidade suportada pela versão server (Clonezilla SE);

8. Pode restaurar múltiplas imagens usando o modo multicast pela rede, funcionalidade suportada na versão server (Clonezilla SE).

Obs.: Estas características não são uma lista completa das implementadas até o momento da construção deste artigo. Para ter uma lista completa, acesse o link:

Principais limitações do Clonezilla

1. Na operação de restauração, a partição ou disco de destino deve ter tamanho igual ou superior do que a partição ou disco de origem;

2. Backups incrementais e diferenciais ainda não são suportados;

3. A operação de clonar ou gerar a imagem dos discos/partições do dispositivo de origem só pode ser feita com o dispositivo de origem offline, ou seja, o dispositivo de origem não pode está em uso no momento da operação;

4. A operação de restauração tem que ser feita com o dispositivo de destino offline, ou seja, o dispositivo de destino não pode estar em uso;

5. O formato da imagem gerado pelo Clonezilla não permite acessar os dados contidos na imagem, ou seja, a navegação pela imagem ainda não está implementada. Isto acontece porque a imagem de backup é compactada. No entanto, o desenvolvedor do Clonezilla informa e neste link que há uma forma de fazer isso;

6. O suporte a RAID por software não está implementada até o momento;

7. O Clonezilla restaura o backup ou faz a clonagem deixando o dispositivo de destino igual ao de origem, então, em algumas situações, é necessário redimensionar o dispositivo de destino, caso o mesmo tenha uma tamanho maior que o dispositivo de origem.

Obs.: Estas limitações estão presentes até o presente momento da construção deste artigo. Para uma lista detalhada, acesse esse link:

Como o trabalho de clonagem e backup, assim como restauração, só podem ser feitos em partições e discos que não estão em uso (offline), então, no artigo farei uso de uma ferramenta muito interessante chamada deParted Magic. Trata-se de uma distribuição livre CD/Live USB usada para manutenção de sistemas que contém, entre outros softwares, o Clonezilla e GParted.

Optei pelo Parted Magic, porque, às vezes, precisamos redimensionar o espaço não alocado. Isto acontece quando vamos clonar ou restaurar uma imagem e o dispositivo de destino tem tamanho maior, seja partição ou disco e o espaço não é alocado automaticamente.

Felizmente, o Clonezilla tem a funcionalidade de redimensionar o espaço não alocado, mas em algumas situações pode ser necessário aumentar o tamanho fazendo uso do GParted.

Você pode baixar a distribuição Parted Magic neste link:

Para inicializar a distribuição pelo pendrive, use como referência o artigo do link:

Caso não queira fazer uso do Parted Magic, então baixe o Clonezilla Live do link:

E queime a imagem em uma mídia, ou use em um pendrive.

Clonagem de dispositivos  Continue reading »

GBAK – Firebird Backup and Restore

 Banco de Dados, Leitura Recomendada, Linux, Redes  Comentários desativados em GBAK – Firebird Backup and Restore
abr 292013
 

GBAK is Firebird’s command line tool for online backup and restore of a complete database.

GBAK is able to perform a backup while the database is running. There is no need to shut down the database during a GBAK backup. GBAK will create a consistent snapshot of the database at the time it starts running. You will, however, notice a perfomance degradation during the backup, so it is a good idea to backup at night. As GBAK visits all pages of the database, so it will also perform a garbage collection on the database.

General Syntax

gbak <options> -user <username> -password <password> <source> <destination>

Backup

For backups, <source> is the database you want to back up, <destination> is the file name of the backup file. The usual extension for the backup file is .fbk for Firebird and .gbk for InterBase.

Only SYSDBA or the database owner can perform a backup. For multi-file databases, specify only the name of the first file as the database name.

Restore

For restores, <source> is the backup file and <destination> is the name of the database that is to be built up from the backup file. You will have to specify the -C option for restore.

General Options

-nodbtriggers
Suppresses Database Triggers from running [Firebird 2.1]
-pas[sword] <password>
Database password
-fet[ch_password] <filename>
Instead of -password: Fetch password from the file so it is not visible in the command line. When <filename> is stdin, the user will be prompted for the password. [Firebird 2.5]
-m[etadata]
Only backs up/restores metadata (schema). No table data will be re/stored.
-role <role>
Connect as role
-se[rvice]
  <hostname>:service_mgr
Backup: Creates the backup file on the database server, using the Service Manager.
Restore: Creates the database from a backup file on the server, using the Service Manager.
All file names (backup file, log file) must be specified as viewn from the server’s perspective.
-u[ser] <username>
Database user name
-v[erbose] or
-v[erify]
Verbose output of what GBAK is doing
-y <filename>
Redirect all output messages to <filename>
The file must not exist before running GBAK!
-y suppress
Quiet mode: suppress any output
-z
Show GBAK version and server version

Backup Options

-b[ackup_database]
Back up. This switch is optional.
-co[nvert]
Converts external tables to internal tables
-e[xpand]
Creates an uncompressed backup
-fa[ctor] n
Blocking factor for tape device
-g[arbage collect]
Does not perform garbage collection during backup, so the backup will be faster. When you plan to da a Restore or Sweep anyway after the backup.
-ig[nore]
Ignores checksum errors while backing up
-l[imbo]
Ignores limbo transactions while backing up
-m[etadata]
Only backs up metadata (schema). No table data will be stored.
-nt
Non-transportable format (use only when you know you will restore on same platform and database version)
-t[ransportable]
Creates a transportable backup (transportable between platforms and server versions). This is the default.

Restore Options

-bu[ffers]
Set cache size for restored database
-c[reate_database]
Restore to a new database (the target database file MUST NOT exist)
-fix_fss_d[ata] <charset>
Repair malformed UNICODE_FSS data during Restore [Firebird 2.5]
-fix_fss_m[etadata] <charset>
Repair malformed UNICODE_FSS metadata during Restore [Firebird 2.5]
-i[nactive]
All indexes will be restored as INACTIVE
-k[ill]
Does not create shadows that are defined in the backup
-m[etadata]
Only restores metadata (schema). No table data will be restored.
-mo[de] read_write
Restores to a read/write database (This is the default)
-mo[de] read_only
Restores to a read-only database
-n[o_validity]
Does not restore validity constraints. So you can restore data that does not meet these constraints and could not be restored otherwise.
-o[ne_at_a_time]
Usually the restore takes place in one single transaction for the whole database. This switch puts a commit after each table. So you can use this to partially restore databases with corrupt table data.
-p[age_size] <size>
Sets page size of new database. <size> can be one of 1024, 2048, 4096, 8192. Default is 1024.
-r[eplace_database]
Restores over an existing database. This can only be performed by SYSDBA or the owner of the database that is overwritten. Do NOT restore over a database that is in use! [Firebird 1.0, 1.5]
-rep[lace_database]
New abbreviation for the old -replace_database [Firebird 2.0]
-r[ecreate_database] o[verwrite]
[Firebird 2.0] Restores over an existing database. This can only be performed by SYSDBA or the owner of the database that is overwritten. Do NOT restore over a database that is in use!-r is equivalent to -c. Only the “overwrite” option will restore over an existing database.
-use_[all_space]
Normally, on restore, database pages will be filled to about 80 %. With the use_all_space option, database pages will be filled to 100 %. (Useful for read-only databases which will see no more modifications.)

Examples

A regular Backup

gbak -v -t -user SYSDBA -password "masterkey" dbserver:/db/warehouse.fdb c:\backups\warehouse.fbk

Backup with output to a logfile

del c:\backups\warehouse.log
gbak -v -t -user SYSDBA -password masterkey -y c:\backups\warehouse.log dbserver:/db/warehouse.fdb c:\backups\warehouse.fbk

A regular Restore

gbak -c -v -user SYSDBA -password masterkey c:\backups\warehouse.fbk dbserver:/db/warehouse2.fdb

Restore to an already existing database (Firebird 1.0, 1.5)

gbak -c -r -v -user SYSDBA -password masterkey c:\backups\warehouse.fbk dbserver:/db/warehouse.fdb

Restore to an already existing database (Firebird 2.x)

gbak -r o -v -user SYSDBA -password masterkey c:\backups\warehouse.fbk dbserver:/db/warehouse.fdb

Create a read-only database

gbak -c -v -mode read_only -use_all_space -user SYSDBA -password masterkey c:\backups\warehouse.fbk c:\files\warehousedb.fdb

Multi-file backups

Syntax for backup

gbak [options] <database> <target file 1> <size 1> <target file 2> <size 2> ... <target file n>

NOTE: Do not specify a size for the last file. It will always be filled to take up what is left over, no matter how large.

Size can be given in bytes (8192), kilobytes (1024k), megabytes (5m), or gigabytes (2g)

Syntax for restore

gbak -c [options] <source file 1> <source file 2> ... <source file n> <database>

Restoring to a multi-file database

gbak -c [options] <source file> <db file 1> <size 1> <db file 2> <size 2> ... <db file n>

NOTE: Do not specify a size for the last database file. It can always grow unlimited to take up the rest.

Size can be given in bytes (8192), kilobytes (1024k), megabytes (5m), or gigabytes (2g)

Restoring from a multi-file backup to a multi-file database

gbak -c [options] <source file 1> <source file 2> ... <source file n> <db file 1> <size 1> <db file 2> <size 2> ... <db file n>

Backup and Restore at the same time

Use this when you want to test the physical and logical health of your database or to copy a database to another location using a proper Backup-&-Restore cycle.

Note that stdin and stdout get special treatment from gbak here, so don’t use “/dev/stdin” or “/dev/stdout”.

Syntax

gbak -c [options] <source database> stdout | gbak -r [options] stdin <target database>

Backing up and Restoring the Security Database

Firebird 1.0, 1.5

You can perform a regular backup of the security database.  The security database resides in the Firebird directory. It is named

  • ISC4.gdb in Firebird 1.0 and
  • security.fdb in Firebird 1.5.

Firebird 2.x (using the Service Manager)

Firebird 2.x does not allow regular database access to the security database. Its name is now security2.fdb

The only way to access the security database is via the Service Manager. As GBAK can also use the Service Manager (Option -se), you can run a backup using this option. However, the backup file will also be written to the server machine.

General Syntax:

gbak <options> -user <username> -password <password> -service <servername>:service_mgr <sec-db-name> <backup-filename>

Example:

gbak -v -t -user sysdba -password masterkey -service dbserver:service_mgr c:\Programme\Firebird2\security2.fdb C:\Backups\Security2.fbk
  (in this case, Security2.fbk will be written to the C:\Backups folder of dbserver!)

When your database server listens on a non-default port:

gbak -v -t -user sysdba -password masterkey -se dbserver/3051:service_mgr c:\Programme\Firebird2\security2.fdb C:\Backups\Security2.fbk

Firebird 2.1/2.5

In Firebird 2.1 there is a new option -no_dbtriggers that suppresses database triggers from running during backup/restore. So you can suppress any unwanted behaviour for the connection that GBAK needs to establish for the database.

Restoring the Security Database

It is not possible to restore the security database while Firebird is running. In case your security database gets destroyed, this is what you can do:

  • Stop the Firebird service/daemon
  • Replace the current security database with a new one. If anything else fails, re-install the Firebird server
  • You should now have a working SYSDBA login and password. If not, re-install the Firebird server …
  • Start the Firebird service/daemon
  • Using GBAK, restore your backup of the security database to a temporary place (like C:\Temp\security2.fdb)
  • Stop the Firebird service/daemon again
  • Now copy the file from the temporary place to the correct place in the Firebird folder
  • Start the Firebird service/daemon
  • Now you should have your “old” security database back.
  • Good Luck! 🙂

Upgrading a Security Database to Firebird 2.0

There is a special chapter “Dealing with the New Security Database” about this in the Firebird 2.0 Release Notes, which get installed to the doc subdirectory of your Firebird directory. You should also take a look at the misc\upgrade\security\security_database.txt file, which explains in detail how to do it.