Home > Backup- und Wiederherstellungs-Blog > AIX-sicherung meistern: Umfassender Leitfaden für Systemadministratoren
Aktualisiert 14th März 2025, Rob Morrison

Contents

Wenn es um Unternehmens-Computing geht, sind AIX-Systeme nach wie vor für eine Vielzahl von unternehmenskritischen Aufgaben oder Vorgängen von großer Bedeutung. Solche robusten UNIX-basierten Umgebungen erfordern auch ebenso flexible Sicherungsstrategien, um die Geschäftskontinuität zu gewährleisten und sensible Informationen des Unternehmens zu schützen. Die Sicherung der gesamten AIX-Infrastruktur ist eine geschäftliche Notwendigkeit und nicht nur eine technische Anforderung.

Die AIX-Infrastruktur weist auch einige spezifische Herausforderungen auf, die sie von anderen potenziellen Sicherungszielen unterscheiden. Diese Nuancen sollten bei der Entwicklung einer Sicherungsstrategie immer berücksichtigt werden. Unser Ziel in diesem Artikel ist es, einen detaillierten Leitfaden für das AIX-Sicherungsmanagement aus einer Hand zu erstellen, der grundlegende Konzepte, fortgeschrittene Techniken, bewährte Ansätze, Automatisierungsstrategien und schließlich einige Beispiele für unsere empfohlenen Sicherungslösungen für den Einsatz in solchen Szenarien enthält.

AIX-Sicherung: Die Grundlagen

Ein klares Verständnis sowohl des „Wie“ als auch des „Warum“ hinter geschäftskritischen Vorgängen ist die Grundlage für ein effizientes Systemverwaltungskonzept. AIX-Sicherungsstrategien basieren in hohem Maße auf proprietären Tools von IBM in Kombination mit Standard-Dienstprogrammen, wodurch sie sich wesentlich von den meisten Sicherungsansätzen in anderen Linux-Distributionen oder UNIX-Varianten unterscheiden.

Definition der AIX-Sicherung

Die AIX-Sicherung ist ein komplexes Set von Technologien und Prozessen, die alle ein einziges Ziel haben: die Erstellung einer wiederherstellbaren Kopie von Systeminformationen zusammen mit allen Anwendungen und Konfigurationen. AIX verwendet ein komplexes logisches Volumenverwaltungssystem, das einen unkonventionellen Ansatz für Sicherungs- und Wiederherstellungsaufgaben erfordert, um sicherzustellen, dass alle diese Prozesse effizient ausgeführt werden.

Die Notwendigkeit, solch robuste Sicherungslösungen für AIX-Umgebungen zu schaffen, ergab sich aus einer Reihe von Faktoren. Die empfindlichsten Arbeitslasten in Finanzinstituten, Gesundheitsdienstleistern und Fertigungsbetrieben sind oft auf AIX angewiesen, und zufällig sind diese Branchen auch in der Regel am empfindlichsten, wenn es um die Verfügbarkeit der Infrastruktur geht. Schon eine einzige Stunde Systemausfall kann ein solches Unternehmen mehrere Millionen Dollar kosten.

Abgesehen von finanziellen Erwägungen gibt es auch das wichtige Thema der Einhaltung von Vorschriften. Zahlreiche Compliance-Rahmenwerke wie PCI-DSS, SOX oder HIPAA schreiben sehr spezifische Sicherungsprotokolle für sensible Informationen vor. Im Zusammenhang mit diesen Vorschriften werden auch viele andere Datenschutzmaßnahmen erwähnt, wobei AIX-Systeme häufig der primäre Speicher für genau die Informationen sind, die als sensibel oder anderweitig wichtig gelten.

Schließlich ist es wichtig zu bedenken, dass AIX-Sicherungen als letzte Verteidigungslinie gegen jede Art von Cyber-Bedrohung dienen. Ransomware-Angriffe, die auf Unternehmenssysteme abzielen, sind seit mehreren Jahren an der Tagesordnung, wobei viele Bedrohungsakteure Malware mit dem Ziel erstellen, neben der standardmäßigen Informationsspeicherung auch Sicherungssysteme ins Visier zu nehmen. Eine richtig geplante und durchgeführte AIX-Sicherungsstrategie ist der beste Ansatz, um solche komplexen Angriffe zu bekämpfen.

Schlüsselterminologien in AIX

Bei AIX-Sicherungen geht es oft um spezifische Konzepte und Begriffe, die das Grundvokabular der Informationssicherheit bilden:

  • mksysb ist ein Dienstprogramm, mit dem bootfähige Systemabbilder erstellt werden können, die die gesamten rootvg und Betriebssystem-Volume-Gruppen enthalten. Diese Abbilder können sowohl als Systembereitstellungswerkzeug als auch als Disaster-Recovery-Maßnahme eingesetzt werden.
  • Die rootvg Volume-Gruppe ist der Speicherort für das Betriebssystem (und nichts anderes, da benutzerdefinierte Volume-Gruppen in solchen Situationen Anwendungsdaten enthalten sollen).
  • savevg ist ein Befehl, der auf Volume-Gruppen außerhalb von rootvg abzielt, um komplexe Sicherungsvorgänge durchzuführen, die auch Benutzerdaten und nicht nur das Betriebssystem umfassen.
  • JFS und JFS2 sind beides Dateisysteme mit Transaktionsprotokollierung, die in der Lage sind, die Konsistenz des Dateisystems jederzeit aufrechtzuerhalten; sie können auch die Art und Weise beeinflussen, wie Sicherungen mit den verwendeten Informationen interagieren.
  • EMG sind erweiterte Mount-Gruppen, die konsistente Sicherungen mehrerer Umgebungen auf einmal ermöglichen.
  • NIM ist der Network Installation Manager, der viele Aufgaben der Sicherungsverwaltung vereinfacht und zentralisiert.
  • TSM ist ein Tivoli Storage Manager, ein wichtiges Tool zur Aufrechterhaltung der Sicherungskonsistenz über verschiedene Dateisysteme hinweg.
  • Clone Operations ermöglichen die Duplizierung ganzer Volume-Gruppen zu Sicherungszwecken.

Für AIX geeignete Sicherungsarten

AIX-Sicherungen können nach vier primären Methoden erfolgen. Vollständige Sicherungen verwenden eines der oben genannten Tools, um das gesamte Betriebssystem mit all seinen Anwendungen und Konfigurationsdateien zu erfassen. Sie erfordern viel Speicherplatz und Verarbeitungszeit, können aber nach fast jedem Problem eine vollständige Systemwiederherstellung ermöglichen.

Volumengruppen-Sicherungen konzentrieren sich auf bestimmte Datensätze innerhalb des logischen Volumenverwaltungssystems von AIX. Sie können die Ressourcennutzung optimieren und bieten gleichzeitig ein gewisses Maß an Granularität für Sicherungsprozesse.

Sowohl inkrementelle als auch differenzielle Sicherungen können den Overhead minimieren, da sie nur Änderungen seit der vorherigen Sicherung erfassen können. Diese Strategien können die Sicherungsfenster drastisch reduzieren, machen die Wiederherstellungsaufgaben im Vergleich dazu jedoch deutlich komplexer.

Sicherungen auf Dateiebene verfolgen eine ähnliche Idee wie ihre Sicherungsphilosophie und bieten eine granulare Kontrolle darüber, welche Daten mit Standardwerkzeugen wie cpio, tar usw. geschützt werden können.

Die strategische Implementierung einer oder mehrerer dieser Sicherungsarten kann zur Bildung eines abgestuften Datenschutzrahmens verwendet werden, der die Systemleistung und die Ressourcenbeschränkungen mit der Komplexität des Datenschutzes in Einklang bringt.

Die am besten geeignete AIX-Sicherungsmethode in einer bestimmten Situation

Nachdem wir nun den Kontext der verschiedenen Ansätze für Sicherungsvorgänge kennen, ist es an der Zeit, die beste Möglichkeit zu finden, sie in verschiedenen Situationen anzuwenden.

Bei der Erstellung einer komplexen Sicherungsmethode müssen viele wichtige Faktoren berücksichtigt werden: Einschränkungen des Sicherungsfensters, betriebliche Komplexität, Wiederherstellungszeitziele, Speicherbeschränkungen usw. Glücklicherweise können die nativen AIX-Dienstprogramme in verschiedenen Schutzszenarien eingesetzt werden und haben in einigen Fällen auch ihre eigenen Vorteile.

Bestimmte Befehle oder Flags können je nach verwendeter AIX-Version variieren. Wir empfehlen, in der offiziellen Dokumentation für Ihre spezifische AIX-Version nachzuschlagen, welche Befehle unterstützt werden.

mksysb Befehl für System-Backups

Wie bereits erwähnt, erstellt mksysb eine vollständige, bootfähige Sicherung des gesamten AIX-Betriebssystems mit all seinen Inhalten (in der rootvg-Volumengruppe). Eine solche Sicherung kann bei Bedarf verwendet werden, um eine gesamte Umgebung von Grund auf neu zu erstellen.

Der gesamte Prozess der Erstellung einer mksysb-Sicherung kann in mehrere Phasen unterteilt werden. Zunächst wird eine ./bosinst.data-Datei erstellt, die alle Details der Installationskonfiguration enthält. Zweitens wird ein Inhaltsverzeichnis für alle rootvg-Dateien erstellt, bevor diese archiviert werden. Sogar der Speicherort des betreffenden Images kann geändert werden, sodass es auf andere Dateien, Netzwerkordner, separate Bandlaufwerke usw. verweist.

# mksysb -i /dev/rmt0
Mit diesem Befehl wird eine bootfähige Sicherung erstellt, wobei das erste Bandlaufwerk als Speicherort verwendet wird. Wenn das Image in der vorhandenen Speicherumgebung gespeichert werden muss, muss ein Benutzer stattdessen den genauen Dateipfad angeben:
# mksysb -i /backups/system_backup.mksysb
Auch wenn mksysb eine hervorragende Möglichkeit zum Schutz wichtiger Systemdateien darstellt, ist es bei weitem nicht perfekt. Da es sich beispielsweise auf die rootvg-Volumengruppe konzentriert, besteht die Möglichkeit, dass Anwendungsdaten, die in anderen Volumengruppen gespeichert sind, nicht berücksichtigt werden.

Hinzu kommt, dass mksysb der Logik regelmäßiger vollständiger Sicherungen folgt – diese dauern eine Weile und benötigen viel Speicherplatz, was sie für den häufigen Gebrauch unpraktisch macht. Daher neigen die meisten Unternehmen dazu, mksysb nur gelegentlich (auf wöchentlicher oder monatlicher Basis) zu verwenden, während sie sie durch häufigere Sicherungen (inkrementell oder differenziell) unterstützen, um ein Gleichgewicht zwischen betrieblichen Auswirkungen und Informationssicherheit zu erreichen.

Befehl savevg für Volume-Group-Sicherungen

Die außerhalb der rootvg-Volume-Gruppe gespeicherten Informationen können mit dem Befehl savevg gesichert werden. Dieses Dienstprogramm ist auf bestimmte Volume-Gruppen mit Anwendungsdaten, Datenbankdateien und Benutzerinformationen ausgerichtet und bietet eine viel detailliertere Kontrolle über die Sicherungsziele.

Die allgemeine Syntax für savevg ist fast identisch mit der für mksysb, wobei der Speicherort der Ziel-Volume-Gruppen einer der größten Unterschiede ist:

# savevg -i /backups/appvg_backup.savevg appvg
Mit diesem Befehl können wir eine Sicherung der Volume-Gruppe „appvg“ erstellen und in einer dafür vorgesehenen Datei speichern. Im Gegensatz zu mksysb sind savevg-Sicherungen standardmäßig nicht bootfähig, da ihr Hauptzweck in der allgemeinen Datensicherung besteht und sie nicht die erforderlichen Betriebssystemdateien enthalten, um eigenständig zu funktionieren.

Ein solcher Ansatz hat seine eigenen Vorteile, darunter gezielte Datensicherheit, Verkleinerung des Sicherungsfensters und die Möglichkeit, ohne Beeinträchtigung des Systembetriebs durchgeführt zu werden. Andererseits ist eine funktionierende AIX-Umgebung nach wie vor eine Voraussetzung für die Wiederherstellung jeder savevg-Sicherung, sodass beide Optionen in derselben Sicherungsstrategie verwendet werden müssen.

Benutzerdefinierte Sicherungen mit tar, cpio und dd

In bestimmten Fällen können auch Standard-UNIX-Tools als Sicherungswerkzeuge verwendet werden, wenn AIX-spezifische Dienstprogramme der Aufgabe nicht gewachsen sind. Einige dieser Tools bieten in Kombination mit plattformübergreifender Kompatibilität ein hohes Maß an granularer Kontrolle über Sicherungsvorgänge.

Der bekannte Befehl tar eignet sich beispielsweise hervorragend zum Erstellen von Sicherungen bestimmter Dateisätze oder Verzeichnisse, und seine Syntax ist relativ einfach:

# tar -cvf /backups/app_config.tar /opt/application/config
Wenn eine größere Kompatibilität mit verschiedenen Systemarchitekturen erforderlich ist, kann stattdessen cpio verwendet werden:
# find /home -print | cpio -ocvB > /backups/home_backup.cpio
Wenn Operationen auf Blockebene erforderlich sind – z. B. das Erstellen exakter Festplatten-Images oder das Sichern von Rohgeräten – bietet der Befehl dd das erforderliche Toolset:
# dd if=/dev/hdisk1 of=/backups/hdisk1. img bs=512k
Diese Dienstprogramme sind zwar bei weitem nicht so komplex oder anpassbar wie mksysb, aber sie sind nahezu unübertroffen, wenn es um Flexibilität bei granularen Sicherungsszenarien geht. Aus diesem Grund werden bei vielen komplexen Sicherungsstrategien mehrere verschiedene Maßnahmen gleichzeitig eingesetzt, z. B. sowohl AIX-spezifische Maßnahmen als auch UNIX-basierte Tools, um spezifische Schwachstellen des Datenschutzplans zu beheben.

Schritt-für-Schritt-Anleitung zur Durchführung von AIX-Sicherungen

Die Durchführung effizienter Sicherungen in AIX-Umgebungen erfordert eine methodische Ausführung und sorgfältige Vorbereitung auf mehreren Ebenen. In diesem Abschnitt werden wir versuchen, den Prozess der Sicherungsansätze auf unterschiedliche Weise aufzuschlüsseln. Alle Schritte sind praxiserprobt und in einer bestimmten Weise ausgewogen, um Effizienz und Gründlichkeit zu gewährleisten und sicherzustellen, dass kritische Systeme ohne unnötige Komplexität sicher und geschützt bleiben.

Vorbereitung des AIX-Systems für die Sicherung

Bevor ein Sicherungsvorgang eingeleitet wird, muss eine ordnungsgemäße Systemvorbereitung durchgeführt werden, um die Zuverlässigkeit der Sicherungen und die Erfolgsraten nachfolgender Wiederherstellungen zu verbessern. Es gibt einige wichtige Punkte, die wir hier näher betrachten möchten:

  • Überprüfung der Systemstabilität durch Überprüfung der Fehlerprotokolle auf potenzielle Probleme, die die Integrität der Sicherung beeinträchtigen könnten:
# errpt -a | more
  • Suchen und beheben Sie alle kritischen Fehler und stellen Sie sicher, dass im Dateisystem, in dem die Sicherungsimages gespeichert werden sollen, genügend freier Speicherplatz vorhanden ist:
# df -g /backup
  • Aktualisieren Sie den Objektdatenmanager, um sicherzustellen, dass er alle aktuellen Systemkonfigurationsdetails erfassen kann (insbesondere für mksysb-Vorgänge):
# savebase -v
  • Bereinigen Sie unnötige Dateien wie Core-Dumps, temporäre Dateien oder Protokolle:
# find /var/tmp -type f -mtime +7 -exec rm {} \;
# find /tmp -type f -mtime +3 -exec rm {} \;
  • Überprüfen Sie, ob alle Sicherungsgeräte zugänglich und ordnungsgemäß konfiguriert sind. Die Zugänglichkeit des Bandlaufwerks wird beispielsweise wie folgt überprüft:
# tctl -f /dev/rmt0 status
  • Überlegen Sie, ob anwendungskonsistente Sicherungen einen vollständigen Dienststopp erfordern oder ob es eine vom Anbieter bereitgestellte Option gibt, um die Datenintegrität sicherzustellen (wenn die Datenbanksysteme gesichert werden). Viele gängige Datenbankumgebungen für Unternehmen bieten eigene Sicherungsmechanismen, die gegebenenfalls auch in AIX-Sicherungsprozessen verwendet werden sollten.

Diese Vorbereitungen können dazu beitragen, einen mechanischen Prozess in einen durchdachten strategischen Vorgang mit den besten verfügbaren Datenschutzoptionen umzuwandeln.

Erstellen einer vollständigen Systemsicherung mit mksysb

Das Dienstprogramm mksysb ist eine gute Möglichkeit, eine umfassende und konsistente Systemsicherung für die AIX-Umgebung zu erstellen. Die ursprüngliche Syntax ist unkompliziert und bietet sogar mehrere verschiedene Optionen und Anpassungsmöglichkeiten, um das Endergebnis zu verbessern.

Zum Beispiel können wir damit beginnen, eine Sicherungs-Image-Datei zu erstellen, anstatt die Sicherung direkt an einen Zielort zu schreiben, was Flexibilität bei nachfolgenden Verifizierungsprozessen bietet:

# mksysb -i /backup/$(hostname)_$(date +%Y%m%d).mksysb
Im obigen Befehl haben wir der Sicherungsdatei einen leicht erkennbaren Namen gegeben, indem wir die Kombination aus Hostname und aktuellem Datum verwendet haben. Das Sicherungsimage selbst wird mit der Option -i erstellt.

Um die Dateien zu erfassen, die nicht in der Standardsicherung enthalten sind, muss man die Ausschlussliste vorher bearbeiten. Dies ist mit folgendem Befehl möglich:

# vi /etc/exclude.rootvg
Nachdem alle Einträge, die in die Sicherung aufgenommen werden sollen, aus dieser Datei entfernt wurden, kann ein neuer mksysb-Befehl mit der Option -e ausgeführt werden, die die neu aktualisierte Ausschlussliste angibt:
# mksysb -e /etc/modified_exclude.rootvg -i /backup/full_$(hostname).mksysb
Wenn eine AIX-Sicherung in einer Umgebung mit strengen Zeitfenstern für Ausfallzeiten durchgeführt werden muss, kann die Option -P verwendet werden, um eine Vorschau des Prozesses anzuzeigen und dessen Dauer und Größe im Voraus abzuschätzen:
# mksysb -P
Die Überprüfung ist hier ein weiterer wichtiger Schritt. Sie sollte jedes Mal durchgeführt werden, wenn ein neues mksysb-Image erstellt wird, um dessen Vollständigkeit zu überprüfen:
# lsmksysb -l /backup/system.mksysb
Der obige Befehl sollte alle Inhalte der Sicherung auflisten und Benutzern helfen, zu bestätigen, dass sie alle erforderlichen Dateien und Strukturen enthält.

Datenträgergruppen mit savevg sichern

Datenträgergruppen enthalten oft einige der wertvollsten Informationen, die ein Unternehmen haben kann, weshalb ihr Schutz von größter Bedeutung ist. Der Befehl savevg soll die gezielte Sicherungsfunktion bieten, die die oben besprochenen Sicherungen auf Systemebene ergänzt.

Ein Teil der Syntax von mksysb gilt auch hier, z. B. die Möglichkeit, eine Datenträgergruppe als Datei zu sichern:

# savevg -i /backup/datavg_$(date +%Y%m%d).savevg datavg
Wenn in der Umgebung mehrere Datenträgergruppen vorhanden sind, die geschützt werden müssen, kann dies durch Erstellen einer einfachen Schleife wie folgt erfolgen:
# for VG in datavg appvg dbvg; do
savevg -i /backup/${VG}_$(date +%Y%m%d).savevg $VG
done
Wenn einige logische Datenträger ungewöhnliche Handhabungsregeln erfordern – Ausschlusslisten funktionieren hier gut, wie das Beispiel, das wir im Abschnitt mksysb vorgestellt haben:
# savevg -e /etc/exclude. $VG -i /backup/$VG.savevg $VG
Wenn es nicht notwendig ist, Sicherungen von Volume-Gruppen in eine Datei zu schreiben, können sie mit der Option -f direkt auf das Speichermedium geschrieben werden, z. B. auf ein Band:
# savevg -f /dev/rmt0 datavg
Bei größeren Volume-Gruppen kann auch die integrierte Komprimierungsfunktion genutzt werden, was jedoch zu einer höheren CPU-Auslastung während der Sicherung führt (die Option ist in früheren Versionen von AIX möglicherweise nicht verfügbar):
# savevg -i /backup/datavg_compressed. savevg -Z datavg
Nach Abschluss des Vorgangs savevg wird dringend empfohlen, alle Sicherungen mithilfe der erwarteten Analyse der Volume-Gruppeninformationen zu überprüfen:
# listvgbackup -l /backup/datavg.savevg
Mit dem betreffenden Befehl können Dateisysteme, logische Volumes und andere Strukturen innerhalb des Sicherungsimages angezeigt werden, um dessen Vollständigkeit zu überprüfen.

Erstellen benutzerdefinierter Sicherungen mit tar

Wenn wir die Möglichkeit in Betracht ziehen, dass bestimmte Dateien oder Verzeichnisse anstelle ganzer Volume-Gruppen gesichert werden müssen, können wir in solchen Fällen tar als Alternative verwenden, die Flexibilität und Präzision bietet. Es kann eine Vielzahl von Sicherungen verarbeiten, die von mksysb oder savevg nicht mit der gleichen Effizienz durchgeführt werden können.

Eine einfache Verzeichnissicherung mit tar kann wie folgt aussehen:

# tar -cvf /backup/app_config.tar /opt/application/config
Durch Hinzufügen einer Komprimierung zum Prozess würden die Speicheranforderungen reduziert, ohne die Dateiorganisation zu stören, was jedoch zu einem höheren CPU-Verbrauch führen könnte:
# tar -czvf /backup/logs_$(date +%Y%m%d).tar. gz /var/log/application
Es gibt auch spezielle Flags für Sicherungen, bei denen erweiterte Attribute und Zugriffssteuerungslisten beibehalten werden müssen:
# tar -cvEf /backup/secure_data.tar /secure/data
Bei all diesen Beispielen handelt es sich jedoch um Ihre standardmäßigen vollständigen Sicherungen. Wenn Sie mit der Erstellung von Sicherungen in inkrementellen Schritten beginnen möchten, wird der Prozess etwas komplexer. Er beginnt mit der Erstellung eines Referenzzeitstempels, der vor der Sicherung selbst erfolgen muss:
# touch /backup/tar_timestamp
# tar -cvf /backup/full_backup.tar /data
Der betreffende Zeitstempel wird dann für nachfolgende inkrementelle Sicherungen verwendet:
# tar -cvf /backup/incremental.tar -N „$(cat /backup/tar_timestamp)“ /data
# touch /backup/tar_timestamp
Nach Abschluss der Sicherungen ist natürlich eine Integritätsprüfung angebracht. Diese kann auf die übliche oder eine detailliertere Weise durchgeführt werden. Die erste Option (-tvf) ähnelt der, die wir für andere Sicherungen durchgegangen sind – sie listet den gesamten Inhalt der Sicherung auf und ermöglicht es, manuell nach Diskrepanzen zu suchen:
# tar -tvf /backup/archive.tar
Die zweite Option (-dvf) ist viel detaillierter, sie verwendet die Originaldateien im Dateisystem als Vergleichspunkt für die betreffende Sicherung und meldet alle Unterschiede zwischen den beiden, wodurch der Vergleich viel automatisierter und detaillierter wird:
# tar -dvf /backup/archive.tar
Benutzerdefinierte Sicherungen mit einem so hohen Grad an Granularität sind am besten, wenn sie in Kombination mit AIX-spezifischen Tools verwendet werden, um eine umfassendere Abdeckung sensibler Informationen zu gewährleisten, die sowohl die Wiederherstellung auf Systemebene als auch die granulare Wiederherstellung von Dateien abdecken.

AIX-Sicherungen: Automatisierung für mehr Effizienz

In modernen Umgebungen stellen manuelle Sicherungsprozesse unnötige Risiken dar, da sie fehleranfällig sind und inkonsistent ausgeführt werden können. Die Lösung für diese Probleme ist die Automatisierung, die Sicherungen von einzelnen Aufgaben in ein komplexes Schutzsystem verwandelt. AIX-Umgebungen selbst verfügen über eine Vielzahl von Automatisierungsfunktionen, die bei richtiger Konfiguration zuverlässige und konsistente Sicherungsprozesse ermöglichen.

Planung von Sicherungen mit cron-Jobs

Die cron-Funktion kann die Grundlage für die Planung von Sicherungen in AIX bilden und bietet eine präzise Kontrolle über wiederkehrende Vorgänge. Anstatt sich darauf zu verlassen, dass Administratoren jede Befehlssequenz manuell ausführen, kann cron die Konsistenz von Sicherungsprozessen gemäß vordefinierten Zeitplänen gewährleisten.

Unser erster Schritt wäre, die richtigen Berechtigungen für die zukünftige Sicherungsskriptdatei festzulegen:

# chmod 700 /usr/local/bin/backup_script.sh
Danach können wir auf die crontab zugreifen und Befehle und Zeitpläne einrichten:
# crontab -e
Wenn wir beispielsweise möchten, dass die wöchentlichen vollständigen Sicherungen jeden Sonntag um 1:00 Uhr durchgeführt werden, sollte der crontab-Eintrag wie folgt aussehen:
0 1 * * 0 /usr/local/bin/backup_script.sh > /var/log/backup.log 2>&1
Natürlich besteht immer die Möglichkeit, mithilfe der flexiblen Konfiguration von cron komplexere Zeitpläne zu erstellen. Als Beispiel können wir die vorherige Zeile verwenden und weitere Sicherungen mit unterschiedlichen Regeln hinzufügen:
# 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

Wir verwenden hier auch einen Befehl, um die Ausgabe in Protokolldateien umzuleiten (> /var/log/backup.log 2>&1), um die Standardausgabe der Sicherung und verschiedene Fehlermeldungen gleichzeitig zu erfassen. Eine detaillierte Protokollierung wie diese kann einen tiefen Einblick in verschiedene automatisierte Prozesse bieten, die normalerweise unbeaufsichtigt ablaufen.

Wenn ein Unternehmen eine zentralisierte Planung für mehrere AIX-Umgebungen gleichzeitig benötigt, ist der Network Installation Manager für diese Zwecke besser geeignet. NIM kann Administratoren dabei helfen, Sicherungsrichtlinien einmal zu definieren und sie dann konsistent auf die gesamte Infrastruktur anzuwenden.

Erstellen von Sicherungsskripten für wiederholte Aufgaben

Eine effektive Automatisierung von Sicherungen verwendet gut strukturierte Skripte, die in der Lage sind, den Sicherungsvorgang und alle wichtigen Schritte rund um die Sicherung – Vorbereitung, Überprüfung und Bereinigung – zu bewältigen. Durch die Erstellung eines solchen Sicherungsskripts wird eine Auswahl unzusammenhängender Befehle in einen umfassenden Workflow umgewandelt, der die Zuverlässigkeit von Sicherungsprozessen erheblich verbessern kann.

Eine grundlegende Sicherung mit mksysb sollte folgendermaßen aussehen:

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

Wie Sie sehen, enthält dieses Skript die meisten bewährten Verfahren, die wir in einem der vorherigen Abschnitte besprochen haben, mit dynamischem Benennungsschema, umfassender Protokollierung, Bereinigung vor der Sicherung, ordnungsgemäßer Fehlerbehandlung, dedizierter Überprüfung der Sicherungsintegrität, automatischer Bereinigung veralteter Sicherungsdateien und mehr.

Wenn ein Sicherungsskript für Umgebungen mit mehreren Volume-Gruppen erstellt wird, kann das Skript dennoch so angepasst werden, dass es alle erforderlichen Sicherungsprozesse umfasst:

#!/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“

Im Allgemeinen sollten Organisationen mit komplexen Sicherungs- und Wiederherstellungsanforderungen die Implementierung von Funktionen für verschiedene Prozesse in Betracht ziehen, um die Wiederverwendbarkeit des Codes zu verbessern und die Gesamtgröße jedes Skripts zu reduzieren (für eine bessere Wartbarkeit):
#!/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 „$@“

Es sollte beachtet werden, dass dieses Skript automatisch davon ausgeht, dass backup_functions.sh und die Konfigurationsdateien zuvor erstellt und als Quelle angegeben wurden.

Diese drei Beispiele sollten den meisten Benutzern einen guten Einblick in die Entwicklung von Skripten geben, von der Ausführung grundlegender Befehle bis hin zur Erstellung komplexer Arbeitsabläufe mit allen erforderlichen Optionen für Fehlerbehandlung, Protokollierung und modulares Design.

Automatische Analyse und Überprüfung von Sicherungen

Es ist nur logisch, dass automatisierte Sicherungen auch über automatisierte Überwachungs- und Verifizierungsprozesse verfügen sollten. Die Prozessautomatisierung kann jedoch eine gefährliche Illusion von Normalität erzeugen, wenn es keine tatsächliche Bestätigung für ihren Erfolg gibt.

Ein grundlegendes Verifizierungsskript sollte zumindest die Größe der Sicherung und die Tatsache, dass sie überhaupt vorhanden ist, überprüfen können:

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

Wenn ein fortgeschrittenerer Satz an Prozessen erforderlich ist, können auch Trendanalyse-Sequenzen (Verfolgung verschiedener Parameter im Laufe der Zeit) und zentralisierte Überwachungssysteme (Integration mit Unternehmensüberwachungslösungen wie Zabbix, Nagios oder Tivoli) implementiert werden.

Um Informationen über die Größe und Dauer von Sicherungen für weitere Tests zu extrahieren, können wir die folgende Ergänzung zum Skript verwenden:

# 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

Selbst Wiederherstellungstests können automatisiert werden, indem Teile von Sicherungen wiederhergestellt werden, um ihre Funktionsfähigkeit und Integrität regelmäßig zu überprüfen:
# Restore a test file from the most recent backup
mkdir -p /tmp/restore_test
tar -xvf /backup/latest.tar -C /tmp/restore_test ./path/to/test/file
Wie bereits erwähnt, ist der effektivste Ansatz für die Sicherung und Überwachung eine Kombination aus mehreren verschiedenen Ansätzen, die ein umfassendes Rahmenwerk für Verifizierungsprozesse schaffen und deren Nutzbarkeit und Vollständigkeit regelmäßig bestätigen.

Datenwiederherstellung aus AIX-Sicherungen

Es spielt keine Rolle, wie komplex und kompliziert die Sicherungsstrategie ist, wenn sie nicht mit einer ebenso effektiven Wiederherstellungsfunktion kombiniert wird. Wiederherstellungsverfahren müssen genauso sorgfältig behandelt werden wie Sicherungsvorgänge, da sie in der Regel bei kritischen Systemausfällen oder anderen Situationen außerhalb der Norm auftreten. Ein gutes Verständnis aller verschiedenen Nuancen von Wiederherstellungspraktiken sollte der Verwaltung dabei helfen, die Datenintegrität aufrechtzuerhalten und Ausfallzeiten zu minimieren, wenn Fehler oder Probleme unvermeidlich auftreten.

Wiederherstellung vollständiger Systemsicherungen mit mksysb

Das Dienstprogramm mksysb kann zur Erstellung vollständiger System sicherungen verwendet werden und bietet gleichzeitig die Grundlage für eine Bare-Metal-Wiederherstellung in der Zukunft. Auf diese Weise kann eine gesamte AIX-Umgebung von Grund auf neu erstellt werden, um sowohl die Systemdateien als auch die Anwendungsdateien oder Benutzerdaten wiederherzustellen.

Die Wiederherstellung beginnt mit dem Booten von AIX mithilfe des Installationsmediums – unabhängig davon, ob es sich um ein physisches Medium oder eine Netzwerkquelle handelt. Sobald wir uns im Installationsmenü befinden, wählen wir die Option „Von einer Systemsicherung installieren“ aus. Anschließend müssen wir das zu verwendende mksysb-Image angeben.

So sollte der Speicherort für das Image angegeben werden:

  • Das entsprechende Gerät wird eingegeben, wenn die Sicherungen bandbasiert sind:
/dev/rmt0
  • Wenn die Wiederherstellung netzwerkbasiert ist, muss NIM verwendet werden:
nim_server:/exports/mksysb/system_backup.mksysb
  • Wenn das Image auf einem lokalen oder angeschlossenen Speicher gehostet wird:
/dev/hdisk1:/backups/system_backup.mksysb

Sobald das mksysb-Image ausgewählt wurde, kann der Wiederherstellungsprozess beginnen. Zu den typischen Elementen dieses Prozesses gehören:

  1. Neuerstellung der ursprünglichen logischen Volumenstruktur unter Verwendung gespeicherter Metadaten als Grundlage.
  2. Neuformatierung vorhandener Dateisysteme gemäß den Sicherungsparametern.
  3. Extrahieren aller Dateien aus dem Image und Wiederherstellen am Zielspeicherort.
  4. Konfigurieren von Boot-Datensätzen, um das neu wiederhergestellte System bootfähig zu machen.
  5. Verwendung gesicherter Gerätekonfigurationen und Systemparameter.

Es sollte unbedingt erwähnt werden, dass mksysb-Wiederherstellungen die rootvg Volume-Gruppe des Zielsystems überschreiben, wobei alle vorherigen Daten in diesem Prozess zerstört werden. Dies hat jedoch keine so großen Auswirkungen auf Systeme mit mehreren Volume-Gruppen, da dies nur die rootvg betrifft. Andere Volume-Gruppen müssten separat mit unterschiedlichen Verfahren wiederhergestellt werden.

Nach der vollständigen Wiederherstellung des Systems kann die Systemintegrität durch eine Kombination aus Fehlerprotokollprüfung und kritischem Funktionstest überprüft werden:

# errpt -a | more
# lsvg -l rootvg

Datenwiederherstellung aus Volume-Gruppen-Sicherungen

Wenn der zu behebende Fehler nur bestimmte Volume-Gruppen und nicht die gesamte Umgebung betrifft, könnte eine gezielte Wiederherstellung mithilfe von restvg die bessere Alternative sein. Dieses Dienstprogramm kann Volume-Gruppen mithilfe von savevg-Sicherungen rekonstruieren, ohne dass das System von Grund auf neu installiert werden muss.

Ein grundlegender Befehl zum Wiederherstellen einer Volume-Gruppe aus einer Sicherungsdatei sieht wie folgt aus:

# restvg -f /backups/datavg.savevg
restvg versucht in der Standardkonfiguration, die Volume-Gruppe unter Verwendung ihres ursprünglichen Namens und anderer Merkmale neu zu erstellen. Diese Parameter können jedoch mithilfe bestimmter Befehle beliebig geändert werden:
# restvg -f /backups/datavg.savevg -l hdisk1 datavg_new
Mit diesem Befehl wird die Volume-Gruppe auf einer Festplatte namens hdisk1 unter dem Namen „datavg_new“ wiederhergestellt. Ein solcher konfigurierbarer Ansatz ist ideal, wenn Konflikte mit vorhandenen Volume-Gruppen vermieden werden müssen (oder wenn eine Sicherung auf einer anderen Hardware wiederhergestellt werden soll).

Andere potenziell nützliche Parameter, die auf ähnliche Weise konfiguriert werden könnten, sind:

  • Selektive Festplattenausrichtung, die die Wiederherstellung bestimmter logischer Volumes in bestimmten physischen Umgebungen steuert.
# restvg -f /backups/datavg.savevg -l hdisk1,hdisk2
  • Speicherplatzoptimierung zur Steuerung der Zuordnungsmuster physischer Partitionen.
# restvg -f /backups/datavg.savevg -b
  • Verifizierungsmodus, der den Wiederherstellungsprozess durch eine Vorschau-Imitation ersetzt.

# restvg -f /backups/datavg.savevg -v
Ähnlich wie im vorherigen Beispiel empfehlen wir auch hier, die Integrität der Volume-Gruppe nach Abschluss des Wiederherstellungsprozesses zu überprüfen:
# lsvg -l datavg
# fsck -y /dev/datavg/lv01

Dateiextraktion aus tar- oder cpio-Sicherungen

Die Wiederherstellung auf Dateiebene ist die detaillierteste der drei Optionen – sie ermöglicht es Administratoren, ganz bestimmte Dateien abzurufen, ohne die gesamte Umgebung zu beeinträchtigen. Sie ist die beste Möglichkeit, um Dateibeschädigungen, versehentliches Löschen oder andere Fälle selektiver Datenwiederherstellung zu beheben.

Unser erster Befehl wird verwendet, um bestimmte Informationen aus einem tar-Archiv zu extrahieren:

# cd /
# tar -xvf /backups/app_config.tar ./opt/application/config/settings.xml
Dieser Befehl extrahiert jedoch nur eine bestimmte Datei, wobei der ursprüngliche Pfad beibehalten wird. Wenn ein anderes Ziel festgelegt werden muss, können wir diesen Befehl verwenden:
# tar -xvf /backups/app_config.tar -C /tmp ./opt/application/config/settings.xml
Wenn der genaue Dateipfad im Archiv nicht klar ist, kann eine Alternative darin bestehen, den gesamten Inhalt aufzulisten:
# tar -tvf /backups/app_config.tar | grep settings
Wenn wir mit cpio-Archiven arbeiten, unterscheidet sich die Extraktionssyntax etwas:
# cd /
# cpio -idv ./opt/application/config/settings.xml < /backups/app_backup.cpio
Bei inkrementellen Sicherungen ist in der Regel eine sequenzielle Wiederherstellung erforderlich (beginnend mit einer vollständigen Sicherung, gefolgt von jeder inkrementellen Sicherung in chronologischer Reihenfolge). Ein sequenzieller Prozess wie dieser ist notwendig, um sicherzustellen, dass der Endzustand der Informationen alle Änderungen widerspiegelt, die über mehrere Sicherungsvorgänge hinweg erfasst wurden.

Beim Extrahieren von Konfigurationsskripten oder -dateien ist es keine schlechte Idee, kritische Dateiattribute sorgfältig zu bewahren:

# tar -xpvf /backups/app_config.tar
Das Flag „p“ in -xpvf ist notwendig, um alle ursprünglichen Eigentumsrechte, Zeitstempel und Berechtigungen der Informationen beizubehalten, was für den Betrieb der meisten Systemdateien unglaublich wichtig ist.

Best Practices für AIX-Sicherungsaufgaben und Wiederherstellungsprozesse

Der Unterschied zwischen einer funktionalen und einer belastbaren Sicherungsstrategie zeigt sich oft in der Berücksichtigung aller Details während der Implementierung. Die meisten bewährten Verfahren der AIX-Community sind das Ergebnis jahrelanger kollektiver Erfahrung, die dazu dient, eine Vielzahl unterschiedlicher Probleme in aktuellen und zukünftigen Umgebungen zu vermeiden.

Regelmäßige Tests der Sicherung

Es ist allgemein bekannt, dass eine ungetestete Sicherung in etwa so nützlich ist wie eine nicht vorhandene. Regelmäßige Wiederherstellungstests beweisen, dass die Sicherung im Falle eines Ereignisses verwendet werden kann, wodurch aus einem theoretischen Schutz eine praktische Funktion wird. Es ist nicht überraschend, dass diese Testverfahren häufig Probleme aufdecken, die möglicherweise übersehen oder anderweitig vergessen wurden.

Es sollte jedoch beachtet werden, dass das Testen selbst nicht nur ein einzelner binärer Prozess ist. Tatsächlich verwendet der bestmögliche Testansatz mehrere verschiedene Testansätze, darunter:

  • Die Metadatenverifizierung ist eine grundlegende Bestätigung, dass Sicherungsarchive dieselbe Struktur wie die Originalinformationen aufweisen:
# lsmksysb -l /backups/latest.mksysb
# listvgbackup -l /backups/datavg.savevg
  • Die Inhaltsstichprobenprüfung ist ein etwas fortgeschrittenerer Verifizierungsprozess, bei dem repräsentative Dateien extrahiert und ihre Integrität auf individueller Basis überprüft wird:
# 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
  • Funktionale Tests sind der de-facto-Goldstandard der Datenüberprüfung. Sie stellen Daten in einer isolierten Umgebung wieder her und versuchen, sie zu verwenden (erfordern jedoch auch dedizierte Testsysteme oder logische Partitionen, um zu verhindern, dass sich die Verifizierungsprozesse auf die Produktion auswirken):
# nim -o bos_inst -a source=mksysb -a spot=spot_name -a mksysb=backup_name test_lpar
  • Die Überprüfung auf Anwendungsebene ist nur auf Datenbankumgebungen anwendbar. Sie überprüft sowohl das Vorhandensein von Dateien als auch die Nutzbarkeit der Daten:

# db2 restore db SAMPLE from /backups/db_backup
# db2 connect to SAMPLE
# db2 „select count(*) from critical_table“

Ein ordnungsgemäßer Verifizierungsprozess sollte erst dann als abgeschlossen betrachtet werden, wenn bestätigt wurde, dass alle Dateien vorhanden sind, die Dateiberechtigungen den Anforderungen entsprechen, die Anwendungen wie erforderlich funktionieren und die Leistungskennzahlen innerhalb akzeptabler Grenzen liegen.

Maximale Sicherheit durch Rotation der Sicherungsmedien

Strategien zur Medienrotation gehen über die grundlegende Planung hinaus. Sie bieten einen zeitlichen Schutz vor vielen Ausfallszenarien, indem sie Speicherplatzbeschränkungen und Aufbewahrungsfristen ausgleichen und gleichzeitig Informationen vor vielen möglichen Problemen schützen.

Die typischste Struktur für die Rotation von Sicherungen wird oft als „Großvater-Vater-Sohn“-Prinzip bezeichnet. Sie umfasst

  • monatliche vollständige Sicherungen für langfristige Aufbewahrungszwecke (Großväter)
  • wöchentliche Sicherungen zur Bereitstellung konsolidierter Wiederherstellungspunkte (Väter)
  • tägliche Sicherungen zur Erfassung inkrementeller Änderungen (Söhne)

Neben der grundlegenden Sicherungsmethode der Rotation verwenden einige Unternehmen auch die Mediendiversifizierung, um technologiespezifische Risiken zu reduzieren, indem sie Sicherungen über verschiedene Speichertypen hinweg aufrechterhalten. Zum Schutz vor standortspezifischen Katastrophen wird dagegen eine geografische Trennung empfohlen.

Dokumentation des Sicherungsverfahrens

Dokumentationsprozesse sind eine Notwendigkeit, sie verwandeln das persönliche Wissen einer Person oder eines Teams in eine organisatorische Fähigkeit, die für den Wissenstransfer genutzt werden kann. Eine effektive Dokumentation deckt mehrere Dimensionen gleichzeitig ab:

  1. Verfahrensdokumentation ist die direkte Erfassung aller Prozesse für Sicherung und Wiederherstellung, Schritt für Schritt.
  2. Konfigurationsdokumentation muss verschiedene kritische Systemparameter enthalten, die ein Benutzer während einer Wiederherstellungssequenz möglicherweise benötigt.
  3. Abhängigkeitszuordnung wird verwendet, um Beziehungen zwischen Anwendungen und Systemen zu identifizieren, die die Wiederherstellungssequenz beeinflussen könnten.

Die Dokumentation selbst sollte auch an mehreren Orten gespeichert werden, einschließlich auf Sicherungsmedien, in gedruckter Form, auf separaten Systemen und in Cloud-Speichern.

Bekannte Herausforderungen und ihre Lösungen bei AIX-Sicherungen

Selbst die detaillierteste Sicherungsstrategie kann früher oder später auf ein Hindernis stoßen – sei es eine technische Einschränkung, eine Ressourcenknappheit usw. Wenn Administratoren jedoch die häufigsten Probleme kennen und wissen, wie sie zu lösen sind, sollte dies ihnen dabei helfen, die Zuverlässigkeit von Sicherungs- und Wiederherstellungsvorgängen langfristig aufrechtzuerhalten.

Speicherplatzbeschränkungen für Sicherungen

Speicherbeschränkungen treten bei AIX-Sicherungen überraschend häufig auf, da Datenmengen wachsen und die Anforderungen an den Sicherungsspeicher früher oder später angepasst werden müssen. Dieses Problem allein kann sich in abgeschnittenen Archiven und fehlgeschlagenen Sicherungsaufträgen äußern, die beide einen unzureichenden Schutz für die Umgebung bieten.

Es wird normalerweise empfohlen, verschiedene Maßnahmen zu ergreifen, wenn der verfügbare Speicherplatz unter 10-15 % fällt. Der naheliegendste Schritt wäre, zu versuchen, veraltete Sicherungsdateien zu löschen. Wenn diese Option jedoch nicht hilft, können wir auch einige komplexere Ansätze ausprobieren:

  • Implementierung von differentiellen und inkrementellen Sicherungen.
  • Anwendung von Datenkomprimierung.
  • Nutzung von Deduplizierungsfunktionen.
  • Verwendung von Tiered-Storage-Strategien, wenn anwendbar.
  • Erstellen einer automatisierten Lebenszyklus-Management-Umgebung, die Speicherhierarchien verwendet, um den Speicherplatz selbstständig zu verwalten.

Diagnose und Behebung von Fehlern bei Sicherungen

Es kann viele Gründe dafür geben, warum eine Sicherung fehlschlagen kann. Es kann sich um eine einfache Ressourcenbeschränkung oder eine komplexe Software-Interaktion handeln. Der Schlüssel zur Effektivität liegt immer in einer systematischen Diagnosesequenz, gefolgt von einer gezielten Lösung.

Eine detaillierte Fehleranalyse ist immer eine gute Idee, wenn ein Fehler auftritt:

# errpt -a | grep -i backup
# tail -100 /var/log/backup.log
Zu den häufigsten Fehlermustern in AIX-Umgebungen gehören:

  1. E/A-Fehler während Sicherungsvorgängen, die oft auf zugrunde liegende Festplattenprobleme hinweisen.
  2. Speicherzuordnungsfehler, die durch Erhöhung des verfügbaren Speichers durch Prozessbeendigung oder Anpassung des Paging-Speichers behoben werden.
  3. Netzwerk-Timeouts, die eine gründliche Prüfung des Netzwerkdurchsatzes erforderlich machen, um Engpässe und Einschränkungen zu ermitteln.
  4. Lock-Konflikte sind ein Problem bei Sicherungen, die auf aktiven Dateisystemen durchgeführt werden müssen, und werden häufig mithilfe von Snapshot-Technologien gelöst.

Abgesehen von allen gezielten technischen Abhilfemaßnahmen wird auch empfohlen, einen systematischen Ansatz für die Sicherungsüberwachung zu verwenden, mit dem Fehler erkannt und relevante Benutzer darüber benachrichtigt werden können.

Wenn einige Sicherungsfehler weiterhin bestehen, ist es möglicherweise an der Zeit für eine dauerhaftere Lösung, wie z. B. gestaffelte Sicherungszeitpläne, um mehr Ressourcen freizugeben, neben anderen Maßnahmen.

Kompatibilitätsprobleme bei Sicherungsgeräten

Sowohl die Hardware- als auch die Softwarekompatibilität können in einer komplexen AIX-Umgebung ein Problem darstellen, insbesondere wenn verschiedene Technologie-Stacks vorhanden sind. Beispielsweise ist die Kompatibilität von Bandlaufwerken in der Regel darauf zurückzuführen, dass ältere Hardware mit einer neueren Version von AIX interagiert, die diese nicht mehr unterstützt.

Alternativ dazu gibt es auch Herausforderungen bei der Netzwerkspeicherkompatibilität, die eine ordnungsgemäße Überprüfung aller im Sicherungs- oder Wiederherstellungsprozess verwendeten Protokolle erforderlich machen. Dateigrößenbeschränkungen scheinen der Vergangenheit anzugehören, treten aber in vielen Situationen und Dateisystemen immer noch auf (und die einzige Lösung besteht in den meisten Fällen darin, ein System zu verwenden, das größere Dateien unterstützt).

Backup-Proxys werden für viele Umgebungen mit anhaltenden Kompatibilitätsproblemen empfohlen. Dabei handelt es sich um dedizierte Systeme, die speziell für Sicherungsvorgänge konfiguriert sind und potenzielle Kompatibilitätslücken zwischen einer Sicherungsinfrastruktur und den Produktionsservern überbrücken.

AIX-Sicherungssoftware von Drittanbietern

Auch wenn native AIX-Tools ein beachtliches Maß an Sicherungsfunktionen bieten, erfordern die meisten Unternehmensumgebungen viele weitere Funktionen – erweiterte Planung, zentralisierte Verwaltung, Unterstützung mehrerer Plattformen und vieles mehr. An dieser Stelle kommen Lösungen von Drittanbietern ins Spiel, die die vorhandenen Funktionen von AIX um eigene Funktionssätze erweitern. Wir haben drei verschiedene Sicherungslösungen mit AIX-Unterstützung ausgewählt und werden nun versuchen zu erklären, wie sie Unternehmen in diesem Bereich zugutekommen können.

Veeam

Veeams breite Palette unterstützter Technologien und Umgebungen umfasst auch AIX (unter Verwendung eines speziellen Agenten, der für UNIX-Umgebungen entwickelt wurde). Einige der gängigsten Beispiele für die Fähigkeiten von Veeam sind:

  • Sicherung auf Dateiebene
  • Anwendungskonsistente Sicherung
  • Inkrementelle „Forever“-Sicherungsarchitektur
  • Zentralisierte Verwaltung

Veeam ist am wertvollsten, wenn es in heterogenen Rechenzentren eingesetzt wird, in denen AIX-Systeme neben vielen anderen Plattformen betrieben werden, was eine einheitliche Verwaltung mit reduziertem Verwaltungsaufwand erfordert.

Bacula Enterprise

Bacula Enterprise ist eine außergewöhnlich sichere Sicherungs- und Wiederherstellungslösung, die über ein dediziertes Modul für AIX-Umgebungen verfügt, wobei der Schwerpunkt auf Leistungsoptimierung und Zuverlässigkeit auf Unternehmensebene liegt. Zu den wichtigsten Funktionen von Bacula in AIX-Umgebungen gehören:

  • Erkennung von Volume-Gruppen
  • Fortschrittliche VIO-Technologie zur sicherung
  • Hochgradig gleichzeitige Sicherungsvorgänge
  • Optionen für die Bare-Metal-Wiederherstellung

Die modulare Architektur von Bacula kann AIX-Administratoren dabei helfen, nur die Komponenten auszuwählen, die sie in ihrer aktuellen Umgebung benötigen, wodurch der Verwaltungsaufwand drastisch reduziert wird, ohne dass die Datensicherheit beeinträchtigt wird.

Commvault

Commvault Complete Data Protection bietet eine Vielzahl von Funktionen und unterstützten Umgebungen, darunter AIX. Dies wird durch den Einsatz von speziell entwickelten Agenten erreicht, die sich tief in die vorhandenen AIX-Komponenten integrieren lassen und die folgenden Funktionen bieten:

  • Integration von mksysb
  • IntelliSnap-Technologie
  • Automatisierte Notfallwiederherstellung
  • Multi-Stream-Backup-Architektur
  • Cloud-Tiering-Optionen

Der größte Vorteil von CommVault in AIX und ähnlichen Umgebungen ist die umfassende Datenlebenszyklus-Management-Funktion, die über Sicherungs- und Wiederherstellungsvorgänge hinausgeht und Compliance, Analysen, langfristige Aufbewahrung usw. bietet.

Schlussfolgerung

AIX-Sicherungsstrategien erfordern die Kombination aus strategischer Vision und technischer Präzision. Die einzigartige Architektur von AIX-Systemen kann sowohl vorteilhaft als auch äußerst herausfordernd sein, wenn es um den Datenschutz geht. Wenn man die Arbeit mit AIX beherrscht, kann man Sicherungsvorgänge in einen echten organisatorischen Vorteil verwandeln, anstatt in einen notwendigen Verwaltungsaufwand.

Es ist wichtig, sich daran zu erinnern, dass die in diesem Leitfaden erwähnten Ansätze nicht nur theoretische Verfahren sind, sondern bewährte Methoden, die wiederholt und verfeinert wurden und auf der kollektiven Erfahrung unzähliger Produktionsumgebungen basieren. Daraus lässt sich schließen, dass die effektivste AIX-Umgebung eine ist, die native Dienstprogramme mit geeigneter Software von Drittanbietern, umfassender Dokumentation und gegebenenfalls automatisierter Verifizierung kombiniert. Ein solch komplexer Ansatz stellt sicher, dass jedes zukünftige Problem mit Zuversicht und einem Plan statt mit Panik angegangen werden kann.

Wir sollten noch einmal erwähnen, dass jede erfolgreiche Sicherungsstrategie auch ständige Aufmerksamkeit mit regelmäßigen Tests, regelmäßigen Überprüfungen und kontinuierlichen Verbesserungen erfordert, um den sich ständig ändernden Geschäftsumgebungen gerecht zu werden. Die Sicherung ist nie ein abgeschlossenes Projekt, sondern eine ganze Disziplin, die es im Laufe der Zeit aufrechtzuerhalten und zu verbessern gilt und die sich direkt auf die Widerstandsfähigkeit der Organisation in einer zunehmend informationsabhängigen Welt auswirkt.

Häufig gestellte Fragen

Können AIX-Sicherungen auf einem aktiven System durchgeführt werden?

Es stimmt zwar, dass AIX Online-Sicherungen für die meisten Vorgänge unterstützt, es gibt jedoch einige wichtige Einschränkungen zu beachten. Die meisten granularen Sicherungen mit tar, cpio und anderen Sicherungsdienstprogrammen sollten während des normalen Systembetriebs einwandfrei funktionieren, bei Dateien, die aktiv geändert werden, jedoch möglicherweise nicht. Volume-Group-Sicherungen mit savevg sollten ebenfalls funktionieren, für die Datenbankkonsistenz wären jedoch zusätzliche Schritte erforderlich – das Stoppen von Datenbankvorgängen, die Verwendung datenbankspezifischer Dienstprogramme usw. Vollständige System-Backups sind möglich, können jedoch zu erheblichen Leistungseinbußen beim Backup-Prozess führen.

Welche Tools eignen sich am besten für die Überwachung der Backup-Leistung in AIX?

Das interne AIX-Tool topas ist die beste integrierte Lösung für die Echtzeit-Leistungsüberwachung während Backup-Vorgängen. nmon bietet außerdem die Möglichkeit, Daten für Trendanalysen zu sammeln. Darüber hinaus kann die AIX Performance Toolbox während der Sicherungsfenster detaillierte Messdaten über die Hardware zur weiteren Verarbeitung erfassen. Es gibt auch zahlreiche Tools von Drittanbietern mit ähnlichen oder besseren Funktionen, die jedoch außerhalb der komplexeren und vielseitigeren Unternehmensumgebungen nur selten benötigt werden.

Wie lassen sich AIX-Sicherungen am besten in einen Cloud-Speicher migrieren?

Technisch gesehen ist die effizienteste Methode zur Migration von AIX-Sicherungen die Nutzung der Befehlszeilentools in einem AIX-System, um Informationen direkt an AWS, Azure oder Google Cloud zu übertragen – da alle drei über einen dedizierten CLI-Befehl verfügen (diese Umgebungen sollten zuvor ordnungsgemäß installiert und konfiguriert werden):

# aws s3 cp /backup/system.mksysb s3://aix-backups/
Das gleiche Ergebnis sollte sich auch mit der sicheren Dateiübertragungsfunktion von AIX erzielen lassen:
# scp /backup/datavg.savevg cloud-gateway:/remote/backups/
In komplexeren Umgebungen und Infrastrukturen sollten Cloud-Gateway-Geräte implementiert werden, um Cloud-Speicher als NFS- oder Objektspeicher darzustellen und die Datenübertragung mit Standardmitteln zu vereinfachen.

Kann ich mehrere Sicherungstypen gleichzeitig planen?

Es sollte zwar möglich sein, mehrere AIX-Sicherungen gleichzeitig zu planen und durchzuführen, doch führt dieser Ansatz unweigerlich zu Ressourcenkonflikten, die die Leistung der meisten Umgebungen beeinträchtigen, sodass solche Pläne in den meisten Fällen nicht ideal sind.

Was ist zu tun, wenn das AIX-Sicherungsmedium beschädigt wird?

Bei beschädigten AIX-Sicherungsmedien ist ein systematischer Wiederherstellungsansatz erforderlich. Der erste Schritt sollte immer darin bestehen, das Ausmaß des Schadens mithilfe eines der oben genannten Verifizierungswerkzeuge zu beurteilen. Der nächste Schritt hängt dann von der Art der Beschädigung ab. Bei einer teilweisen Beschädigung können spezielle Dienstprogramme möglicherweise einige lesbare Elemente mithilfe fortschrittlicher Algorithmen wiederherstellen. Wenn kritische Daten betroffen sind, wird dringend empfohlen, den IBM-Support oder einen Datenrettungsspezialisten zu konsultieren, bevor Sie versuchen, Daten wiederherzustellen oder einen Systembefehl auszuführen.

Über den Autor
Rob Morrison
Rob Morrison ist der Marketingdirektor bei Bacula Systems. Er begann seine IT-Marketing-Karriere bei Silicon Graphics in der Schweiz, wo er fast 10 Jahre lang in verschiedenen Marketing-Management-Positionen sehr erfolgreich war. In den folgenden 10 Jahren hatte Rob Morrison auch verschiedene Marketing-Management-Positionen bei JBoss, Red Hat und Pentaho inne und sorgte für das Wachstum der Marktanteile dieser bekannten Unternehmen. Er ist Absolvent der Plymouth University und hat einen Honours-Abschluss in Digital Media and Communications und ein Overseas Studies Program absolviert.
Einen Kommentar hinterlassen

Deine Email-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *