Se o Linux é utilizado, você já tem acesso a ferramentas extremamente poderosas para a criação de soluções de backup customizadas. As soluções neste artigo podem ajuda-lo a executar backups de rede simples até mais avançados e seguros usando as ferramentas de software livre que fazem parte de praticamente toda a distribuição Linux.

Backups Simples

Este artigo segue uma abordagem etapa por etapa direta, já que você segue as etapas básicas.

Vamos começar com um mecanismo de archive simples, mas poderoso, para uma solução de backup distribuído mais avançada. Examinaremos um script útil, chamado arc, que permite criar capturas instantâneas de backup de um prompt shell Linux.

   #!/bin/sh
   tar czvf $1.$(date +%Y%m%d-%H%M%S).tgz $1
   exit $?

O script arc aceita um arquivo simples ou nome de diretório como parâmetro e cria um arquivo archive compactado com a data atual integrada no nome de arquivo archive resultante. Por exemplo, se possui um diretório chamado beoserver, pode chamar o script arc, transmitindo para ele o nome do diretório beoserver para criar um archive compactado, por exemplo: beoserver.20040321-014844.tgz

O uso do comando date para integrar uma data e registro de data e hora o ajuda a organizar seus arquivos arquivados. O formato de data é Ano, Mês, Dia, Hora, Minutos e Segundos -- embora o uso do campo de segundos talvez seja exagero. Visualize a man page do comando de data (man date) para obter informações sobre outras opções. Além disso, na Lista 1, transmitimos a opção -v (verbose) para tar. Isso faz com que tar exiba todos os arquivos que ele está arquivando. Remova a opção -v se desejar que o backup continue silenciosamente.

   $ ls
   arc  beoserver
   $ ./arc beoserver
   beoserver/
   beoserver/bookl.dat
   beoserver/beoserver_ab_off
   beoserver/beoserver_ab_on
   $ ls
   arc  beoserver  beoserver.20040321-014844.tgz

Voltar para parte superior

Backups Avançados

Este exemplo de backup simples é útil; no entanto, ele ainda inclui um processo de backup manual. As boas práticas de mercado recomendam backups frequentes, em várias mídias, e a separação de locais geográficos. A ideia central é evitar contar inteiramente com qualquer mídia ou local único de armazenamento.

Mostraremos esse desafio em nosso próximo exemplo, onde examinaremos uma rede distribuída fictícia, ilustrada na Figura 1, que exibe um administrador do sistema com acesso a dois servidores remotos e um servidor de armazenamento de dados externo.

Os arquivos de backup no servidor #1 e #2 serão seguramente transmitidos para o servidor de armazenamento externo e todo o processo de backup distribuído ocorrerá regularmente, sem intervenção humana. Usaremos um conjunto de ferramentas padrão que fazem parte do conjunto de ferramentas Open Secure Shell (OpenSSH), bem como um arquivador de fita (tar) e o serviço de planejamento de tarefas cron. Nosso plano geral será usar cron para planejamento, programação shell e o aplicativo tar durante o processo de backup, criptografia OpenSSH secure shell (ssh) para acesso remoto e autenticação e a cópia shell segura (scp) para automatizar as transferências de arquivos. Certifique-se de rever cada man page da ferramenta para obter informações adicionais.

Voltar para parte superior

Acesso Remoto Seguro Usando Chaves Públicas/Privadas

No contexto de segurança digital, uma chave é uma parte dos dados usada para criptografar ou decriptografar outras partes dos dados. O esquema de chave pública e privada é interessante porque os dados criptografados com uma chave pública só podem ser decriptografados com a chave privada associada. É possível distribuir gratuitamente uma chave pública para que outros possam criptografar as mensagens enviadas para você. Um dos motivos pelos quais esses esquemas de chave pública/privada revolucionaram a segurança digital é porque o emissor e o receptor não precisam compartilhar uma senha comum. Entre outras coisas, a criptografia de chave pública/privada tornou possível o e-commerce e outras transações seguras. Neste artigo, criaremos e usaremos as chaves públicas e privadas para criar uma solução de backup distribuída altamente segura.

Cada máquina envolvida no processo de backup deve estar executando o OpenSSH secure shell service (sshd) com a porta 22 acessível através de qualquer firewall intermediário. Se os servidores remotos forem acessados, você terá boas chances de já estar utilizando shell seguro.

Nossa meta será fornecer máquinas com acesso seguro sem a necessidade do fornecimento de senhas manualmente. Algumas pessoas acham que a maneira mais fácil de fazer isso é configurar um acesso sem senha, mas nem pense nisso! Não é seguro. A abordagem que usaremos neste artigo, ao contrário, talvez requeira uma hora do seu tempo, com a configuração de um sistema que lhe fornece toda a conveniência de contas "sem passphrase", mas reconhecidamente como muito seguras.

Começaremos verificando se o OpenSSH está instalado e continuaremos verificando seu número de versão. Quando este artigo foi escrito, o release mais recente do OpenSSH era a versão 3.8, liberada em 24 de fevereiro de 2004. Considere usar um release recente e estável, e, no mínimo, use um release que seja mais recente que a versão 2.x. Visite a página de Segurança do OpenSSH para obter detalhes sobre as vulnerabilidades específicas das versões mais antigas (consulte o link em Recursos posteriormente neste artigo). No momento, o OpenSSH é muito estável e provou estar imune a muitas das vulnerabilidades reportadas para outras ferramentas SSH.

Em uma linha de comando do shell, digite ssh com a opção V em letra maiúscula para verificar o número de versão:

$ ssh -V
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

Se ssh retornar um número de versão maior que 2.x, a máquina estará relativamente em boa forma. No entanto, recomenda-se o uso de releases estáveis mais recentes de todos os softwares; isso é especialmente importante para o software relacionado à segurança.

Nossa primeira etapa é efetuar login na máquina do servidor de armazenamento externo usando a conta, que terá o privilégio de poder acessar os servidores 1 e 2 (consulte a Figura 1).

$ ssh accountname@somedomain.com

Depois de efetuado o logon na máquina de armazenamento externo, use o programa ssh-keygen para criar um par de chave pública/privada usando a opção -t dsa. A opção -t é exigida e usada para especificar o tipo de chave de criptografia na qual estamos interessados em geral. Usaremos o Digital Signature Algorithm (DSA), que permitirá o uso do protocolo SSH2 mais novo. Consulte a man page ssh-keygen para obter mais detalhes.

Durante a execução de ssh-keygen, lhe solicitarão fornecer o local no qual as chaves ssh serão armazenadas antes de fornecer uma passphrase. Basta pressionar Enter quando for solicitado a salvar a chave e o programa ssh-keygen criará um diretório oculto chamado .ssh (se não existir nenhum) junto com dois arquivos, um arquivo de chave pública e privada.

Um recurso interessante de ssh-keygen é que ele permite que um simples Enter seja pressionado quando uma passphrase é solicitada. Se não fornecer a passphrase, o ssh-keygen gerará chaves que não são criptografadas! Como pode imaginar, isso não é muito bom. Quando uma passphrase for solicitada, certifique-se de digitar uma mensagem de cadeia razoavelmente longa que contenha caracteres alfanuméricos em vez de uma cadeia de senha simples.

   [offsite]:$ ssh-keygen -t dsa
   Gerando par de chaves dsa pública/privada.
   Inserir o arquivo no qual salvar a chave (/home/accountname/.ssh/id_dsa):
   Inserir passphrase (vazio para nenhuma passphrase): (enter passphrase)
   Inserir a mesma passphrase novamente: (enter passphrase)
   Sua identificação foi salva em /home/accountname/.ssh/id_dsa.
   Sua chave pública foi salva em /home/accountname/.ssh/id_dsa.pub.
   A impressão digital da chave é:
   7e:5e:b2:f2:d4:54:58:6a:fa:6b:52:9c:da:a8:53:1b accountname@offsite

Como o diretório .ssh que o ssh-keygen cria é um diretório "dot" oculto, transmita a opção -a para o comando ls para visualizar o diretório criado recentemente:

[offsite]$ ls -a
. .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh

Inserir o diretório .ssh oculto e listar o conteúdo:

[offsite]$ cd .ssh
[offsite]$ ls -lrt
id_dsa id_dsa.pub

Agora você tem uma chave privada (id_dsa) e uma chave pública (id_dsa.pub) no diretório oculto .ssh. É possível examinar o conteúdo de cada arquivo de chave usando um editor de texto como vi ou emacs ou simplesmente utilizando os comandos less ou cat. Será notado que o conteúdo consiste em caracteres alfanuméricos codificados em base64.

A seguir, precisamos copiar e instalar a chave pública nos servidores 1 e 2. Não use ftp. Em vez disso, use o programa de cópia segura para transmitir as chaves públicas em cada uma das máquinas remotas:

   [offsite]$ scp .ssh/id_dsa.pub accountname@server1.com:offsite.pub
   accountname@server1.com's password: (enter password, not new
   passphrase!)
   id_dsa.pub 100% |*****************************| 614 00:00

   [offsite]$ scp .ssh/id_dsa.pub accountname@server2.com:offsite.pub
   accountname@server2.com's password: (enter password, not new
   passphrase!)
   id_dsa.pub 100% |*****************************| 614 00:00

Depois de instalarmos as novas chaves públicas, poderemos nos conectar a cada máquina usando a passphrase especificada ao criar as chaves pública e privada. Agora, efetue login em cada máquina e anexe o conteúdo do arquivo offsite.pub em um arquivo chamado authorized_keys, que está armazenado em cada diretório .ssh da máquina remota. Podemos usar um editor de texto ou simplesmente usar o comando cat para anexar o conteúdo do arquivo offsite.pub no arquivo authorized_keys:

   [offsite]$ ssh accountname@server1.com
   accountname@server1.com's password: (enter password, not new
   passphrase!)
   [server1]$ cat offsite.pub >> ./ssh/authorized_keys

A próxima etapa envolve a implementação de um bit de segurança extra. Primeiro, alteramos os direitos de acesso para o diretório .ssh, de modo que apenas o proprietário tenha privilégios de leitura, gravação e execução. Depois, verificamos se o arquivo authorized_keys pode apenas ser acessado pelo proprietário. E finalmente removemos o arquivo de chave offsite.pub anteriormente atualizado, pois ele não é mais necessário. É importante garantir que as permissões de acesso sejam corretamente configuradas, pois o servidor OpenSSH pode se recusar a usar chaves que tenham direitos de acesso que não sejam seguros.

   [server1]$ chmod 700 .ssh
   [server1]$ chmod 600 ./ssh/authorized_keys
   [server1]$ rm offsite.pub
   [server1]$ exit

Depois de concluir o mesmo processo em server2, estamos prontos a retornar à máquina de armazenamento externo para testar o novo acesso de tipo de passphrase. >Do servidor externo, é possível digitar o seguinte:

[offsite]$ ssh -v accountname@server1.com

Utilizar o comando -v, ou opção de sinalizador detalhado, para exibir as informações de depuração ao verificar se sua conta agora pode acessar o servidor remoto usando a nova passphrase em vez da senha original. A saída de depuração exibe informações importantes que podem não ser vistas, além de oferecer uma visualização de alto nível de como o processo de autenticação funciona. Não será necessário especificar o sinalizador -v nas conexões subsequentes; mas ele é muito útil ao testar uma conexão.

Voltar para parte superior

Automatizando o Acesso à Máquina Utilizando ssh-agent

O programa ssh-agent atua como um gatekeeper, fornecendo, com segurança, acesso às chaves de segurança conforme necessário. Depois que o ssh-agent é iniciado, ele fica em segundo plano e torna-se disponível a outros aplicativos OpenSSH como os programas ssh e scp. Isso permite que o programa ssh solicite uma chave já decriptografada, em vez de lhe pedir a passphrase secreta da chave privada sempre que necessário.

Vamos observar mais de perto o ssh-agent. Quando o ssh-agent é executado, ele efetua a saída dos comandos shell:

   [offsite]$ ssh-agent
   SSH_AUTH_SOCK=/tmp/ssh-XX1O24LS/agent.14179; export SSH_AUTH_SOCK;
   SSH_AGENT_PID=14180; export SSH_AGENT_PID;
   echo Agent pid 14180;

Podemos instruir o shell a executar os comandos de saída que o ssh-agent exibe usando o comando eval do shell:

[offsite]$ eval `ssh-agent`
Agent pid 14198

O comando eval pede ao shell para avaliar (executar) os comandos gerados pelo programa ssh-agent. Certifique-se de especificar o caractere de aspas invertidas (`) e não aspas simples! Depois de executado, a instrução eval `ssh-agent` retornará o identificar de processo do agente. Nos bastidores, as variáveis de shell SSH_AUTH_SOCK e SSH_AGENT_PID foram exportadas e agora estão disponíveis. É possível visualizar seus valores exibindo-os para o console shell:

[offsite]$ echo $SSH_AUTH_SOCK
/tmp/ssh-XX7bhIwq/agent.14197

O $SSH_AUTH_SOCK (abreviação para SSH Authentication Socket) é o local de um soquete local que os aplicativos podem usar para se comunicarem com o ssh-agent. Para garantir que as variáveis SSH_AUTH_SOCK e SSH_AGENT_PID estejam sempre registradas, digite a instrução eval `ssh-agent` em seu ~/.bash_profile.

Agora o ssh-agent se tornou um processo de plano de fundo que é visível utilizando os comandos top e ps.

Agora estamos prontos para compartilhar nossa passphrase com o ssh-agent. Para fazer isso, devemos usar um programa chamado ssh-add, que inclui (envia) nossa passphrase para o programa ssh-agent em execução.

   [offsite]$ ssh-add
   Inserir passphrase para /home/accountname/.ssh/id_dsa: (enter passphrase)
   Identificar incluído: /home/accountname/.ssh/id_dsa
   (/home/accountname/.ssh/id_dsa)

Agora, quando acessamos server1, não somos solicitados a fornecer uma passphrase:

[offsite]$ ssh accountname@server1.com
[server1]$ exit

Se você ainda não está convencido, tente remover (kill -9) o processo do ssh-agent e reconectar-se a server1. Agora será notado que server1 solicitará a passphrase para a chave privada armazenada no arquivo id_dsa no diretório .ssh:

[offsite]$ kill -9 $SSH_AGENT_PID
[offsite]$ ssh accountname@server1.com
Digitar passphrase para a chave '/home/accountname/.ssh/id_dsa':

Voltar para parte superior

Simplificando o Acesso à Chave Utilizando Keychain

Até agora falamos sobre os diversos programas OpenSSH (ssh, scp, ssh-agent e ssh-add) e criamos e instalamos as chaves públicas e privadas para ativar um processo de login automatizado e seguro. Você pode ter percebido que a maioria do nosso trabalho de configuração ocorre apenas uma vez. Por exemplo, o processo de criação de chaves, a instalação delas e a obtenção do ssh-agent para execução via .bash_profile só precisam ser feitos uma vez por máquina. Isso é excelente.

A má notícia é que ssh-add deve ser chamado sempre que nos conectamos à máquina externa e ssh-agent não é imediatamente compatível com o processo de planejamento cron necessário para a automatização de nossos backups. O motivo pelo qual esses processos cron não podem se comunicar com o ssh-agent é que as tarefas cron são executadas como processos filhos pelo cron e, assim, não herdam a variável de shell $SSH_AUTH_SOCK.

Felizmente, há uma solução na qual não apenas se elimina as limitações associadas ao ssh-agent e ssh-add, como também permite o uso de cron para automatizar todos os tipos de processos que exigem acesso sem senha seguro para outras máquinas. Na série de três partes do developerWorks de 2001, OpenSSH Key Management (consulte Recursos para obter um link), Daniel Robbins apresentou um script shell chamado keychain, que é um frontend para ssh-add e ssh-agent e que simplifica todo o processo sem senha. Com o tempo, o script keychain teve diversos aperfeiçoamentos e agora é mantido por Aron Griffis, com um release 2.3.2-1 recente lançado em 17 de junho de 2004.

O script shell keychain é um muito grande para ser listado neste artigo, pois o script bem escrito inclui muitas verificações de erros, ampla documentação e uma generosa apresentação de código entre plataformas. No entanto, keychain pode ser rapidamente transferido por download do Web site do projeto (consulte Recursos para obter um link).

Depois de transferir por download e instalar keychain, seu uso será bastante fácil. Basta efetuar login em cada máquina e incluir as seguintes duas linhas em cada .bash_profile:

keychain id_dsa
. ~/.keychain/$HOSTNAME-sh

Na primeira vez que você efetuar login novamente em cada máquina, keychain solicitará a passphrase. No entanto, keychain não pedirá que a passphrase seja digitada novamente em tentativas de login subsequentes, a menos que a máquina tenha sido reiniciada. A melhor parte é que as tarefas cron agora podem usar os comandos OpenSSH para acessar com segurança máquinas remotas sem exigir o uso interativo de passphrases. Agora temos o melhor dos dois mundos, segurança incluída e facilidade de uso.

   KeyChain 2.3.2; http://www.gentoo.org/projects/keychain
   Copyright 2002-2004 Gentoo Technologies, Inc.; Distributed under the
   GPL

   * Inicializando arquivo /home/accountname/.keychain/localhost.localdomain-sh...
   * Inicializando arquivo /home/accountname/.keychain/localhost.localdomain-csh...
   * Iniciando ssh-agent
   * Incluindo 1 chave(s)...
   Inserir passphrase para /home/accountname/.ssh/id_dsa: (enter passphrase)

Voltar para parte superior

Gerando Script de um Processo de Backup

Nossa próxima tarefa é criar os scripts shell, que executarão as operações de backup necessárias. A meta é executar um backup completo do banco de dados dos servidores 1 e 2. Em nosso exemplo, cada servidor está executando o servidor de banco de dados MySQL e usaremos o utilitário de linha de comandos mysqldump para exportar algumas tabelas de banco de dados para um arquivo de importação SQL.

   #!/bin/sh

   # ir para o diretório backup_agent no qual os arquivos de dados estão armazenados.
   cd /home/backup_agent

   # utilizar o utilitário mysqldump para exportar as tabelas de bancos de dados de sites
   mysqldump -u sitedb -pG0oDP@sswrd --add-drop-table sitedb --tables
   tbl_ccode tbl_machine tbl_session tbl_stats > userdb.sql

   # compactar e arquivar
   tar czf userdb.tgz userdb.sql

No servidor 2, colocaremos um script semelhante que fará backup da apresentação das tabelas exclusivas no banco de dados do site. Cada script é sinalizado como executável utilizando:

[server1]:$ chmod +x dbbackup.sh

Com um arquivo dbbackup.sh nos servidores 1 e 2, retornamos ao servidor de dados externo, no qual criaremos um script shell para chamar cada script dbbackup.sh remoto antes de inicializar uma transferência dos arquivos de dados compactados (.tgz).

   #!/bin/sh

   # utilizar ssh para executar remotamente o script dbbackup.sh no servidor 1
   /usr/bin/ssh backup_agent@server1.com "/home/backup_agent/dbbackup.sh"

   # utilizar scp para copiar com segurança o arquivo userdb.tgz recentemente arquivado
   # do servidor 1.  Observe o uso do comando date para efetuar o registro de data e hora
   # do arquivo no servidor de dados externo.
   /usr/bin/scp backup_agent@server1.com:/home/backup_agent/userdb.tgz
   /home/backups/userdb-$(date +%Y%m%d-%H%M%S).tgz

   # executar dbbackup.sh no servidor 2
   /usr/bin/ssh backup_agent@server2.com "/home/backup_agent/dbbackup.sh"

   # utilizar scp para transferir transdb.tgz para o servidor externo.
   /usr/bin/scp backup_agent@server2.com:/home/backup_agent/transdb.tgz
   /home/backups/transdb-$(date +%Y%m%d-%H%M%S).tgz

O script shell backup_remote_servers.sh utiliza o comando ssh para executar um script nos servidores remotos. Como configuramos o acesso sem senha, o comando ssh pode executar comandos nos servidores 1 e 2 remotamente do servidor externo. Todo o processo de autenticação agora é feito automaticamente, graças a keychain.

Voltar para parte superior

Planejamento

Nossa próxima e última tarefa envolve planejar a execução do script shell backup_remote_servers.sh no servidor de armazenamento de dados externo. Incluiremos duas entradas no servidor de planejamento cron para solicitar a execução do script de backup duas vezes por dia, às 03:34 e novamente às 20:34. No servidor externo chamamos o programa crontab com a opção de edição (-e).

[offsite]:$ crontab -e

O crontab chama o editor padrão, como especificado, utilizando as variáveis de ambiente shell VISUAL ou EDITOR. Depois, digita duas entradas e salva e fecha o arquivo.

   34 3 * * * /home/backups/remote_db_backup.sh
   34 20 * * * /home/backups/remote_db_backup.sh

Uma linha crontab contém duas seções principais, uma seção de planejamento de tempo seguida por uma seção de comando. O planejamento de tempo é dividido em campos para especificação quando um comando deve ser executado:

          +---- minuto
          | +----- hora
          | | +------ dia do mês
          | | | +------ mês
          | | | | +---- dia da semana
          | | | | | +-- comando para executar
          | | | | | |
         34 3 * * * /home/backups/remote_db_backup.sh

Voltar para parte superior

Verificando seus Backups

É necessário verificar com frequência seus backups para garantir que o processo esteja funcionando corretamente. Os processos de automatização podem eliminar o trabalho desnecessário, mas nunca devem ser uma forma de escapar de obrigações. Se o backup de seus dados é valioso, também é importante fazer a verificação de tempo em tempo.

Considere incluir uma tarefa cron para lembrá-lo de verificar seus backups pelo menos uma vez por mês. Além disso, é uma boa ideia alterar as chaves de segurança de vez em quando e é possível planejar uma tarefa cron para lembrá-lo também disso.

Voltar para parte superior

Precauções de Segurança Adicionais

Para mais segurança, considere instalar e configurar um Intrusion Detection System (IDS), como o Snort, em cada máquina. Presumidamente, um IDS o notificará quando uma intrusão está prestes a ser feita ou que ocorreu recentemente. Como um IDS, será possível incluir outros níveis de segurança como assinatura digital e criptografia de seus backups.

As ferramentas de software livre populares como GNU Privacy Guard (GnuPG), OpenSSL e ncrypt permitem arquivos archive seguros através de scripts shell, mas não é recomendável fazer isso sem o nível extra de proteção que um IDS fornece (consulte Recursos para obter informações adicionais sobre o Snort).

Voltar para parte superior

Conclusão

Este artigo mostrou como seus scripts podem ser executados em servidores remotos e como executar transferências de arquivos seguros e automatizados. Espero que inspire-se a pensar sobre como proteger seus valiosos dados e como criar novas soluções usando ferramentas de software livre como OpenSSH e Snort.

Recursos

• Encontre downloads, documentações e muito mais na home page oficial do OpenSSH e na página de Segurança do OpenSSH.
  
  
• Leia o excelente artigo de três partes de Daniel Robbins sobre o IBM developerWorks, "OpenSSH Key Management" (developerWorks, 2001) e faça download de seu aplicativo keychain.
  
  
• Para obter informações adicionais sobre o SSH, Carlos recomenda SSH, The Secure Shell: The Definitive Guide de O'Reilly (O'Reilly & Associates, 2001).
  
  
• O Snort Intrusion Detection System (IDS) é a melhor geração de produtos de software livre criados para detectar e reportar acesso não autorizado ou comportamento suspeito. Certifique-se de usar um IDS se planeja automatizar a assinatura e criptografia de arquivos archive.
  
  
• É possível assinar e criptografar seus arquivos de backup archive utilizando GNU Privacy Guard (GnuPG), OpenSSL e ncrypt de seus scripts shell.
  
  
• Se não são ainda utilizados, veja essas dicas sobre TCP wrappers e xinetd.
  
  
• As pessoas interessadas em Perl também se interessarão por "Automating UNIX system administration with Perl" (developerWorks, 2001), "Intro to cfengine for system administration" (developerWorks, 2002), e "Application configuration with Perl" (developerWorks, 2000), todos de Ted Zlatanov.
  
  
• O artigo developerWorks "Windows-to-Linux roadmap: Part 8. Backup and recovery" (developerWorks, 2003) oferece dicas sobre estratégias de backup.
  
  
• O Tivoli Storage Manager para Linux da IBM também pode automatizar backups, archive e gerenciamento central de dados confiáveis para computadores Linux e servidores em planejamentos customizados. Além disso, A Família de Produtos Tivoli oferece produtos para gerenciamento de usuário, controle de acesso, monitoramento de rede -- e mais -- tudo com um ambiente e uma interface unificados.
  
  
• Saiba mais sobre as soluções Tivoli na zona Tivoli do IBM developerWorks.
  
  
• Encontre mais recursos para desenvolvedores Linux na developerWorks.
  
  
• Navegue em Manuais nesses e em outros tópicos técnicos.
  
  
• Desenvolva e teste seus aplicativos Linux utilizando as ferramentas e middlewares IBM mais recentes com uma assinatura do developerWorks: adquira o software IBM do WebSphere, DB2, Lotus, Rational e Tivoli e uma licença para usar o software por 12 meses, tudo por menos do que você imagina.
  
  
• Faça download sem custo das versões de avaliação dos produtos com assinatura do developerWorks que executam em Linux, incluindo o WebSphere Studio Site Developer, WebSphere SDK para serviços da Web, WebSphere Application Server, DB2 Universal Database Personal Developers Edition, Tivoli Access Manager, e Lotus Domino Server, da seção Speed-start your Linux app do developerWorks. Para um início ainda mais rápido, aproveite uma coleta produto por produto de artigos com instruções e suporte à tecnologia.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Backups Simples
• Backups Avançados
• Acesso Remoto Seguro Usando Chaves Públicas/Privadas
• Automatizando o Acesso à Máquina Utilizando ssh-agent
• Simplificando o Acesso à Chave Utilizando Keychain
• Gerando Script de um Processo de Backup
• Planejamento
• Verificando seus Backups
• Precauções de Segurança Adicionais
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais