netvault_backupsystem:start
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende ÜberarbeitungNächste ÜberarbeitungBeide Seiten der Revision | ||
netvault_backupsystem:start [10:27 21. June 2010 ] – jnn | netvault_backupsystem:start [10:09 04. December 2014 ] – [Hardware] Christian Marg | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== | + | ====== |
- | + | ||
- | Zentrales Backup | + | |
Das Rechenzentrum betreibt eine zentrale Backup-Lösung, | Das Rechenzentrum betreibt eine zentrale Backup-Lösung, | ||
- | NetVault Backupsystem | ||
- | Hardware | ||
- | Das Backup erfolgt zentral gesteuert, d.h. Backup-Requests werden von einem Server auf den Clients initiiert, die Backup-Jobs sind nicht über die Backup-Clients veränderbar, | + | ===== NetVault Backupsystem ===== |
- | 2 Backupserver im RZ übernehmen die Steuerung der Backup-Requests und verwalten die Backup-Devices, | + | ==== Hardware ==== |
- | Als Backupdevices werden verwendet: | ||
- | * ADIC Scalar100 Tapelibrary, mit 5 LTO-2 Laufwerken und 60 Tape-Slots (Nettokapazität 12TB) zur Aufnahme der NDMP-Backups der NetApp-Filers | + | Das Backup erfolgt zentral gesteuert, d.h. Backup-Requests werden von einem Server auf den Clients initiiert, die Backup-Jobs sind nicht über die Backup-Clients veränderbar, |
- | * 2 VTLs (Virt. TapeLibs, bzw. Disk-RAID-Systeme mit 3.5TB und 4.5TB als Backup-Stage | + | |
- | * MSL6060 TapeLib mit 2x LTO-3 Laufwerken und 60 Tape-Slots (24TB netto) im EFZN | + | |
- | * MSL6060 TapeLib mit 4x LTO-4 Laufwerken und 60 Tape-Slots (48TB netto) im RZ | + | |
- | * MSL6060 TapeLib mit 2x LTO-4 Laufwerken und 60 Tape-Slots (48TB netto) im Cluster Vorderer Feldgraben | + | |
- | Die Verteilung der Tape-Libraries auf unterschiedliche Standorte hat verschiedene Gründe. Zum einen soll vermieden | + | Als Backupdevices |
- | Die Lagerung | + | * Virtuelle TapeLib mit etwa 16TB Speicherplatz (als RAID-System im Backup-Server) |
+ | * Overland Neo8000 TapeLib mit derzeit 6x (max 12x) LTO-5 Laufwerken und 216 (von 500) nutzbaren Tape-Slots im RZ | ||
- | + | ||
- | Backup-Policy | + | ==== Backup-Policy |
Einmalig werden die zu sichernden Bereiche des Backup-Clients vollständig auf Band gesichert. Anschliessend werden täglich inkrementelle Sicherungen durchgeführt, | Einmalig werden die zu sichernden Bereiche des Backup-Clients vollständig auf Band gesichert. Anschliessend werden täglich inkrementelle Sicherungen durchgeführt, | ||
Zeile 32: | Zeile 24: | ||
Ein Restore des Systems bzw. der Systemplatte kann mit NetVault nicht durchgeführt werden. Deshalb muss der Systembereich mit den entspr. Unix-Tools, wie " | Ein Restore des Systems bzw. der Systemplatte kann mit NetVault nicht durchgeführt werden. Deshalb muss der Systembereich mit den entspr. Unix-Tools, wie " | ||
- | Die Filerköpfe nas 1 und nas2 werden täglich | + | Die NAS-Systeme des RZ (NetApp |
+ | |||
+ | === NetApp NAS (nas1.tu-clausthal.de | ||
+ | |||
+ | * 6 Snapshots um 08:00, 10:00, 12:00, 16:00 und 20:00 | ||
+ | * 6 tägliche Snapshots um 00:00 | ||
+ | * 4 wöchentliche Snapshots um 00:00 | ||
+ | |||
+ | Diese Snapshots werden zyklisch überschrieben, | ||
+ | |||
+ | === Isilon-NAS bzw. isilon-Cluster (nas.tu-clausthal.de) === | ||
+ | |||
+ | Gleichartige Snapshot-Schedules für sämtliche Instituts-Datenbereiche: | ||
+ | |||
+ | * every weekday every 4 hours from 08:00 to 20:00, expiration=5days | ||
+ | * every day at 02:00, expiration=21days | ||
+ | * every 1 month on the 1st, expiration=4months | ||
+ | |||
+ | Insgesamt werden hier 45 Snapshot-Images vorgehalten. | ||
+ | |||
+ | Das sind die derzeitigen Einstellungen, | ||
+ | |||
+ | ==== Hinweis zum Expire von inkrementellen und vollen Sicherungen ==== | ||
+ | |||
+ | Zunächst einmal ist zu unterscheiden zwischen löschen und expire, letzteres löscht nur die entsprechenden Einträge aus der NetVault-Datenbank, | ||
+ | |||
+ | Ähnlich verhält es sich bei vollen und inkrementellen Datensicherungen. Wenn ein Fullbackup expired, werden auch die relevanten Incrementals expired, d.h. aus der Datenbank entfernt, da sie ohne Fullbackup wertlos sind. Allerdings bleiben alle Backups so lange auf Tape, bis es überschrieben wird und können somit mittels Scan wieder in die Datenbank gelesen werden. | ||
+ | |||
+ | Inkrementelle Backups beziehen sich auf das vorangegangene Full Backup bzw. auf das synthetische konsolidierte Backup. Deshalb benötigen die inkrementellen Sicherungen keine Angabe zur Lifetime, da sie laut unserer Policy mit erfolgreichem nächsten Full Backup bzw. Konsolidierlauf mit der vorangegangenen vollen Sicherung gelöscht werden. | ||
+ | |||
+ | Ein consolidated backup zählt so, als ob zu diesem Zeitpunkt als ein neues Full Backup angelegt worden wäre. (O-Ton-Bakbone) | ||
Zeile 40: | Zeile 62: | ||
{{indexmenu> | {{indexmenu> | ||
+ | |||
+ | Weiterführende Infos entnehmen Sie bitte der (englischssprachigen) NetVault-Dokumentation: | ||
+ | |||
+ | * {{: | ||
+ | * {{: | ||
+ | * {{: |