Bienvenue > Blog sur la sauvegarde et la restauration > Maîtriser la sauvegarde AIX : Guide complet pour les administrateurs système
Mis à jour 15th mars 2025, Rob Morrison

Contents

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.

# mksysb -i /dev/rmt0
Cette commande est utilisée pour créer une sauvegarde amorçable en utilisant le premier périphérique de bande comme emplacement de stockage. S’il est nécessaire d’enregistrer l’image dans l’environnement de stockage existant, l’utilisateur devra spécifier le chemin d’accès exact au fichier, au lieu de :
# mksysb -i /backups/system_backup.mksysb
Même si mksysb est un excellent moyen de protéger les fichiers système importants, il est loin d’être parfait. Par exemple, le fait qu’il se concentre sur le groupe de volumes rootvg introduit la possibilité de ne pas prendre en compte les données d’application stockées dans différents groupes de volumes.

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 :

# savevg -i /backups/appvg_backup.savevg appvg
Cette commande nous permet de créer une sauvegarde du groupe de volumes « appvg » et de l’enregistrer dans un fichier désigné. Contrairement à mksysb, les sauvegardes savevg ne sont pas amorçables par défaut, car leur objectif principal est la conservation générale des données et elles ne contiennent pas les fichiers du système d’exploitation nécessaires pour fonctionner seules.

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 :

# tar -cvf /backups/app_config.tar /opt/application/config
Si une plus grande compatibilité avec diverses architectures système est nécessaire, cpio peut être utilisé à la place :
# find /home -print | cpio -ocvB > /backups/home_backup.cpio
Lorsqu’il est nécessaire d’effectuer des opérations au niveau des blocs (création d’images disque exactes ou sauvegarde de périphériques bruts), la commande dd peut fournir l’ensemble d’outils nécessaire :
# dd if=/dev/hdisk1 of=/backups/hdisk1.img bs=512k
S’il est vrai que ces utilitaires sont loin d’être aussi complexes ou personnalisables que mksysb, ils sont presque inégalés en termes de flexibilité pour les scénarios de sauvegarde granulaire. C’est pourquoi de nombreuses stratégies de sauvegarde complexes utilisent plusieurs mesures différentes à la fois, telles que des mesures spécifiques à AIX et des outils basés sur UNIX, afin de résoudre les problèmes spécifiques du plan de protection des données.

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 :
# errpt -a | more
  • 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 :
# df -g /backup
  • 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) :
# savebase -v
  • Nettoyez les fichiers inutiles tels que les vidages de mémoire, les fichiers temporaires ou les journaux :
# find /var/tmp -type f -mtime +7 -exec rm {} \;
# 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 :
# tctl -f /dev/rmt0 status
  • 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 :

# mksysb -i /backup/$(hostname)_$(date +%Y%m%d).mksysb
Dans la commande ci-dessus, nous avons donné au fichier de sauvegarde un nom facilement reconnaissable en utilisant la combinaison du nom d’hôte et de la date du jour. L’image de sauvegarde elle-même est créée à l’aide de l’indicateur -i.

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 :

# vi /etc/exclude.rootvg
Une fois que toutes les entrées que vous souhaitez inclure dans la sauvegarde ont été supprimées de ce fichier, une nouvelle commande mksysb peut être exécutée avec l’indicateur -e qui spécifie la liste d’exclusion nouvellement mise à jour :
# mksysb -e /etc/modified_exclude.rootvg -i /backup/full_$(hostname).mksysb
Si une sauvegarde AIX doit être effectuée dans un environnement avec des fenêtres de temps d’arrêt strictes, l’indicateur -P peut être utilisé pour prévisualiser le processus afin d’estimer sa durée et sa taille à l’avance :
# mksysb -P
La vérification est une autre étape importante dans ce cas ; elle doit être effectuée chaque fois qu’une nouvelle image mksysb est générée pour tester son exhaustivité :
# lsmksysb -l /backup/system.mksysb
La commande ci-dessus doit lister tout le contenu de la sauvegarde, ce qui aide les utilisateurs à confirmer qu’elle contient tous les fichiers et la structure nécessaires.

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/datavg_$(date +%Y%m%d).savevg datavg
Si l’environnement comporte plusieurs groupes de volumes à protéger, il est possible de le faire en créant une simple boucle comme celle-ci :
# for VG in datavg appvg dbvg; do
savevg -i /backup/${VG}_$(date +%Y%m%d).savevg $VG
done
Si certains volumes logiques nécessitent des règles de traitement inhabituelles, les listes d’exclusion fonctionnent bien ici, comme dans l’exemple présenté dans la section mksysb :
# savevg -e /etc/exclude.$VG -i /backup/$VG.savevg $VG
Lorsqu’il n’est pas nécessaire d’écrire les sauvegardes de groupes de volumes dans un fichier, elles peuvent être écrites directement sur le support de stockage, tel qu’une bande, à l’aide de l’indicateur -f :
# savevg -f /dev/rmt0 datavg
Les groupes de volumes plus volumineux peuvent également tirer parti de la capacité de compression intégrée au prix d’une charge CPU plus élevée pendant les processus de sauvegarde (le drapeau peut également ne pas être présent dans les versions antérieures d’AIX) :
# savevg -i /backup/datavg_compressed.savevg -Z datavg
Une fois l’opération savevg terminée, il est fortement recommandé de vérifier toutes les sauvegardes à l’aide des informations attendues sur le groupe de volumes analyse :
# listvgbackup -l /backup/datavg.savevg
La commande en question peut afficher les systèmes de fichiers, les volumes logiques et d’autres structures au sein de l’image de sauvegarde afin de vérifier son exhaustivité.

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 :

# tar -cvf /backup/app_config.tar /opt/application/config
L’ajout de la compression au processus réduirait les besoins de stockage sans perturber l’organisation des fichiers, mais pourrait entraîner une consommation plus élevée du processeur :
# tar -czvf /backup/logs_$(date +%Y%m%d).tar.gz /var/log/application
Il existe également des indicateurs dédiés pour les sauvegardes qui doivent préserver les attributs étendus et les listes de contrôle d’accès :
# tar -cvEf /backup/secure_data.gz /var/log/application
Il existe également des indicateurs dédiés aux sauvegardes qui doivent conserver les attributs étendus et les listes de contrôle d’accès :
# tar -cvEf /backup/secure_data.tar /secure/data
Cependant, tous ces exemples sont des sauvegardes complètes standard. S’il est nécessaire de commencer à créer des sauvegardes incrémentielles, le processus devient un peu plus complexe. Il commence par la création d’un horodatage de référence qui doit avoir lieu avant la sauvegarde elle-même :
# tar -cvf /backup/incremental.tar -N « $(cat /backup/tar_timestamp) » /data
# touch /backup/tar_timestamp
Bien sûr, une fois les sauvegardes terminées, une vérification d’intégrité s’impose. Elle peut être effectuée de la manière habituelle ou de manière plus détaillée. La première option (-tvf) est similaire à celle que nous avons examinée pour d’autres sauvegardes : elle répertorie tout le contenu de la sauvegarde, ce qui permet de vérifier manuellement les divergences :
# tar -tvf /backup/archive.tar
La deuxième option (-dvf) est beaucoup plus détaillée. Elle utilise les fichiers originaux du système de fichiers comme point de comparaison pour la sauvegarde en question et signale toute différence entre les deux, ce qui rend la comparaison beaucoup plus automatisée et détaillée :
# tar -dvf /backup/archive.tar
Les sauvegardes personnalisées avec un tel degré de granularité sont optimales lorsqu’elles sont utilisées en tandem avec des outils spécifiques à AIX pour une couverture plus complète des informations sensibles, permettant à la fois la récupération au niveau du système et la restauration granulaire des fichiers.

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 :

# chmod 700 /usr/local/bin/backup_script.sh
Ensuite, nous pouvons accéder au crontab et commencer à configurer les commandes et les horaires :
# crontab -e
Par exemple, si nous voulons que les sauvegardes complètes hebdomadaires soient effectuées tous les dimanches à 1h00 du matin, l’entrée crontab devrait ressembler à ceci :
0 1 * * 0 /usr/local/bin/backup_script.sh > /var/log/backup.log 2>&1
Bien sûr, il est toujours possible de créer des programmations plus complexes en utilisant la configuration flexible de cron. Par exemple, nous pouvons utiliser la ligne précédente et y ajouter d’autres sauvegardes avec des règles différentes :
# Full backup on Sundays at 1:00 AM
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

Nous utilisons également une commande pour rediriger la sortie vers des fichiers journaux ici (> /var/log/backup.log 2>&1) afin de capturer la sortie de sauvegarde standard et divers messages d’erreur en même temps. Une pratique de journalisation détaillée comme celle-ci peut offrir une visibilité approfondie sur divers processus automatisés qui s’exécutent généralement sans surveillance.

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 :

#!/bin/ksh
# 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

Comme vous pouvez le constater, ce script intègre la plupart des bonnes pratiques que nous avons passées en revue dans l’une des sections précédentes, avec un schéma de nommage dynamique, une journalisation complète, un nettoyage avant la sauvegarde, une gestion appropriée des erreurs, une vérification dédiée de l’intégrité de la sauvegarde, un nettoyage automatique des fichiers de sauvegarde anciens, etc.

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 :

#!/bin/ksh
# 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 »

D’une manière générale, les organisations qui ont des exigences complexes en matière de sauvegarde et de récupération devraient envisager de mettre en œuvre des fonctions pour différents processus afin d’améliorer la réutilisabilité du code et de réduire la taille totale de chaque script (pour une meilleure maintenabilité) :
#!/bin/ksh
# 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 « $@ »

Il convient de noter que ce script suppose automatiquement que backup_functions.sh et les fichiers de configuration sont créés et chargés au préalable.

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 :

#!/bin/ksh
# 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

Si un ensemble de processus plus avancé est nécessaire, il est également possible de mettre en œuvre des séquences d’analyse des tendances (suivi de divers paramètres dans le temps) et des systèmes de surveillance centralisés (intégration avec des solutions de surveillance d’entreprise telles que Zabbix, Nagios ou Tivoli).

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 :

# Extract backup size and duration from logs
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é :
# Restaurer un fichier test à partir de la sauvegarde la plus récente
mkdir -p /tmp/restore_test
tar -xvf /backup/latest.tar -C /tmp/restore_test ./path/to/test/file
Comme nous l’avons déjà mentionné, l’approche la plus efficace en matière de sauvegarde et de surveillance consiste à combiner plusieurs approches différentes afin de créer un cadre complet pour les processus de vérification, en confirmant fréquemment leur facilité d’utilisation et leur achèvement.

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 :
/dev/rmt0
  • Si la restauration est basée sur le réseau, il faudrait utiliser NIM :
nim_server:/exports/mksysb/system_backup.mksysb
  • Si un stockage local ou connecté héberge l’image :
/dev/hdisk1:/backups/system_backup.mksysb

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 :

  1. Recréer la structure de volume logique d’origine en utilisant les métadonnées stockées comme base de référence.
  2. Reformater le système de fichiers existant en fonction des paramètres de sauvegarde.
  3. Extraire tous les fichiers de l’image et les restaurer à l’emplacement cible.
  4. Configurer les enregistrements de démarrage afin de rendre le système nouvellement restauré amorçable.
  5. 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 :

# errpt -a | more
# 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 :

# restvg -f /backups/datavg.savevg
La configuration par défaut de restvg tente de recréer le groupe de volumes en utilisant son nom d’origine et d’autres caractéristiques. Cependant, ces paramètres peuvent être modifiés à volonté à l’aide de commandes spécifiques :
# restvg -f /backups/datavg.savevg -l hdisk1 datavg_new
Cette commande restaurerait le groupe de volumes sur un disque appelé hdisk1 en utilisant le nom « datavg_new ». Une telle approche configurable est idéale lorsqu’il est nécessaire d’éviter les conflits avec des groupes de volumes existants (ou lors de la restauration d’une sauvegarde sur un matériel différent).

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.
# restvg -f /backups/datavg.savevg -l hdisk1,hdisk2
  • Optimisation de l’espace pour contrôler les modèles d’allocation des partitions physiques.
# restvg -f /backups/datavg.savevg -b
  • Mode de vérification qui remplace le processus de restauration par une imitation de prévisualisation.

# restvg -f /backups/datavg.savevg -v
Comme dans l’exemple précédent, nous recommandons également de vérifier l’intégrité du groupe de volumes une fois le processus de restauration terminé :
# lsvg -l datavg
# 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 :

# tar -xvf /backups/app_config.tar -C /tmp ./opt/application/config/settings.xml
Si le chemin d’accès exact du fichier dans l’archive n’est pas clair, une alternative peut être de lister tout son contenu :
# tar -tvf /backups/app_config.tar | grep settings
Si nous travaillons avec des archives cpio, la syntaxe d’extraction va différer quelque peu :
# cd /
# cpio -idv ./opt/application/config/settings.xml < /backups/app_backup.cpio
Une restauration séquentielle est généralement nécessaire pour les sauvegardes incrémentales (commençant par une sauvegarde complète suivie de chaque sauvegarde incrémentale dans un ordre chronologique). Un processus séquentiel comme celui-ci est nécessaire pour garantir que l’état final des informations reflète toutes les modifications capturées lors de plusieurs opérations de sauvegarde.

Lorsque des scripts ou des fichiers de configuration sont extraits, il est conseillé de conserver soigneusement les attributs des fichiers critiques :

# tar -xpvf /backups/app_config.tar
L’indicateur « p » dans -xpvf est nécessaire pour conserver tous les droits de propriété, les horodatages et les autorisations d’origine des informations, ce qui est extrêmement important pour le fonctionnement de la plupart des fichiers système.

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 :
# lsmksysb -l /backups/latest.mksysb
# 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 :
# mkdir -p /tmp/test_restore
# 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) :
# nim -o bos_inst -a source=mksysb -a spot=spot_name -a mksysb=backup_name test_lpar
  • 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 restore db SAMPLE from /backups/db_backup
# 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 :

  1. La documentation des procédures est la capture directe de tous les processus pour la sauvegarde et la récupération, étape par étape.
  2. 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.
  3. 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 :

# errpt -a | grep -i backup
# tail -100 /var/log/backup.log
Les modèles de défaillance les plus courants dans les environnements AIX comprennent :

  1. Des erreurs d’E/S pendant les opérations de sauvegarde qui indiquent souvent des problèmes de disque sous-jacents.
  2. 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.
  3. 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.
  4. 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) :

# aws s3 cp /backup/system.mksysb s3://aix-backups/
Il devrait également être possible d’obtenir le même résultat avec la fonctionnalité de transfert de fichiers sécurisé d’AIX :
# scp /backup/datavg.savevg cloud-gateway:/remote/backups/
Les environnements et infrastructures plus complexes devraient mettre en œuvre des appliances de passerelle cloud pour présenter le stockage cloud en tant que NFS ou stockage objet afin de simplifier le transfert de données avec des moyens standard.

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.

À propos de l’auteur
Rob Morrison
Rob Morrison est le directeur marketing de Bacula Systems. Il a commencé sa carrière dans le marketing informatique chez Silicon Graphics en Suisse, où il a obtenu de bons résultats dans divers rôles de gestion du marketing pendant près de 10 ans. Au cours des 10 années suivantes, Rob a également occupé divers postes de gestion du marketing chez JBoss, Red Hat et Pentaho, assurant la croissance des parts de marché de ces sociétés bien connues. Il est diplômé de l'université de Plymouth, titulaire d'un diplôme spécialisé en médias et communications numériques, et a suivi un programme d'études à l'étranger.
Laissez un commentaire

Votre adresse email ne sera pas publiée. Les champs requis sont indiqués *