--- title: "AIX-sicherung meistern: Umfassender Leitfaden für Systemadministratoren" published_at: "2025-03-14T19:35:22+00:00" modified_at: "2025-03-14T19:35:45+00:00" url: "https://www.baculasystems.com/de/blogs/sicherung-von-aix-meistern/" markdown_url: "https://www.baculasystems.com/de/blogs/sicherung-von-aix-meistern.md" taxonomy_language: - "Deutsch" --- [Home](https://www.baculasystems.com/de/) > [Backup- und Wiederherstellungs-Blog](https://www.baculasystems.com/de/blogs/) > AIX-sicherung meistern: Umfassender Leitfaden für Systemadministratoren # AIX-sicherung meistern: Umfassender Leitfaden für Systemadministratoren Aktualisiert 14th März 2025, Rob Morrison 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](https://www.veeam.com/) 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](https://www.baculasystems.com/) 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](https://www.commvault.com/) 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 [https://www.linkedin.com/in/rob-morrison-3aa443/](https://www.linkedin.com/in/rob-morrison-3aa443/) 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. *Verwandte Beiträge* [https://www.baculasystems.com/de/blogs/hpc-sicherheitsleitfaden-800-223-800-234/](https://www.baculasystems.com/de/blogs/hpc-sicherheitsleitfaden-800-223-800-234/) [HPC-Sicherheitsleitfaden und Standards: NIST SP 800-223 und SP 800-234](https://www.baculasystems.com/de/blogs/hpc-sicherheitsleitfaden-800-223-800-234/) Oktober 6, 2025 [https://www.baculasystems.com/de/blogs/was-ist-business-continuity-disaster-recovery/](https://www.baculasystems.com/de/blogs/was-ist-business-continuity-disaster-recovery/) [Was ist Business Continuity und Disaster Recovery? Der Unterschied zwischen BC und DR](https://www.baculasystems.com/de/blogs/was-ist-business-continuity-disaster-recovery/) Mai 1, 2024 [https://www.baculasystems.com/de/blogs/mainframe-sicherung-und-wiederherstellung/](https://www.baculasystems.com/de/blogs/mainframe-sicherung-und-wiederherstellung/) [Mainframe-Backup und -Wiederherstellung: Moderne Strategien für ausfallsichere Unternehmenssysteme](https://www.baculasystems.com/de/blogs/mainframe-sicherung-und-wiederherstellung/) März 30, 2026 [https://www.baculasystems.com/de/blogs/intersystems-iris-sicherung-und-wiederherstellung-zur-gewaehrleistung-der-datenbankintegritaet/](https://www.baculasystems.com/de/blogs/intersystems-iris-sicherung-und-wiederherstellung-zur-gewaehrleistung-der-datenbankintegritaet/) [InterSystems IRIS: Sicherung und Wiederherstellung zur Gewährleistung der Datenbankintegrität](https://www.baculasystems.com/de/blogs/intersystems-iris-sicherung-und-wiederherstellung-zur-gewaehrleistung-der-datenbankintegritaet/) Mai 28, 2026 [https://www.baculasystems.com/de/blogs/bare-metal-backup-sicherung/](https://www.baculasystems.com/de/blogs/bare-metal-backup-sicherung/) [Bare Metal Backup und Recovery: Definition und Typen](https://www.baculasystems.com/de/blogs/bare-metal-backup-sicherung/) Oktober 2, 2024 [https://www.baculasystems.com/de/blog/unternehmen-backup-software/](https://www.baculasystems.com/de/blog/unternehmen-backup-software/) [Wie wählt man die beste Backup Software für Unternehmen im Jahr 2025? Die besten Datensicherungslösungen für Unternehmen.](https://www.baculasystems.com/de/blog/unternehmen-backup-software/) August 2, 2025