Contents
- Backup do AIX: O básico
- A definição de backup do AIX
- Principais terminologias em AIX
- Tipos de backup aplicáveis ao AIX
- O método de backup AIX mais adequado em uma situação específica
- Comandomksysb para backups do sistema
- Comandosavevg para backups de grupos de volumes
- Backups personalizados usando tar, cpio e dd
- Guia passo a passo sobre a realização de backups do AIX
- Preparação do sistema AIX para backup
- Criação de um backup completo do sistema com o mksysb
- Como fazer backup de grupos de volumes usando o savevg
- Criação de backups personalizados com o tar
- Automação de backups AIX para maior eficiência
- Uso de cron Jobs para agendar backups
- Geração de scripts de backup para tarefas repetidas
- Análise e verificação automática de backups
- Restauração de dados de backups do AIX
- Restauração completa do backup do sistema com o mksysb
- Recuperação de dados de backups de grupos de volumes
- Extração de arquivos de backups tar ou cpio
- Práticas recomendadas para tarefas de backup e processos de recuperação do AIX
- Testes regulares de backup
- Rotação de mídia de backup para segurança máxima
- Documentação do procedimento de backup
- Desafios conhecidos e suas soluções em backups AIX
- Limitações de espaço de armazenamento para backups
- Diagnóstico e solução de falhas de backup
- Problemas de compatibilidade de dispositivos de backup
- Software de backup AIX de terceiros
- Veeam
- Bacula Enterprise
- Commvault
- Conclusão
- Perguntas frequentes
- Os backups do AIX podem ser executados em um sistema ativo?
- Quais são as melhores ferramentas para monitorar o desempenho do backup no AIX?
- Qual é a melhor maneira de migrar os backups do AIX para o armazenamento em nuvem?
- Posso agendar vários tipos de backup simultaneamente?
- O que precisa ser feito se a mídia de backup do AIX for corrompida?
Quando se trata de computação corporativa, os sistemas AIX ainda são muito importantes em uma ampla gama de tarefas ou operações de missão crítica. Esses ambientes robustos baseados em UNIX também precisam de estratégias de backup igualmente flexíveis para garantir a continuidade dos negócios e proteger as informações confidenciais da organização. A proteção de toda a infraestrutura AIX é um imperativo comercial e não apenas um requisito técnico.
A infraestrutura AIX também tem vários desafios específicos que a diferenciam de outros possíveis alvos de backup. Essas nuances devem ser sempre consideradas ao projetar uma estratégia de backup. Nosso objetivo neste artigo é criar um guia completo e detalhado para o gerenciamento de backup do AIX, incluindo conceitos fundamentais, técnicas avançadas, abordagens comprovadas, estratégias de automação e, por fim, alguns exemplos de nossas soluções de backup recomendadas para uso em tais cenários.
Backup do AIX: O básico
Ter uma compreensão clara do “como” e do “porquê” das operações de missão crítica é a base de uma estrutura eficiente de administração de sistemas. As estratégias de backup do AIX dependem muito das ferramentas proprietárias da IBM em combinação com utilitários padrão, o que as torna substancialmente diferentes da maioria das abordagens de backups em outras distribuições do Linux ou variantes do UNIX.
A definição de backup do AIX
O backup do AIX é um conjunto complexo de tecnologias e processos com o objetivo único de criar uma cópia restaurável das informações do sistema, juntamente com todos os seus aplicativos e configurações. O AIX usa um sistema complexo de gerenciamento de volumes lógicos que exige uma abordagem não convencional das tarefas de backup e recuperação para garantir que todos esses processos sejam conduzidos com eficiência.
A necessidade de criar soluções de backup tão robustas para ambientes AIX nasceu de uma série de fatores. As cargas de trabalho mais sensíveis em instituições financeiras, provedores de serviços de saúde e operações de manufatura geralmente dependem do AIX e, incidentalmente, esses setores também costumam ser os mais sensíveis no que diz respeito à disponibilidade da infraestrutura. Uma única hora de tempo de inatividade do sistema pode custar a uma dessas organizações mais de milhões de dólares.
Além das considerações financeiras, há também o importante tópico da conformidade normativa. Diversas estruturas de conformidade, como PCI-DSS, SOX ou HIPAA, exigem protocolos de backup muito específicos com relação a informações confidenciais. Muitas outras medidas de proteção de dados também são mencionadas no contexto dessas normas, sendo que os sistemas AIX geralmente são o principal armazenamento das informações exatas que são consideradas confidenciais ou importantes.
Por fim, é importante considerar que os backups AIX atuam como a última linha de defesa contra qualquer tipo de ameaça cibernética. Os ataques de ransomware que têm como alvo os sistemas corporativos são comuns há vários anos, e muitos agentes de ameaças criam malware com o objetivo de atingir os sistemas de backup juntamente com o armazenamento padrão de informações. Uma estratégia de backup AIX adequadamente planejada e executada é a melhor abordagem para combater esses ataques complexos.
Principais terminologias em AIX
As operações de backup do AIX geralmente giram em torno de conceitos e termos específicos que formam o vocabulário básico da segurança da informação:
- O mksysb é um utilitário capaz de criar imagens de sistema inicializáveis que contêm todo o rootvg e os grupos de volumes do sistema operacional. Essas imagens podem ser empregadas como uma ferramenta de implementação do sistema e como uma medida de recuperação de desastres.
- O grupo de volumes rootvg é o local de armazenamento do sistema operacional (e nada mais, já que os grupos de volumes definidos pelo usuário devem abrigar dados de aplicativos nessas situações).
- savevg é um comando que tem como alvo grupos de volumes fora do rootvg para realizar operações de backup complexas que também incluem dados do usuário e não apenas o sistema operacional.
- JFS e JFS2 são sistemas de arquivos com registro de transações capazes de manter a consistência do sistema de arquivos o tempo todo; eles também podem influenciar a maneira como os backups interagem com as informações em uso.
- EMG são grupos de montagem aprimorados que possibilitam backups consistentes de vários ambientes ao mesmo tempo.
- NIM é o gerenciador de instalação de rede que tem a tarefa de simplificar e centralizar muitas tarefas de gerenciamento de backup.
- TSM é um gerenciador de armazenamento Tivoli – uma ferramenta importante para manter a consistência do backup em diferentes sistemas de arquivos.
- As operações de clone permitem a duplicação de grupos de volumes inteiros para fins de backup.
Tipos de backup aplicáveis ao AIX
Os backups do AIX podem operar em quatro metodologias principais. Os backups completos usam uma das ferramentas acima para capturar todo o sistema operacional com todos os seus aplicativos e arquivos de configuração. Eles exigem espaço de armazenamento e tempo de processamento significativos, mas podem oferecer restauração completa do sistema após praticamente qualquer problema.
Os backups de grupos de volumes concentram-se em conjuntos de dados específicos dentro do sistema de gerenciamento de volumes lógicos do AIX. Eles podem otimizar o uso de recursos e, ao mesmo tempo, oferecer um certo grau de granularidade aos processos de backup.
Os backups incrementais e diferenciais podem minimizar a sobrecarga, pois só conseguem capturar as alterações feitas desde o backup anterior. Essas estratégias podem reduzir drasticamente as janelas de backup, mas tornam as tarefas de restauração significativamente mais complexas em comparação.
Os backups em nível de arquivo usam uma ideia semelhante como filosofia de backup, fornecendo controle granular sobre quais dados podem ser protegidos usando ferramentas padrão como cpio, tar, etc.
A implementação estratégica de um ou vários desses tipos de backup pode ser usada para formar uma estrutura de proteção de dados em camadas que equilibra o desempenho do sistema e as restrições de recursos com a complexidade da proteção de dados.
O método de backup AIX mais adequado em uma situação específica
Agora que temos o contexto das diferentes abordagens das operações de backup, é hora de analisar a melhor maneira de aplicá-las em diferentes situações.
Há muitos fatores importantes que precisam ser considerados ao criar uma metodologia de backup complexa: restrições de janela de backup, complexidade operacional, objetivos de tempo de recuperação, limitações de armazenamento, etc. Felizmente, os utilitários nativos do AIX podem ser usados em diferentes cenários de proteção e também têm suas próprias vantagens em alguns casos.
Alguns comandos ou sinalizadores podem variar de acordo com a versão do AIX utilizada. Recomendamos consultar a documentação oficial de sua versão específica do AIX para saber quais comandos são suportados.
Comandomksysb para backups do sistema
Como mencionado anteriormente, o mksysb cria um backup completo e inicializável de todo o sistema operacional AIX com todo o seu conteúdo (no grupo de volumes rootvg ). Um desses backups pode ser usado para reconstruir um ambiente inteiro a partir do zero, quando necessário.
O processo completo de criação de um backup mksysb pode ser dividido em várias fases. Primeiro, ele cria um arquivo ./bosinst.data que contém todos os detalhes de configuração da instalação. Em segundo lugar, ele cria uma tabela de conteúdo para todos os arquivos rootvg antes de arquivá-los. Até mesmo o local da imagem em questão pode ser alterado, direcionando-a para outros arquivos, locais de rede, unidades de fita separadas, etc.
Há também o fato de que o mksysb segue a lógica dos backups completos regulares – eles demoram um pouco para serem concluídos e precisam de muito espaço de armazenamento, o que o torna pouco prático para uso frequente. Por isso, a maioria das empresas tende a usar o mksysb apenas ocasionalmente (semanal ou mensalmente) e, ao mesmo tempo, a apoiá-lo com backups mais frequentes (incrementais ou diferenciais), tentando obter um equilíbrio entre o impacto operacional e a segurança das informações.
Comandosavevg para backups de grupos de volumes
Quanto às informações armazenadas fora do grupo de volumes rootvg, é possível fazer o backup usando um comando chamado savevg. Trata-se de um utilitário que visa a grupos de volumes específicos que contêm dados de aplicativos, arquivos de banco de dados e informações de usuários, oferecendo um controle muito mais granular sobre os alvos de backup.
A sintaxe geral do savevg é quase idêntica à usada para o mksysb, sendo a localização dos grupos de volumes de destino uma das maiores diferenças:
Essa abordagem tem suas próprias vantagens, que incluem segurança direcionada do conjunto de dados, redução da janela de backup e a capacidade de ser conduzida sem afetar as operações do sistema. Por outro lado, um ambiente AIX em funcionamento continua sendo um requisito para restaurar qualquer backup savevg, o que exige o uso de ambas as opções na mesma estratégia de backup.
Backups personalizados usando tar, cpio e dd
As ferramentas padrão do UNIX também podem ser usadas como ferramentas de backup em determinados casos de uso, quando os utilitários específicos do AIX não estão à altura da tarefa. Algumas dessas ferramentas podem oferecer um grau substancial de controle granular sobre as operações de backup em combinação com a compatibilidade entre plataformas.
Por exemplo, o conhecido comando tar é uma ótima maneira de criar backups de conjuntos de arquivos ou diretórios específicos, e sua sintaxe é relativamente simples:
Guia passo a passo sobre a realização de backups do AIX
A realização de backups eficientes em ambientes AIX exige execução metódica e preparação cuidadosa em vários níveis. Nesta seção, tentaremos detalhar o processo de abordagem de backups de diferentes maneiras. Todas as etapas são testadas em campo e equilibradas de forma específica para oferecer eficiência e rigor, garantindo que os sistemas críticos permaneçam seguros e protegidos sem complexidade desnecessária.
Preparação do sistema AIX para backup
Antes de iniciar qualquer operação de backup, é necessário realizar a preparação adequada do sistema para aumentar a confiabilidade dos backups e melhorar as taxas de sucesso das restaurações subsequentes. Há algumas questões importantes que gostaríamos de explorar aqui:
- Verificar a estabilidade do sistema verificando os registros de erros quanto a possíveis problemas que possam comprometer a integridade do backup:
- Localizar e resolver quaisquer erros críticos e, ao mesmo tempo, garantir que haja espaço livre suficiente no sistema de arquivos onde as imagens de backup serão armazenadas:
- Atualize o Object Data Manager para garantir que ele possa capturar todos os detalhes da configuração atual do sistema (especificamente para operações mksysb ):
- Limpe os arquivos desnecessários, como core dumps, arquivos temporários ou registros:
# find /tmp -type f -mtime +3 -exec rm {} \;
- Verifique se todos os dispositivos de backup estão acessíveis e configurados corretamente – por exemplo, a acessibilidade da unidade de fita é verificada desta forma:
- Considere se os backups consistentes com aplicativos exigem uma parada total do serviço ou se há uma opção fornecida pelo fornecedor para garantir a integridade dos dados (se houver backup dos sistemas de banco de dados). Muitos ambientes de banco de dados populares de nível empresarial oferecem seus próprios mecanismos de backup que também devem ser usados nos processos de backup do AIX, quando aplicável.
Esses preparativos podem ajudar a transformar um processo mecânico em uma operação estratégica bem pensada, com as melhores opções de proteção de dados disponíveis.
Criação de um backup completo do sistema com o mksysb
O utilitário mksysb é uma boa maneira de criar um backup abrangente e consistente do sistema para o ambiente AIX. A sintaxe original é bastante simples, e ele ainda tem várias opções e personalizações diferentes para melhorar o resultado final.
Por exemplo, podemos começar criando um arquivo de imagem de backup em vez de gravar o backup diretamente em um local de destino, oferecendo flexibilidade nos processos de verificação subsequentes:
Para capturar os arquivos que não estão incluídos no backup padrão, seria necessário editar a lista de exclusão com antecedência, o que pode ser feito com este comando:
Como fazer backup de grupos de volumes usando o savevg
Os grupos de volumes de dados geralmente incluem algumas das informações mais valiosas que uma empresa pode ter, o que torna sua proteção fundamental. O comando savevg deve oferecer o recurso de backup direcionado que complementa os backups em nível de sistema que discutimos acima.
Parte da sintaxe do mksysb também se aplica aqui, como o recurso de fazer backup de um grupo de volumes como um arquivo:
savevg -i /backup/${VG}_$(date +%Y%m%d).savevg $VG
done
Criação de backups personalizados com o tar
Se considerarmos a possibilidade de arquivos ou diretórios específicos necessitarem de backups em vez de grupos de volumes inteiros, podemos usar o tar como alternativa nesses casos, pois ele oferece flexibilidade e precisão. Ele pode lidar com uma ampla gama de backups que não podem ser realizados pelo mksysb ou pelo savevg com o mesmo nível de eficiência.
O backup básico de diretórios com o tar pode ter a seguinte aparência:
# tar -cvf /backup/full_backup.tar /data
# touch /backup/tar_timestamp
Automação de backups AIX para maior eficiência
Em um ambiente moderno, os processos manuais de backup são a causa de riscos desnecessários devido à possibilidade de erro humano ou execução inconsistente. A automação é a solução para esses problemas, transformando os backups de tarefas individuais em uma estrutura de proteção complexa. Os próprios ambientes AIX têm uma ampla gama de recursos de automação capazes de criar processos de backup confiáveis e consistentes, quando configurados adequadamente.
Uso de cron Jobs para agendar backups
O recurso cron pode ser a base para o agendamento de backup no AIX, oferecendo controle preciso sobre operações recorrentes. Em vez de depender dos administradores para executar cada sequência de comandos manualmente, o cron pode fornecer a consistência dos processos de backup de acordo com programações predefinidas.
Nosso primeiro passo seria definir as permissões corretas para o futuro arquivo de script de backup:
0 1 * * 0 /usr/local/bin/full_backup.sh > /var/log/full_backup.log 2>&1
# Incremental backups Monday-Saturday at 2:00 AM
0 2 * * 1-6 /usr/local/bin/incremental_backup.sh > /var/log/inc_backup.log 2>&1
# Application-specific backup at midnight daily
0 0 * * * /usr/local/bin/app_backup.sh > /var/log/app_backup.log 2>&1
Se uma empresa precisar de agendamento centralizado em vários ambientes AIX ao mesmo tempo, o Network Installation Manager pode ser mais adequado para esses fins. O NIM pode ajudar os administradores a definir políticas de backup uma vez e aplicá-las em toda a infraestrutura de forma consistente.
Geração de scripts de backup para tarefas repetidas
A automação eficaz do backup utiliza scripts bem estruturados capazes de lidar com a operação de backup e todas as etapas importantes relacionadas a ela – preparação, verificação e limpeza. A criação de um desses scripts de backup transforma uma seleção de comandos desarticulados em um fluxo de trabalho abrangente capaz de melhorar muito a confiabilidade dos processos de backup.
Um backup básico do mksysb deve ter a seguinte aparência:
# mksysb_backup.sh – Full system backup script
# Set variables
BACKUP_DIR=”/backup”
BACKUP_FILE=”${BACKUP_DIR}/$(hostname)_rootvg_$(date +%Y%m%d).mksysb”
LOG_FILE=”/var/log/mksysb_$(date +%Y%m%d).log”
# Ensure backup directory exists
if [ ! -d “$BACKUP_DIR” ]; then
mkdir -p “$BACKUP_DIR”
fi
# Log start time
echo “Backup started at $(date)” > “$LOG_FILE”
# Clean up filesystem
echo “Cleaning temporary files…” >> “$LOG_FILE”
find /tmp -type f -mtime +7 -exec rm {} \; >> “$LOG_FILE” 2>&1
find /var/tmp -type f -mtime +7 -exec rm {} \; >> “$LOG_FILE” 2>&1
# Update ODM
echo “Updating ODM…” >> “$LOG_FILE”
savebase -v >> “$LOG_FILE” 2>&1
# Create mksysb backup
echo “Creating mksysb backup…” >> “$LOG_FILE”
mksysb -i “$BACKUP_FILE” >> “$LOG_FILE” 2>&1
RC=$?
# Verify backup
if [ $RC -eq 0 ]; then
echo “Verifying backup integrity…” >> “$LOG_FILE”
lsmksysb -l “$BACKUP_FILE” >> “$LOG_FILE” 2>&1
echo “Backup completed successfully at $(date)” >> “$LOG_FILE”
else
echo “Backup FAILED with return code $RC at $(date)” >> “$LOG_FILE”
# Send alert
echo “System backup failed on $(hostname)” | mail -s “Backup Failure Alert” admin@example.com
fi
# Cleanup old backups (keep last 4)
find “$BACKUP_DIR” -name “$(hostname)_rootvg_*.mksysb” -mtime +28 -exec rm {} \; >> “$LOG_FILE” 2>&1
exit $RC
Se um script de backup for criado para ambientes com vários grupos de volumes, ainda será possível personalizar o script para incluir todos os processos de backup necessários:
# multi_vg_backup.sh – Back up multiple volume groups
BACKUP_DIR=”/backup”
LOG_FILE=”/var/log/vg_backup_$(date +%Y%m%d).log”
VOLUME_GROUPS=”datavg appvg dbvg”
echo “Volume group backup started at $(date)” > “$LOG_FILE”
for VG in $VOLUME_GROUPS; do
echo “Backing up volume group $VG…” >> “$LOG_FILE”
BACKUP_FILE=”${BACKUP_DIR}/${VG}_$(date +%Y%m%d).savevg”
# Check if volume group exists and is varied on
lsvg $VG > /dev/null 2>&1
if [ $? -ne 0 ]; then
echo “ERROR: Volume group $VG does not exist or is not varied on” >> “$LOG_FILE”
continue
fi
# Perform backup
savevg -i “$BACKUP_FILE” $VG >> “$LOG_FILE” 2>&1
RC=$?
if [ $RC -eq 0 ]; then
echo “$VG backup completed successfully” >> “$LOG_FILE”
else
echo “$VG backup FAILED with return code $RC” >> “$LOG_FILE”
echo “Volume group $VG backup failed on $(hostname)” | mail -s “VG Backup Failure” admin@example.com
fi
done
echo “All volume group backups completed at $(date)” >> “$LOG_FILE”
# advanced_backup.sh – Modular backup functions
# Source common functions
. /usr/local/lib/backup_functions.sh
# Configuration
CONFIG_FILE=”/etc/backup/backup.conf”
source “$CONFIG_FILE”
# Main function
main() {
initialize_backup
check_prerequisites
case “$BACKUP_TYPE” in
“full”)
perform_full_backup
;;
“incremental”)
perform_incremental_backup
;;
“application”)
perform_application_backup
;;
*)
log_error “Unknown backup type: $BACKUP_TYPE”
exit 1
;;
esac
verify_backup
cleanup_old_backups
send_notification
}
# Start execution
main “$@”
Esses três exemplos devem fornecer à maioria dos usuários muitas informações sobre como o desenvolvimento de scripts evolui da execução de comandos básicos para a criação de fluxos de trabalho complexos com todas as opções necessárias de tratamento de erros, registro em log e design modular.
Análise e verificação automática de backups
É lógico pensar que os backups automatizados também devem ter processos de monitoramento e verificação automatizados para eles. No entanto, a automação de processos pode criar uma perigosa ilusão de normalidade quando não há confirmação real de seu sucesso.
Um script de verificação básico deve ser capaz de, pelo menos, verificar o tamanho do backup e o fato de que ele existe:
# verify_backups.sh – Check backup integrity
BACKUP_DIR=”/backup”
MIN_SIZE=1048576 # 1 MB in bytes
MAIL_RECIPIENT=”admin@example.com”
REPORT_FILE=”/tmp/backup_verification_$(date +%Y%m%d).txt”
echo “Backup Verification Report – $(date)” > “$REPORT_FILE”
echo “=====================================\n” >> “$REPORT_FILE”
# Check yesterday’s backup files
YESTERDAY=$(date -d “yesterday” +%Y%m%d)
BACKUP_FILES=$(find “$BACKUP_DIR” -name “*${YESTERDAY}*” -type f)
if [ -z “$BACKUP_FILES” ]; then
echo “ERROR: No backup files found for $YESTERDAY” >> “$REPORT_FILE”
cat “$REPORT_FILE” | mail -s “Backup Verification FAILED” “$MAIL_RECIPIENT”
exit 1
fi
FAILURE_COUNT=0
for FILE in $BACKUP_FILES; do
echo “Checking $FILE:” >> “$REPORT_FILE”
# Check file size
SIZE=$(ls -l “$FILE” | awk ‘{print $5}’)
if [ “$SIZE” -lt “$MIN_SIZE” ]; then
echo ” – WARNING: File size too small ($SIZE bytes)” >> “$REPORT_FILE”
FAILURE_COUNT=$((FAILURE_COUNT + 1))
continue
fi
# Check file type
if [[ “$FILE” == *.mksysb ]]; then
echo ” – Verifying mksysb archive:” >> “$REPORT_FILE”
lsmksysb -l “$FILE” > /dev/null 2>&1
RC=$?
elif [[ “$FILE” == *.savevg ]]; then
echo ” – Verifying savevg archive:” >> “$REPORT_FILE”
listvgbackup -l “$FILE” > /dev/null 2>&1
RC=$?
elif [[ “$FILE” == *.tar ]]; then
echo ” – Verifying tar archive:” >> “$REPORT_FILE”
tar -tf “$FILE” > /dev/null 2>&1
RC=$?
else
echo ” – Unknown file type, skipping verification” >> “$REPORT_FILE”
continue
fi
if [ $RC -eq 0 ]; then
echo ” – Integrity check PASSED” >> “$REPORT_FILE”
else
echo ” – Integrity check FAILED” >> “$REPORT_FILE”
FAILURE_COUNT=$((FAILURE_COUNT + 1))
fi
done
echo “\nSummary: Checked $(echo “$BACKUP_FILES” | wc -w) files, found $FAILURE_COUNT issues.” >> “$REPORT_FILE”
if [ $FAILURE_COUNT -gt 0 ]; then
cat “$REPORT_FILE” | mail -s “Backup Verification – $FAILURE_COUNT issues found” “$MAIL_RECIPIENT”
exit 1
else
cat “$REPORT_FILE” | mail -s “Backup Verification PASSED” “$MAIL_RECIPIENT”
exit 0
fi
Para extrair informações sobre o tamanho e a duração do backup para testes adicionais, podemos usar a seguinte adição ao script:
grep “Backup size:” /var/log/backup*.log | awk ‘{print $1,$4}’ > backup_sizes.txt
grep “Duration:” /var/log/backup*.log | awk ‘{print $1,$3}’ > backup_durations.txt
Até mesmo os testes de restauração podem ser automatizados, restaurando partes dos backups para verificar sua usabilidade funcional e integridade regularmente:
mkdir -p /tmp/restore_test
tar -xvf /backup/latest.tar -C /tmp/restore_test ./path/to/test/file
Restauração de dados de backups do AIX
Não importa quão complexa e intrincada seja a estratégia de backup se ela não for combinada com um recurso de restauração igualmente eficaz. Os procedimentos de recuperação precisam de tanta atenção quanto as operações de backup, pois geralmente ocorrem durante interrupções críticas do sistema ou outras situações fora do padrão. Um bom entendimento de todas as diferentes nuances das práticas de restauração deve ajudar a administração a manter a integridade dos dados e minimizar o tempo de inatividade quando ocorrerem falhas ou problemas inevitáveis.
Restauração completa do backup do sistema com o mksysb
O utilitário mksysb pode ser usado para criar backups completos do sistema e, ao mesmo tempo, oferecer a base para a restauração bare-metal no futuro. Dessa forma, todo um ambiente AIX pode ser reconstruído do zero para restaurar os arquivos do sistema e os arquivos de aplicativos ou dados do usuário.
A restauração começa com a inicialização do AIX usando a mídia de instalação, seja ela uma mídia física ou uma fonte de rede. Uma vez no menu de instalação, devemos selecionar a opção “Install from a System Backup ” (Instalar a partir de um backup do sistema ) e, em seguida, especificar a imagem mksysb que será usada.
Veja como o local da imagem deve ser especificado:
- O dispositivo apropriado é inserido quando os backups são baseados em fita:
- Se a restauração for baseada em rede, ela terá de usar o NIM:
- Se um armazenamento local ou anexado hospedar a imagem:
Depois que a imagem mksysb é escolhida, o processo de restauração pode começar. Os elementos mais comuns desse tipo de processo incluem:
- Recriar a estrutura do volume lógico original usando metadados armazenados como linha de base.
- Reformatação do FS existente de acordo com os parâmetros de backup.
- Extração de todos os arquivos da imagem e restauração dos mesmos no local de destino.
- Configuração de registros de inicialização para tornar o sistema recém-restaurado inicializável.
- Usar as configurações de dispositivos e os parâmetros de sistema do backup.
É importante mencionar que as restaurações do mksysb sobrescrevem o grupo de volumes rootvg do sistema de destino, com todos os dados anteriores sendo destruídos no processo. No entanto, isso não tem tanto efeito em sistemas com vários grupos de volumes, pois afeta apenas o rootvg. Outros grupos de volumes teriam de ser restaurados separadamente usando procedimentos diferentes.
Depois que o sistema for completamente restaurado, não custa nada verificar a integridade do sistema com uma combinação de verificação de registro de erros e teste de funcionalidade crítica:
# lsvg -l rootvg
Recuperação de dados de backups de grupos de volumes
Se a falha que precisa ser corrigida afetar apenas grupos de volumes específicos em vez de um ambiente inteiro, a restauração direcionada poderá ser uma alternativa melhor com a ajuda do restvg. Esse é um utilitário que pode reconstruir grupos de volumes usando backups do savevg sem a necessidade de reinstalar o sistema do zero.
Um comando básico para restaurar um grupo de volumes a partir de um arquivo de backup tem a seguinte aparência:
Outros parâmetros potencialmente úteis que poderiam ser configurados de maneira semelhante incluem:
- Direcionamento seletivo de disco que direciona volumes lógicos específicos para serem restaurados em ambientes físicos específicos.
- Otimização de espaço para controlar os padrões de alocação de partição física.
- Modo de verificação que substitui o processo de restauração por uma imitação de visualização.
# fsck -y /dev/datavg/lv01
Extração de arquivos de backups tar ou cpio
A restauração em nível de arquivo é a opção mais granular das três, pois permite que os administradores recuperem arquivos muito específicos sem interromper o ambiente geral. É a melhor maneira de lidar com corrupção de arquivos, exclusão acidental ou outros casos de recuperação seletiva de dados.
Nosso primeiro comando é usado para extrair informações específicas de um arquivo tar:
# tar -xvf /backups/app_config.tar ./opt/application/config/settings.xml
# cpio -idv ./opt/application/config/settings.xml < /backups/app_backup.cpio
Quando os scripts ou arquivos de configuração são extraídos, não seria uma má ideia preservar cuidadosamente os atributos críticos do arquivo:
Práticas recomendadas para tarefas de backup e processos de recuperação do AIX
A diferença entre uma estratégia de backup funcional e uma resiliente geralmente fica evidente ao observar todos os detalhes que são tratados durante a implementação. A maioria das práticas recomendadas da comunidade AIX é resultado de anos e anos de experiência coletiva que são usados para evitar uma infinidade de problemas diferentes em ambientes atuais e futuros.
Testes regulares de backup
É de conhecimento geral que um backup não testado é tão útil quanto um backup inexistente. Os testes regulares de restauração comprovam que o backup pode ser usado caso algo aconteça, transformando uma proteção teórica em um recurso prático. Não é de se surpreender que esses processos de teste geralmente revelem problemas que poderiam ter sido esquecidos ou não detectados.
Deve-se observar, no entanto, que o teste em si não é apenas um processo binário único. Na verdade, a melhor abordagem possível para o teste utiliza várias abordagens de teste diferentes, inclusive:
- A verificação de metadados é uma confirmação básica de que os arquivos de backup têm a mesma estrutura das informações originais:
# listvgbackup -l /backups/datavg.savevg
- A amostragem de conteúdo é um processo de verificação um pouco mais avançado que extrai arquivos representativos e verifica sua integridade individualmente:
# tar -xvf /backups/app_backup.tar -C /tmp/test_restore ./path/to/critical/file
# diff /path/to/critical/file /tmp/test_restore/path/to/critical/file
- O teste funcional é o padrão ouro de fato da verificação de dados, pois ele restaura e tenta usar os dados em um ambiente isolado (mas também precisa de sistemas de teste dedicados ou partições lógicas para evitar que qualquer um dos processos de verificação afete a produção):
- A verificação em nível de aplicativo só é aplicável a ambientes de banco de dados e verifica a presença de arquivos e a usabilidade dos dados:
# db2 connect to SAMPLE
# db2 “select count(*) from critical_table”
Um processo de verificação adequado não deve ser considerado concluído até que se confirme que todos os arquivos estão presentes, que as permissões de arquivo correspondem aos requisitos, que os aplicativos funcionam conforme necessário e que as métricas de desempenho estão dentro dos limites aceitáveis.
Rotação de mídia de backup para segurança máxima
As estratégias de rotação de mídia são um passo além do agendamento básico. Elas representam uma proteção com profundidade de tempo contra muitos cenários de falha, equilibrando as restrições de armazenamento e os períodos de retenção e, ao mesmo tempo, protegendo as informações contra muitos problemas possíveis.
A estrutura mais típica de rotação de backup é geralmente chamada de Grandfather-Father-Son (avô-pai-filho). Ela inclui
- Backups completos mensais para fins de retenção de longo prazo (Grandfathers)
- Backups semanais para fornecer pontos de recuperação consolidados (Fathers)
- Backups diários para capturar alterações incrementais (Sons)
Além da rotação básica do método de backup, algumas empresas também usam a diversificação de mídia para reduzir os riscos específicos da tecnologia, mantendo backups em diferentes tipos de armazenamento. A separação geográfica, por outro lado, é recomendada para proteger contra desastres específicos do local…
Documentação do procedimento de backup
Os processos de documentação são uma necessidade, pois transformam o conhecimento pessoal de uma pessoa ou de uma equipe em um recurso organizacional que pode ser usado para a transferência de conhecimento. A documentação eficaz abrange várias dimensões ao mesmo tempo:
- A documentação de procedimentos é a captura direta de todos os processos de backup e recuperação, passo a passo.
- A documentação de configuração deve preservar vários parâmetros críticos do sistema que um usuário pode precisar durante uma sequência de recuperação.
- O mapeamento de dependências é usado para identificar as relações entre aplicativos e sistemas que podem influenciar o sequenciamento da recuperação.
A documentação em si também deve ser armazenada em vários locais, incluindo a mídia de backup, o formato de cópia impressa, em sistemas separados e em repositórios na nuvem.
Desafios conhecidos e suas soluções em backups AIX
Até mesmo a estratégia de backup mais detalhada pode encontrar um obstáculo mais cedo ou mais tarde – seja uma limitação técnica, uma restrição de recursos, etc. Entretanto, conhecer os problemas mais comuns e saber como resolvê-los deve ajudar os administradores a manter a confiabilidade das operações de backup e recuperação a longo prazo.
Limitações de espaço de armazenamento para backups
As restrições de armazenamento são surpreendentemente comuns nos backups do AIX, pois os volumes de dados crescem e os requisitos de armazenamento de backup precisarão corresponder a eles mais cedo ou mais tarde. Esse problema, por si só, pode se manifestar em arquivos truncados e trabalhos de backup com falha, o que cria um nível inadequado de proteção para o ambiente.
Normalmente, recomenda-se começar a tomar várias medidas quando o espaço disponível cai para menos de 10-15%. A etapa mais óbvia seria tentar limpar os arquivos de backup obsoletos, mas se essa opção não ajudar, também podemos tentar algumas abordagens mais complexas:
- Implementar backups diferenciais e incrementais.
- Aplicar a compactação de dados.
- Aproveitar os recursos de deduplicação.
- Usar estratégias de armazenamento em camadas, quando aplicável.
- Criar um ambiente de gerenciamento de ciclo de vida automatizado que use hierarquias de armazenamento para gerenciar o espaço por conta própria.
Diagnóstico e solução de falhas de backup
Pode haver muitos problemas que explicam por que um backup pode falhar. Pode ser uma simples restrição de recursos ou uma complexa interação de software. A chave para a eficácia está sempre em uma sequência sistemática de diagnóstico, seguida de uma resolução direcionada.
Uma análise detalhada do erro é sempre uma boa ideia para começar quando ocorre um erro:
# tail -100 /var/log/backup.log
- Erros de E/S durante as operações de backup que geralmente apontam para problemas subjacentes no disco.
- Falhas na alocação de memória que são resolvidas com o aumento da memória disponível por meio do encerramento do processo ou do ajuste do espaço de paginação.
- Timeouts de rede que exigem um teste completo da taxa de transferência da rede para identificar gargalos e restrições.
- A contenção de bloqueios é um problema para backups que precisam ser executados em sistemas de arquivos ativos e geralmente é resolvida com o uso de tecnologias de instantâneos.
Além de todas as soluções técnicas direcionadas, também é recomendável usar uma abordagem sistemática para o monitoramento de backup que possa detectar falhas e alertar os usuários relevantes sobre elas.
Se algumas falhas de backup persistirem, talvez seja hora de adotar uma solução mais permanente, como escalonar as programações de backup para liberar mais recursos, entre outras medidas.
Problemas de compatibilidade de dispositivos de backup
A compatibilidade de hardware e software pode ser um problema em um ambiente AIX complexo, especialmente se houver diversas pilhas de tecnologia em vigor. Por exemplo, a compatibilidade da unidade de fita geralmente é resultado da interação de um hardware mais antigo com uma versão mais recente do AIX que não é mais compatível com ele.
Como alternativa, também temos desafios de compatibilidade de armazenamento de rede que exigem a verificação adequada de todos os protocolos usados no processo de backup ou recuperação. As limitações de tamanho de arquivo podem parecer coisa do passado, mas ainda aparecem em muitas situações e sistemas de arquivos (e a única solução na maioria dos casos é usar um sistema que suporte tamanhos de arquivo maiores).
Os proxies de backup são recomendados para muitos ambientes com problemas persistentes de compatibilidade. Eles são sistemas dedicados configurados especificamente para operações de backup, preenchendo possíveis lacunas de compatibilidade entre uma infraestrutura de backup e os servidores de produção.
Software de backup AIX de terceiros
Embora as ferramentas nativas do AIX ofereçam um nível respeitável de recursos de backup, a maioria dos ambientes corporativos precisa de muitos outros recursos – agendamento avançado, gerenciamento centralizado, suporte a várias plataformas e muito mais. É nesse ponto que surgem as soluções de terceiros, que ampliam os recursos existentes do AIX com seus próprios conjuntos de recursos. Aqui, escolhemos três soluções de backup diferentes com suporte para AIX e agora tentaremos explicar como elas podem ser benéficas para as empresas nessa esfera.
Veeam
A ampla gama de tecnologias e ambientes suportados pela Veeam também inclui o AIX (usando um agente especializado projetado para ambientes UNIX). Alguns dos exemplos mais comuns dos recursos da Veeam aqui são:
- Backup em nível de arquivo
- Backup consistente com aplicativos
- Arquitetura de backup incremental para sempre
- Gerenciamento centralizado
A Veeam é mais valiosa quando usada em data centers heterogêneos que operam sistemas AIX juntamente com muitas outras plataformas, necessitando de um gerenciamento unificado com uma sobrecarga administrativa reduzida.
Bacula Enterprise
O Bacula Enterprise é uma solução de backup e recuperação excepcionalmente segura que possui um módulo dedicado para ambientes AIX com foco na otimização do desempenho e na confiabilidade de nível empresarial. Os principais recursos do Bacula em ambientes AIX incluem:
- Reconhecimento do grupo de volumes
- Tecnologia de backup VIO progressivo
- Operações de backup altamente simultâneas
- Opções de recuperação bare-metal
A arquitetura modular do Bacula pode ajudar os administradores do AIX a selecionar apenas os componentes necessários em seu ambiente atual, reduzindo drasticamente a sobrecarga administrativa sem a degradação da segurança dos dados.
Commvault
O Commvault Complete Data Protection tem uma variedade de recursos e ambientes suportados, incluindo o AIX. Isso é possível graças ao uso de agentes criados para fins específicos que podem se integrar profundamente aos componentes AIX existentes, fornecendo os seguintes recursos:
- Integração mksysb
- Tecnologia IntelliSnap
- Recuperação automatizada de desastres
- Arquitetura de backup de vários fluxos
- Opções de camadas de nuvem
A maior vantagem da Commvault em ambientes AIX e similares é a capacidade abrangente de gerenciamento do ciclo de vida dos dados, que vai além das operações de backup e recuperação e oferece conformidade, análise, retenção de longo prazo etc.
Conclusão
As estratégias de backup AIX exigem a combinação de visão estratégica e precisão técnica. A arquitetura exclusiva dos sistemas AIX pode ser vantajosa e extremamente desafiadora para se trabalhar do ponto de vista da proteção de dados. A obtenção de domínio no trabalho com o AIX pode transformar as operações de backup em um ativo organizacional genuíno, em vez de uma sobrecarga administrativa necessária.
É importante lembrar que as abordagens mencionadas neste guia não são apenas procedimentos teóricos, mas sim metodologias comprovadas que foram repetidas, refinadas e, usando a experiência coletiva de inúmeros ambientes de produção. Como resultado, podemos concluir que o ambiente AIX mais eficaz é aquele que combina utilitários nativos com software de terceiros apropriado, documentação abrangente e verificação automatizada, quando aplicável. Essa abordagem complexa garante que cada problema futuro possa ser enfrentado com confiança e um plano, em vez de pânico.
Devemos mencionar novamente que qualquer estratégia de backup bem-sucedida também requer atenção contínua com testes regulares, revisões periódicas e aprimoramentos contínuos para atender aos ambientes de negócios em constante mudança. O backup nunca é um projeto a ser concluído, mas uma disciplina inteira a ser mantida e aprimorada ao longo do tempo, afetando diretamente a resiliência organizacional em um mundo cada vez mais dependente de informações.
Perguntas frequentes
Os backups do AIX podem ser executados em um sistema ativo?
Embora seja verdade que o AIX tem suporte para backups on-line para a maioria das operações, há algumas ressalvas importantes que devem ser observadas. A maioria dos backups granulares com tar, cpio e outros utilitários de backup deve funcionar bem durante as operações normais do sistema, mas pode não funcionar para arquivos que estão sendo modificados ativamente. Os backups de grupos de volumes pelo savevg também devem funcionar bem, mas a consistência do banco de dados exigiria etapas adicionais: desativar as operações do banco de dados, usar utilitários específicos do banco de dados etc. Os backups completos do sistema são possíveis, mas podem introduzir perdas substanciais de desempenho no processo de backup.
Quais são as melhores ferramentas para monitorar o desempenho do backup no AIX?
Uma ferramenta interna do AIX chamada topas é a melhor solução integrada para o monitoramento do desempenho em tempo real durante as operações de backup, e há também o nmon que fornece coleta de dados para análise de tendências. Além disso, o AIX Performance Toolbox pode capturar métricas detalhadas sobre o hardware durante as janelas de backup para processamento posterior. Há também muitas ferramentas de terceiros com recursos semelhantes ou melhores, mas elas raramente são necessárias fora dos ambientes corporativos mais complexos e multifacetados.
Qual é a melhor maneira de migrar os backups do AIX para o armazenamento em nuvem?
Tecnicamente falando, a maneira mais eficiente de migrar backups do AIX é aproveitar as ferramentas de linha de comando em um sistema AIX para transferir informações diretamente para o AWS, o Azure ou o Google Cloud, uma vez que todos os três têm um comando CLI dedicado (esses ambientes devem ser instalados e configurados adequadamente com antecedência):
Posso agendar vários tipos de backup simultaneamente?
Embora deva ser possível agendar e executar vários processos de backup do AIX ao mesmo tempo, esse tipo de abordagem inevitavelmente cria uma contenção de recursos que certamente degradará o desempenho da maioria dos ambientes, tornando esses planos menos do que ideais na maioria dos casos.
O que precisa ser feito se a mídia de backup do AIX for corrompida?
É necessária uma abordagem de recuperação sistemática ao lidar com mídia de backup AIX corrompida. A primeira etapa deve ser sempre avaliar a extensão do dano usando uma das ferramentas de verificação mencionadas acima. A próxima etapa ainda dependerá da natureza da corrupção. Se a corrupção for parcial, os utilitários especializados poderão recuperar alguns elementos legíveis usando algoritmos avançados. Se dados críticos de backup forem afetados, é altamente recomendável consultar o suporte da IBM ou um especialista em recuperação de dados antes de tentar qualquer tipo de operação de recuperação ou comando do sistema.
