Contents
- Sauvegarde AIX : les bases
- Définition de la sauvegarde AIX
- Terminologies clés dans AIX
- Types de sauvegarde applicables à AIX
- La méthode de sauvegarde AIX la plus appropriée dans une situation spécifique
- Commande mksysb pour les sauvegardes système
- Commande savevg pour les sauvegardes de groupes de volumes
- Sauvegardes personnalisées à l’aide de tar, cpio et dd
- Guide étape par étape pour la réalisation de sauvegardes AIX
- Préparation du système AIX pour la sauvegarde
- Créer une sauvegarde complète du système avec mksysb
- Sauvegarder des groupes de volumes à l’aide de savevg
- Création de sauvegardes personnalisées avec tar
- Automatisation des sauvegardes AIX pour plus d’efficacité
- Utilisation de tâches cron pour planifier les sauvegardes
- Génération de scripts de sauvegarde pour les tâches répétitives
- Analyser et vérifier automatiquement les sauvegardes
- Restauration des données à partir des sauvegardes AIX
- Restauration complète de la sauvegarde du système avec mksysb
- Récupération des données à partir des sauvegardes des groupes de volumes
- Extraction de fichiers à partir de sauvegardes tar ou cpio
- Meilleures pratiques pour les tâches de sauvegarde et les processus de récupération sous AIX
- Tests réguliers de sauvegarde
- Rotation des supports de sauvegarde pour une sécurité maximale
- Documentation de la procédure de sauvegarde
- Défis connus et leurs solutions dans les sauvegardes AIX
- Limitations de l’espace de stockage pour les sauvegardes
- Diagnostiquer et résoudre les échecs de sauvegarde
- Problèmes de compatibilité des périphériques de sauvegarde
- Logiciels tiers de sauvegarde AIX
- Veeam
- Bacula Enterprise
- Commvault
- Conclusion
- Foire aux questions
- Les sauvegardes AIX peuvent-elles être effectuées sur un système actif ?
- Quels sont les meilleurs outils pour surveiller les performances de sauvegarde sous AIX ?
- Quelle est la meilleure façon de migrer les sauvegardes AIX vers le stockage dans le cloud ?
- Puis-je planifier plusieurs types de sauvegarde simultanément ?
- Que faut-il faire si le support de sauvegarde AIX est corrompu ?
En matière d’informatique d’entreprise, les systèmes AIX jouent encore un rôle très important dans un large éventail de tâches ou d’opérations critiques. Ces environnements UNIX robustes nécessitent également des stratégies de sauvegarde tout aussi flexibles afin d’assurer la continuité des activités et de protéger les informations sensibles de l’organisation. La sécurisation de l’ensemble de l’infrastructure AIX est un impératif commercial et pas seulement une exigence technique.
L’infrastructure AIX présente également plusieurs défis spécifiques qui la distinguent d’autres cibles de sauvegarde potentielles. Ces nuances doivent toujours être prises en compte lors de la conception d’une stratégie de sauvegarde. Notre objectif dans cet article est de créer un guide détaillé et complet pour la gestion des sauvegardes AIX, comprenant des concepts fondamentaux, des techniques avancées, des approches éprouvées, des stratégies d’automatisation et enfin quelques exemples de nos solutions de sauvegarde recommandées pour une utilisation dans de tels scénarios.
Sauvegarde AIX : les bases
Une bonne compréhension du « comment » et du « pourquoi » des opérations critiques est la base d’une administration système efficace. Les stratégies de sauvegarde AIX reposent en grande partie sur les outils propriétaires d’IBM, associés à des utilitaires standard, ce qui les différencie considérablement de la plupart des approches de sauvegarde dans d’autres distributions Linux ou variantes d’UNIX.
Définition de la sauvegarde AIX
La sauvegarde AIX est un ensemble complexe de technologies et de processus dont le seul objectif est de créer une copie restaurable des informations système ainsi que de toutes ses applications et configurations. AIX utilise un système complexe de gestion des volumes logiques qui nécessite une approche non conventionnelle des tâches de sauvegarde et de restauration pour garantir que tous ces processus sont menés efficacement.
La nécessité de créer des solutions de sauvegarde aussi robustes pour les environnements AIX est née de plusieurs facteurs. Les plus sensibles des charges de travail dans les institutions financières, les prestataires de soins de santé et les opérations de fabrication reposent souvent sur AIX, et incidemment, ces industries sont aussi généralement les plus sensibles en matière de disponibilité des infrastructures. Une seule heure d’indisponibilité du système peut coûter à une telle organisation plus d’un million de dollars.
Outre les considérations financières, il y a aussi l’important sujet de la conformité réglementaire. De nombreux cadres de conformité tels que PCI-DSS, SOX ou HIPAA imposent des protocoles de sauvegarde très spécifiques concernant les informations sensibles. De nombreuses autres mesures de protection des données sont également mentionnées dans le contexte de ces réglementations, les systèmes AIX étant souvent le principal support de stockage des informations considérées comme sensibles ou importantes.
Enfin, il est important de considérer que les sauvegardes AIX constituent la toute dernière ligne de défense contre tout type de cybermenace. Les attaques par ransomware visant les systèmes d’entreprise sont monnaie courante depuis plusieurs années, de nombreux acteurs malveillants créant des logiciels malveillants dans le but de cibler les systèmes de sauvegarde en plus du stockage d’informations standard. Une stratégie de sauvegarde AIX correctement planifiée et exécutée est la meilleure approche pour lutter contre des attaques aussi complexes.
Terminologies clés dans AIX
Les opérations de sauvegarde AIX s’articulent souvent autour de concepts et de termes spécifiques qui constituent le vocabulaire de base de la sécurité de l’information :
- mksysb est un utilitaire capable de créer des images système amorçables qui contiennent l’intégralité des groupes de volumes rootvg et du système d’exploitation. Ces images peuvent être utilisées à la fois comme outil de déploiement du système et comme mesure de reprise après sinistre.
- Le groupe de volumes rootvg est l’emplacement de stockage du système d’exploitation (et rien d’autre puisque les groupes de volumes définis par l’utilisateur sont censés héberger les données des applications dans de telles situations).
- savevg est une commande qui cible les groupes de volumes en dehors de rootvg afin de mener des opérations de sauvegarde complexes qui incluent également les données utilisateur et pas seulement le système d’exploitation.
- JFS et JFS2 sont tous deux des systèmes de fichiers avec journalisation des transactions qui sont capables de maintenir la cohérence du système de fichiers à tout moment ; ils peuvent également influencer la manière dont les sauvegardes interagissent avec les informations en cours d’utilisation.
- EMG sont des groupes de montage améliorés qui permettent de réaliser des sauvegardes cohérentes de plusieurs environnements à la fois.
- NIM est le gestionnaire d’installation réseau chargé de simplifier et de centraliser de nombreuses tâches de gestion des sauvegardes.
- TSM est un gestionnaire de stockage Tivoli, un outil important pour maintenir la cohérence des sauvegardes entre différents systèmes de fichiers.
- Les opérations de clonage permettent de dupliquer des groupes de volumes entiers à des fins de sauvegarde.
Types de sauvegarde applicables à AIX
Les sauvegardes AIX peuvent s’effectuer selon quatre méthodologies principales. Les sauvegardes complètes utilisent l’un des outils ci-dessus pour capturer l’intégralité du système d’exploitation avec toutes ses applications et ses fichiers de configuration. Elles nécessitent un espace de stockage et un temps de traitement importants, mais peuvent permettre une restauration complète du système après presque tout problème.
Les sauvegardes de groupes de volumes se concentrent sur des ensembles de données spécifiques au sein du système de gestion des volumes logiques d’AIX. Elles peuvent optimiser l’utilisation des ressources tout en offrant un certain degré de granularité aux processus de sauvegarde.
Les sauvegardes incrémentales et différentielles peuvent minimiser les frais généraux car elles ne peuvent capturer que les changements effectués depuis la sauvegarde précédente. Ces stratégies peuvent réduire considérablement les fenêtres de sauvegarde, mais rendent les tâches de restauration beaucoup plus complexes en comparaison.
Les sauvegardes au niveau des fichiers utilisent une idée similaire à leur philosophie de sauvegarde, en fournissant un contrôle granulaire sur les données qui peuvent être protégées à l’aide d’outils standard tels que cpio, tar, etc.
La mise en œuvre stratégique d’un ou plusieurs de ces types de sauvegarde peut être utilisée pour former un cadre de protection des données à plusieurs niveaux qui équilibre les performances du système et les contraintes de ressources avec la complexité de la protection des données.
La méthode de sauvegarde AIX la plus appropriée dans une situation spécifique
Maintenant que nous avons le contexte des différentes approches des opérations de sauvegarde, il est temps d’examiner la meilleure façon de les appliquer dans différentes situations.
De nombreux facteurs importants doivent être pris en compte lors de la création d’une méthodologie de sauvegarde complexe : contraintes de la fenêtre de sauvegarde, complexité opérationnelle, objectifs de temps de récupération, limitations de stockage, etc. Heureusement, les utilitaires natifs d’AIX peuvent être utilisés dans différents scénarios de protection et présentent également leurs propres avantages dans certains cas.
Certaines commandes ou indicateurs peuvent varier en fonction de la version d’AIX utilisée. Nous vous recommandons de consulter la documentation officielle de votre version spécifique d’AIX pour connaître les commandes prises en charge.
Commande mksysb pour les sauvegardes système
Comme mentionné précédemment, mksysb crée une sauvegarde complète et amorçable de l’intégralité du système d’exploitation AIX avec tout son contenu (dans le groupe de volumes rootvg). Une telle sauvegarde peut être utilisée pour reconstruire un environnement entier à partir de zéro si nécessaire.
Le processus complet de création d’une sauvegarde mksysb peut être divisé en plusieurs phases. Tout d’abord, il crée un fichier ./bosinst.data qui contient tous les détails de la configuration de l’installation. Ensuite, il crée une table des matières pour tous les fichiers rootvg avant de les archiver. Même l’emplacement de l’image en question peut être modifié, en la dirigeant vers d’autres fichiers, des emplacements réseau, des lecteurs de bande séparés, etc.
Il faut également tenir compte du fait que mksysb suit la logique des sauvegardes complètes régulières : elles prennent du temps à s’exécuter et nécessitent un espace de stockage important, ce qui les rend peu pratiques pour une utilisation fréquente. Ainsi, la plupart des entreprises ont tendance à n’utiliser mksysb qu’occasionnellement (sur une base hebdomadaire ou mensuelle), tout en effectuant des sauvegardes plus fréquentes (incrémentielles ou différentielles), afin de trouver un équilibre entre l’impact opérationnel et la sécurité des informations.
Commande savevg pour les sauvegardes de groupes de volumes
Quant aux informations stockées en dehors du groupe de volumes rootvg, elles peuvent être sauvegardées à l’aide d’une commande appelée savevg. Il s’agit d’un utilitaire qui cible des groupes de volumes spécifiques contenant des données d’application, des fichiers de base de données et des informations utilisateur, offrant un contrôle beaucoup plus granulaire sur les cibles de sauvegarde.
La syntaxe générale de savevg est presque identique à celle utilisée pour mksysb, la différence majeure étant l’emplacement des groupes de volumes cibles :
Une telle approche présente des avantages, notamment la sécurité ciblée des ensembles de données, la réduction de la fenêtre de sauvegarde et la possibilité d’être effectuée sans affecter les opérations du système. Encore une fois, un environnement AIX fonctionnel reste une condition nécessaire à la restauration de toute sauvegarde savevg, ce qui nécessite l’utilisation des deux options dans la même stratégie de sauvegarde.
Sauvegardes personnalisées à l’aide de tar, cpio et dd
Les outils UNIX standard peuvent également être utilisés comme outils de sauvegarde dans certains cas d’utilisation lorsque les utilitaires spécifiques à AIX ne sont pas à la hauteur de la tâche. Certains de ces outils peuvent offrir un degré substantiel de contrôle granulaire sur les opérations de sauvegarde en combinaison avec une compatibilité multiplateforme.
Par exemple, la célèbre commande tar est un excellent moyen de créer des sauvegardes de jeux de fichiers ou de répertoires spécifiques, et sa syntaxe est relativement simple :
Guide étape par étape pour la réalisation de sauvegardes AIX
La réalisation de sauvegardes efficaces dans les environnements AIX nécessite une exécution méthodique et une préparation minutieuse à plusieurs niveaux. Dans cette section, nous allons essayer de décomposer le processus d’approche des sauvegardes de différentes manières. Toutes les étapes sont testées sur le terrain et équilibrées de manière spécifique pour offrir efficacité et rigueur, en veillant à ce que les systèmes critiques restent sûrs et sécurisés sans complexité inutile.
Préparation du système AIX pour la sauvegarde
Avant de lancer une opération de sauvegarde, il est nécessaire de préparer correctement le système afin d’améliorer la fiabilité des sauvegardes et les taux de réussite des restaurations ultérieures. Nous aimerions ici aborder quelques points importants :
- Vérifier la stabilité du système en contrôlant les journaux d’erreurs pour détecter les problèmes potentiels susceptibles de compromettre l’intégrité de la sauvegarde :
- Trouver et résoudre toutes les erreurs critiques tout en s’assurant qu’il y a suffisamment d’espace libre dans le système de fichiers où les images de sauvegarde vont être stockées :
- Mettre à jour le gestionnaire de données d’objets pour s’assurer qu’il peut capturer tous les détails de la configuration actuelle du système (en particulier pour les opérations mksysb) :
- Nettoyez les fichiers inutiles tels que les vidages de mémoire, les fichiers temporaires ou les journaux :
# find /tmp -type f -mtime +3 -exec rm {} \;
- Vérifiez que tous les périphériques de sauvegarde sont accessibles et correctement configurés. Par exemple, l’accessibilité du lecteur de bande est vérifiée comme suit :
- Déterminez si les sauvegardes cohérentes avec les applications nécessitent un arrêt complet du service ou s’il existe une option fournie par le fournisseur pour garantir l’intégrité des données (si les systèmes de base de données sont sauvegardés). De nombreux environnements de bases de données d’entreprise populaires proposent leurs propres mécanismes de sauvegarde qui devraient également être utilisés dans les processus de sauvegarde AIX, le cas échéant.
Ces préparatifs pourraient contribuer à transformer un processus mécanique en une opération stratégique bien pensée, avec les meilleures options de protection des données disponibles.
Créer une sauvegarde complète du système avec mksysb
L’utilitaire mksysb est un bon moyen de créer une sauvegarde complète et cohérente du système pour l’environnement AIX. La syntaxe d’origine est assez simple, et il existe même plusieurs options et personnalisations différentes pour améliorer le résultat final.
Par exemple, nous pouvons commencer par créer un fichier image de sauvegarde au lieu d’écrire directement la sauvegarde à un emplacement cible, ce qui offre une certaine flexibilité dans les processus de vérification ultérieurs :
Afin de capturer les fichiers qui ne sont pas inclus dans la sauvegarde par défaut, il faut au préalable modifier la liste d’exclusion, ce qui est possible avec la commande suivante :
Sauvegarder des groupes de volumes à l’aide de savevg
Les groupes de volumes de données contiennent souvent certaines des informations les plus précieuses d’une entreprise, ce qui rend leur protection primordiale. La commande savevg est censée offrir la capacité de sauvegarde ciblée qui complète les sauvegardes au niveau du système dont nous avons parlé plus haut.
Une partie de la syntaxe de mksysb s’applique également ici, comme la possibilité de sauvegarder un groupe de volumes sous forme de fichier :
savevg -i /backup/${VG}_$(date +%Y%m%d).savevg $VG
done
Création de sauvegardes personnalisées avec tar
Si nous envisageons la possibilité de sauvegarder des fichiers ou des répertoires spécifiques plutôt que des groupes de volumes entiers, nous pouvons utiliser tar. Il peut gérer un large éventail de sauvegardes qui ne peuvent pas être effectuées par mksysb ou savevg avec le même niveau d’efficacité.
La sauvegarde de base d’un répertoire avec tar peut ressembler à ceci :
# touch /backup/tar_timestamp
Automatisation des sauvegardes AIX pour plus d’efficacité
Dans un environnement moderne, les processus de sauvegarde manuels sont la cause de risques inutiles en raison de la possibilité d’erreur humaine ou d’exécution incohérente. L’automatisation est la solution à ces problèmes, transformant les sauvegardes de tâches individuelles en un cadre de protection complexe. Les environnements AIX eux-mêmes disposent d’un large éventail de capacités d’automatisation capables de créer des processus de sauvegarde fiables et cohérents, lorsqu’ils sont correctement configurés.
Utilisation de tâches cron pour planifier les sauvegardes
La fonctionnalité cron peut servir de base à la planification des sauvegardes sous AIX, offrant un contrôle précis des opérations récurrentes. Au lieu de compter sur les administrateurs pour exécuter manuellement chaque séquence de commandes, cron peut assurer la cohérence des processus de sauvegarde selon des calendriers prédéfinis.
Notre première étape consisterait à définir les autorisations correctes pour le futur fichier de script de sauvegarde :
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
Si une entreprise a besoin d’une planification centralisée sur plusieurs environnements AIX à la fois, le Network Installation Manager peut être plus adapté à ces fins. NIM peut aider les administrateurs à définir une fois pour toutes des politiques de sauvegarde, puis à les appliquer de manière cohérente à l’ensemble de l’infrastructure.
Génération de scripts de sauvegarde pour les tâches répétitives
Une automatisation efficace de la sauvegarde utilise des scripts bien structurés capables de gérer l’opération de sauvegarde et toutes les étapes importantes qui l’entourent : préparation, vérification et nettoyage. La création d’un tel script de sauvegarde transforme une sélection de commandes disjointes en un flux de travail complet capable d’améliorer considérablement la fiabilité des processus de sauvegarde.
Une sauvegarde mksysb de base devrait ressembler à ceci :
# 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
Si un script de sauvegarde est créé pour des environnements avec plusieurs groupes de volumes, il est toujours possible de le personnaliser pour inclure tous les processus de sauvegarde nécessaires :
# 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 « $@ »
Ces trois exemples devraient donner à la plupart des utilisateurs un bon aperçu de la façon dont le développement de scripts évolue, de l’exécution de commandes de base à la création de workflows complexes avec toutes les options de gestion des erreurs, de journalisation et de conception modulaire nécessaires.
Analyser et vérifier automatiquement les sauvegardes
Il est logique de penser que les sauvegardes automatisées devraient également être dotées de processus de surveillance et de vérification automatisés. Cependant, l’automatisation des processus peut créer une dangereuse illusion de normalité lorsqu’il n’y a pas de confirmation réelle de leur succès.
Un script de vérification de base devrait au moins pouvoir vérifier la taille de la sauvegarde et le fait qu’elle existe même pour commencer :
# 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
Afin d’extraire des informations sur la taille et la durée des sauvegardes pour des tests ultérieurs, nous pouvons utiliser l’ajout suivant au 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
Même les tests de restauration peuvent être automatisés, en restaurant régulièrement des portions de sauvegardes pour vérifier leur fonctionnalité et leur intégrité :
mkdir -p /tmp/restore_test
tar -xvf /backup/latest.tar -C /tmp/restore_test ./path/to/test/file
Restauration des données à partir des sauvegardes AIX
La stratégie de sauvegarde n’a que peu d’importance si elle n’est pas associée à une capacité de restauration tout aussi efficace. Les procédures de récupération nécessitent autant d’attention que les opérations de sauvegarde, car elles se produisent généralement lors de pannes système critiques ou d’autres situations inhabituelles. Une bonne compréhension des différentes pratiques de restauration devrait aider l’administration à maintenir l’intégrité des données et à minimiser les temps d’arrêt lorsque des pannes ou des problèmes surviennent inévitablement.
Restauration complète de la sauvegarde du système avec mksysb
L’utilitaire mksysb peut être utilisé pour créer des sauvegardes complètes du système tout en offrant la base d’une restauration complète à l’avenir. De cette façon, un environnement AIX entier peut être reconstruit à partir de zéro afin de restaurer à la fois les fichiers système et les fichiers d’application ou les données utilisateur.
La restauration commence par le démarrage d’AIX à l’aide du support d’installation, qu’il s’agisse d’un support physique ou d’une source réseau. Une fois dans le menu d’installation, nous cherchons à sélectionner l’option « Installer à partir d’une sauvegarde système », après quoi nous devrons spécifier l’image mksysb qui va être utilisée.
Voici comment l’emplacement de l’image doit être spécifié :
- Le périphérique approprié est entré lorsque les sauvegardes sont sur bande :
- Si la restauration est basée sur le réseau, il faudrait utiliser NIM :
- Si un stockage local ou connecté héberge l’image :
Une fois l’image mksysb choisie, le processus de restauration peut commencer. Les éléments les plus typiques de ce type de processus sont les suivants :
- Recréer la structure de volume logique d’origine en utilisant les métadonnées stockées comme base de référence.
- Reformater le système de fichiers existant en fonction des paramètres de sauvegarde.
- Extraire tous les fichiers de l’image et les restaurer à l’emplacement cible.
- Configurer les enregistrements de démarrage afin de rendre le système nouvellement restauré amorçable.
- Utilisation des configurations de périphériques et des paramètres système sauvegardés.
Il est important de mentionner que les restaurations mksysb écrasent le groupe de volumes rootvg du système cible, toutes les données précédentes étant détruites au cours du processus. Cependant, cela n’a pas autant d’effet sur les systèmes avec plusieurs groupes de volumes puisque cela n’affecte que le rootvg. Les autres groupes de volumes devraient être restaurés séparément en utilisant des procédures différentes.
Une fois le système entièrement restauré, il est toujours utile de vérifier l’intégrité du système en vérifiant le journal des erreurs et en testant les fonctionnalités critiques :
# lsvg -l rootvg
Récupération des données à partir des sauvegardes des groupes de volumes
Si la panne à corriger n’affecte que des groupes de volumes spécifiques au lieu de tout un environnement, une restauration ciblée peut être une meilleure alternative en utilisant l’aide de restvg. Il s’agit d’un utilitaire qui peut reconstruire des groupes de volumes à l’aide de sauvegardes savevg sans qu’il soit nécessaire de réinstaller le système à partir de zéro.
Une commande de base pour restaurer un groupe de volumes à partir d’un fichier de sauvegarde ressemble à ce qui suit :
D’autres paramètres potentiellement utiles qui pourraient être configurés de manière similaire comprennent :
- Le ciblage sélectif des disques qui oriente des volumes logiques spécifiques à restaurer dans des environnements physiques spécifiques.
- Optimisation de l’espace pour contrôler les modèles d’allocation des partitions physiques.
- Mode de vérification qui remplace le processus de restauration par une imitation de prévisualisation.
# fsck -y /dev/datavg/lv01
Extraction de fichiers à partir de sauvegardes tar ou cpio
La restauration au niveau des fichiers est l’option la plus granulaire des trois. Elle permet aux administrateurs de récupérer des fichiers très spécifiques sans perturber l’environnement global. C’est le meilleur moyen de corriger la corruption de fichiers, la suppression accidentelle ou d’autres cas de récupération sélective de données.
Notre première commande est utilisée pour extraire des informations spécifiques d’une archive tar. : # cd /
# tar -xvf /backups/app_config.tar ./opt/application/config/settings.xml[/dt_code]Cependant, cette commande n’extrait qu’un fichier spécifique tout en conservant son chemin d’accès d’origine. S’il est nécessaire de définir une destination différente, nous pouvons utiliser cette commande :
# cpio -idv ./opt/application/config/settings.xml < /backups/app_backup.cpio
Lorsque des scripts ou des fichiers de configuration sont extraits, il est conseillé de conserver soigneusement les attributs des fichiers critiques :
Meilleures pratiques pour les tâches de sauvegarde et les processus de récupération sous AIX
La différence entre une stratégie de sauvegarde fonctionnelle et une stratégie résiliente est souvent évidente en observant tous les détails qui sont pris en compte lors de la mise en œuvre. La plupart des meilleures pratiques de la communauté AIX sont le résultat d’années d’expérience collective qui sont utilisées pour prévenir une multitude de problèmes différents dans les environnements actuels et futurs.
Tests réguliers de sauvegarde
Il est largement admis qu’une sauvegarde non testée est à peu près aussi utile qu’une sauvegarde inexistante. Des tests de restauration réguliers prouvent que la sauvegarde peut être utilisée en cas d’incident, transformant ainsi une protection théorique en une fonctionnalité pratique. Sans surprise, ces processus de test révèlent souvent des problèmes qui auraient pu être manqués ou oubliés.
Il convient toutefois de noter que le test lui-même n’est pas un processus binaire unique. En fait, la meilleure approche possible en matière de test utilise plusieurs approches différentes, notamment :
- La vérification des métadonnées est une confirmation de base que les archives de sauvegarde ont la même structure que les informations d’origine :
# listvgbackup -l /backups/datavg.savevg
- L’échantillonnage de contenu est un processus de vérification légèrement plus avancé qui extrait des fichiers représentatifs et vérifie leur intégrité individuellement :
# 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
- Les tests fonctionnels sont la référence en matière de vérification des données. Ils restaurent et tentent d’utiliser les données dans un environnement isolé (mais nécessitent également des systèmes de test dédiés ou des partitions logiques pour éviter que les processus de vérification n’affectent la production) :
- La vérification au niveau des applications ne s’applique qu’aux environnements de base de données. Elle vérifie à la fois la présence des fichiers et l’utilisabilité des données :
# db2 connect to SAMPLE
# db2 « select count(*) from critical_table »
Un processus de vérification approprié ne doit pas être considéré comme complet tant qu’il n’a pas confirmé que tous les fichiers sont présents, que les autorisations de fichiers correspondent aux exigences, que les applications fonctionnent comme prévu et que les mesures de performance se situent dans des limites acceptables.
Rotation des supports de sauvegarde pour une sécurité maximale
Les stratégies de rotation des supports sont un cran au-dessus de la planification de base. Elles représentent une protection temporelle contre de nombreux scénarios de défaillance, en trouvant un équilibre entre les contraintes de stockage et les périodes de conservation tout en sécurisant les informations contre de nombreux problèmes possibles.
La structure la plus courante pour la rotation des sauvegardes est souvent appelée Grand-père-Père-Fils. Elle comprend
- Des sauvegardes complètes chaque mois à des fins de conservation à long terme (Grand-pères)
- Des sauvegardes chaque semaine pour fournir des points de récupération consolidés (Pères)
- Des sauvegardes chaque jour pour capturer les changements incrémentiels (Fils)
Outre la méthode de sauvegarde de base par rotation, certaines entreprises utilisent également la diversification des supports afin de réduire les risques spécifiques à la technologie en conservant des sauvegardes sur différents types de stockage. La séparation géographique, quant à elle, est recommandée pour se protéger contre les catastrophes spécifiques à un site.
Documentation de la procédure de sauvegarde
Les processus de documentation sont une nécessité, ils transforment les connaissances personnelles d’une personne ou d’une équipe en une capacité organisationnelle qui peut être utilisée pour le transfert des connaissances. Une documentation efficace couvre plusieurs dimensions à la fois :
- La documentation des procédures est la capture directe de tous les processus pour la sauvegarde et la récupération, étape par étape.
- La documentation de configuration doit préserver divers paramètres système critiques dont un utilisateur pourrait avoir besoin lors d’une séquence de récupération.
- La cartographie des dépendances est utilisée pour identifier les relations entre les applications et les systèmes qui pourraient influencer le séquencement de la récupération.
La documentation elle-même doit également être stockée à plusieurs endroits, y compris sur le support de sauvegarde, sur papier, sur des systèmes séparés et dans des référentiels cloud.
Défis connus et leurs solutions dans les sauvegardes AIX
Même la stratégie de sauvegarde la plus détaillée peut rencontrer un obstacle tôt ou tard, qu’il s’agisse d’une limitation technique, d’une contrainte de ressources, etc. Cependant, connaître les problèmes les plus courants et savoir comment les résoudre devrait aider les administrateurs à maintenir la fiabilité des opérations de sauvegarde et de restauration à long terme.
Limitations de l’espace de stockage pour les sauvegardes
Les contraintes de stockage sont étonnamment courantes dans les sauvegardes AIX, car les volumes de données augmentent et les besoins de stockage des sauvegardes devront tôt ou tard s’y adapter. Ce problème peut à lui seul se traduire par des archives tronquées et des tâches de sauvegarde ayant échoué, ce qui crée un niveau de protection inadéquat pour l’environnement.
Il est généralement recommandé de prendre diverses mesures lorsque l’espace disponible tombe en dessous de 10 à 15 %. La mesure la plus évidente serait d’essayer de supprimer les fichiers de sauvegarde obsolètes, mais si cette option n’aide pas, nous pouvons également essayer des approches plus complexes :
- Mettre en œuvre des sauvegardes différentielles et incrémentielles.
- Appliquer la compression des données.
- Tirer parti des capacités de déduplication.
- Utiliser des stratégies de stockage à plusieurs niveaux, le cas échéant.
- Créer un environnement de gestion automatisée du cycle de vie qui utilise des hiérarchies de stockage pour gérer l’espace de manière autonome.
Diagnostiquer et résoudre les échecs de sauvegarde
Les raisons d’un échec de sauvegarde peuvent être nombreuses. Il peut s’agir d’une simple contrainte de ressources ou d’une interaction logicielle complexe. La clé de l’efficacité réside toujours dans une séquence de diagnostic systématique, suivie d’une résolution ciblée.
Une analyse détaillée de l’erreur est toujours une bonne idée au début lorsqu’une erreur se produit :
# tail -100 /var/log/backup.log
- Des erreurs d’E/S pendant les opérations de sauvegarde qui indiquent souvent des problèmes de disque sous-jacents.
- Des échecs d’allocation de mémoire qui sont résolus en augmentant la mémoire disponible par l’arrêt du processus ou l’ajustement de l’espace de pagination.
- Les dépassements de délai du réseau nécessitent un test approfondi du débit du réseau pour identifier les goulots d’étranglement et les contraintes.
- Les conflits de verrouillage sont un problème pour les sauvegardes qui doivent être effectuées sur des systèmes de fichiers actifs et sont souvent résolus à l’aide de technologies de snapshot.
Outre toutes les solutions techniques ciblées, il est également recommandé d’utiliser une approche systématique de la surveillance des sauvegardes qui permet de détecter les défaillances et d’alerter les utilisateurs concernés.
Si certaines défaillances de sauvegarde persistent, il est peut-être temps d’envisager une solution plus permanente, comme l’échelonnement des calendriers de sauvegarde afin de libérer davantage de ressources, entre autres mesures.
Problèmes de compatibilité des périphériques de sauvegarde
La compatibilité matérielle et logicielle peut poser problème dans un environnement AIX complexe, surtout si plusieurs technologies sont utilisées. Par exemple, la compatibilité des lecteurs de bandes est généralement le résultat d’une interaction entre un matériel plus ancien et une version plus récente d’AIX qui ne le prend plus en charge.
Par ailleurs, nous sommes également confrontés à des problèmes de compatibilité du stockage réseau qui nécessitent une vérification appropriée de tous les protocoles utilisés dans le processus de sauvegarde ou de récupération. Les limites de taille des fichiers peuvent sembler appartenir au passé, mais elles apparaissent encore dans de nombreuses situations et systèmes de fichiers (et la seule solution dans la plupart des cas est d’utiliser un système qui prend en charge des fichiers de plus grande taille).
Les proxys de sauvegarde sont recommandés pour de nombreux environnements présentant des problèmes de compatibilité persistants. Il s’agit de systèmes dédiés, configurés spécifiquement pour les opérations de sauvegarde, qui comblent les écarts de compatibilité potentiels entre une infrastructure de sauvegarde et les serveurs de production.
Logiciels tiers de sauvegarde AIX
Même si les outils AIX natifs offrent un niveau respectable de capacités de sauvegarde, la plupart des environnements d’entreprise nécessitent de nombreuses autres fonctionnalités : planification avancée, gestion centralisée, support multi-plateforme, etc. C’est là qu’interviennent les solutions tierces, qui étendent les capacités existantes d’AIX avec leurs propres fonctionnalités. Nous avons choisi ici trois solutions de sauvegarde différentes avec support AIX et allons maintenant essayer d’expliquer en quoi elles peuvent être bénéfiques aux entreprises dans ce domaine.
Veeam
La vaste gamme de technologies et d’environnements pris en charge par Veeam inclut également AIX (à l’aide d’un agent spécialisé conçu pour les environnements UNIX). Voici quelques-unes des capacités les plus courantes de Veeam dans ce domaine :
- Sauvegarde au niveau des fichiers
- Sauvegarde cohérente des applications
- Architecture de sauvegarde incrémentielle permanente
- Gestion centralisée
Veeam est particulièrement utile lorsqu’il est utilisé dans des data centers hétérogènes qui exploitent des systèmes AIX parallèlement à de nombreuses autres plates-formes, nécessitant une gestion unifiée avec une surcharge administrative réduite.
Bacula Enterprise
Bacula Enterprise est une solution de sauvegarde et de restauration exceptionnellement sécurisée qui dispose d’un module dédié aux environnements AIX, axé sur l’optimisation des performances et la fiabilité de niveau entreprise. Les principales fonctionnalités de Bacula dans les environnements AIX sont les suivantes :
- Prise en compte des groupes de volumes
- Technologie de sauvegarde progressive VIO
- Opérations de sauvegarde hautement simultanées
- Options de restauration à froid
L’architecture modulaire de Bacula permet aux administrateurs AIX de ne sélectionner que les composants dont ils ont besoin dans leur environnement actuel, ce qui réduit considérablement la charge administrative sans compromettre la sécurité des données.
Commvault
Commvault Complete Data Protection offre une variété de fonctionnalités et prend en charge de nombreux environnements, y compris AIX. Pour ce faire, il est possible d’utiliser des agents spécialement conçus qui peuvent s’intégrer en profondeur aux composants AIX existants, offrant les fonctionnalités suivantes :
- Intégration mksysb Technologie IntelliSnap
- Reprise après sinistre automatisée
- Architecture de sauvegarde multi-flux
- Architecture de sauvegarde multi-flux
- Options de hiérarchisation dans le cloud
Le plus grand avantage de Commvault dans AIX et les environnements similaires est la capacité complète de gestion du cycle de vie des données qui s’étend au-delà des opérations de sauvegarde et de restauration pour offrir la conformité, l’analyse, la conservation à long terme, etc.
Conclusion
Les stratégies de sauvegarde AIX nécessitent à la fois une vision stratégique et une précision technique. L’architecture unique des systèmes AIX peut être à la fois avantageuse et extrêmement difficile à utiliser du point de vue de la protection des données. Maîtriser AIX peut transformer les opérations de sauvegarde en un véritable atout organisationnel plutôt qu’en une charge administrative nécessaire.
Il est important de se rappeler que les approches mentionnées dans ce guide ne sont pas seulement des procédures théoriques, mais des méthodologies éprouvées qui ont été répétées et affinées, en utilisant l’expérience collective d’innombrables environnements de production. En conséquence, nous pouvons conclure que l’environnement AIX le plus efficace est celui qui combine des utilitaires natifs avec des logiciels tiers appropriés, une documentation complète et une vérification automatisée le cas échéant. Une approche aussi complexe garantit que chaque problème futur peut être résolu avec confiance et un plan plutôt que dans la panique.
Il convient de rappeler que toute stratégie de sauvegarde efficace nécessite également une attention constante, avec des tests réguliers, des révisions périodiques et des améliorations continues pour s’adapter à des environnements commerciaux en constante évolution. La sauvegarde n’est jamais un projet à achever, mais une discipline à entretenir et à améliorer au fil du temps, qui a un impact direct sur la résilience organisationnelle dans un monde de plus en plus dépendant de l’information.
Foire aux questions
Les sauvegardes AIX peuvent-elles être effectuées sur un système actif ?
S’il est vrai qu’AIX prend en charge les sauvegardes en ligne pour la plupart des opérations, il convient de garder à l’esprit quelques mises en garde importantes. La plupart des sauvegardes granulaires avec tar, cpio et d’autres utilitaires de sauvegarde devraient fonctionner correctement pendant les opérations normales du système, mais elles pourraient ne pas fonctionner pour les fichiers qui sont activement modifiés. Les sauvegardes de groupes de volumes par savevg devraient également fonctionner correctement, mais la cohérence de la base de données nécessiterait des étapes supplémentaires : mise en veille des opérations de la base de données, utilisation d’utilitaires spécifiques à la base de données, etc. Les sauvegardes complètes du système sont possibles, mais elles peuvent entraîner des pertes de performances importantes lors du processus de sauvegarde.
Quels sont les meilleurs outils pour surveiller les performances de sauvegarde sous AIX ?
Un outil interne à AIX appelé topas est la meilleure solution intégrée pour le suivi des performances en temps réel pendant les opérations de sauvegarde. Il existe également nmon, qui permet de collecter des données pour l’analyse des tendances. De plus, la boîte à outils de performance AIX peut capturer des mesures détaillées sur le matériel pendant les fenêtres de sauvegarde pour un traitement ultérieur. Il existe également de nombreux outils tiers dotés de capacités similaires ou supérieures, mais ils sont rarement nécessaires en dehors des environnements d’entreprise plus complexes et multiformes.
Quelle est la meilleure façon de migrer les sauvegardes AIX vers le stockage dans le cloud ?
Techniquement parlant, le moyen le plus efficace de migrer les sauvegardes AIX consiste à utiliser les outils en ligne de commande d’un système AIX pour transférer les informations directement vers AWS, Azure ou Google Cloud, car ces trois environnements disposent d’une commande CLI dédiée (ils doivent être installés et configurés correctement au préalable) :
Puis-je planifier plusieurs types de sauvegarde simultanément ?
Bien qu’il soit possible de planifier et d’exécuter plusieurs processus de sauvegarde AIX à la fois, ce type d’approche crée inévitablement une contention des ressources qui ne manquera pas de dégrader les performances de la plupart des environnements, rendant de tels plans peu idéaux dans la plupart des cas.
Que faut-il faire si le support de sauvegarde AIX est corrompu ?
Une approche systématique de la récupération est nécessaire pour traiter les supports de sauvegarde AIX corrompus. La première étape doit toujours consister à évaluer l’étendue des dommages à l’aide de l’un des outils de vérification mentionnés ci-dessus. L’étape suivante dépendra de la nature de la corruption. Si la corruption est partielle, des utilitaires spécialisés peuvent être en mesure de récupérer certains éléments lisibles à l’aide d’algorithmes avancés. Si des données de sauvegarde critiques sont affectées, il est fortement recommandé de consulter le support IBM ou un spécialiste de la récupération de données avant de tenter toute opération de récupération ou d’exécuter une commande système.