Hi an die NetApp-OnCommand-/Backup-/Restore-Front, nachdem sich viele nicht die „Mühe“ machen, die OnCommand Datenbank auf eine eigene LUN zu legen und sich somit standardmäßig den Weg „verbauen“ mit der Snapshot-Technologie mehrfach täglich die Datenbank von OnCommand zu sichern (da „archive“ Backup maximal täglich funktioniert), hier ein kleiner „Workaround“…
Standardmäßig ist es wie erwähnt nur möglich mit den sog. „Archive“-Backups 1x am Tag zu sichern.
Der Trick sind einfach ein paar geplante Tasks auf dem OnCommand Server, die die Backupschedule einfach weiter drehen…
In meinem Beispiel sollen um 11.00 Uhr und um 23.00 Uhr Datenbankbackups auf die lokale Disk des OnCommand laufen:
Geplanter Task 1 – läuft täglich um 10.00 Uhr auf dem DFM-Server:
# Schedule auf 11.00 Uhr setzen
dfm backup schedule set -t archive -D 11:00
# Schedule enablen
dfm backup schedule enable
# Backupverzeichnis festlegen (Achtung: wenn bereits Backups vorhanden, alle in diesen Ordner kopieren)
dfm option set databaseBackupDir=C:\dfmbackup
# Backup Retention festlegen
dfm option set backupRetentionCount=14
Geplanter Task 2 – läuft täglich um 22.00 Uhr auf dem DFM-Server:
# Schedule auf 23.00 Uhr setzen
dfm backup schedule set -t archive -D 23:00
# Schedule enablen
dfm backup schedule enable
# Backupverzeichnis festlegen (Achtung: wenn bereits Backups vorhanden, alle in diesen Ordner kopieren)
dfm option set databaseBackupDir=C:\dfmbackup
# Backup Retention festlegen
dfm option set backupRetentionCount=14
Mit diesem Workaround ist es möglich, mehrere Archivebackups zu fahren.
Dies löst allerdings nicht das Problem, dass man beim databaseBackupDir keinen Netzwerkpfad angeben kann.
Ich habe es auf alle erdenklichen Weisen versucht – Netzlaufwerk direkt,
Netzlaufwerk mit Unterordner, DirectoryLink gemountet in das Homedrive
von Windows uvm. – allerdings immer ohne Erfolg… Die Knowledge-Base
von Netapp hat auch nichts passendes zu bieten…
An dieser Stelle kann man dann darüber philosophieren, wie man die DB-Backups noch auf eine Backupseite bekommt…
Mögliche Varianten:
- 01. Für Skriptfreunde:
- die DB-Backup-Files aus OnCommand per klassischem robocopy oder Skript wegsichern
- 02. für die Old-Schooler:
- die DB-Backup-Files aus OnCommand per klassischer Backupsoftware auf Tape abziehen
- 03. für die modernen Verrückten:
- OnCommand als virtuelle Maschine aufsetzen und sich selbst nach dem DB-Backup per HostPackage auf ein zweites Storage sichern lassen – am besten in einem Dataset, dass von OnCommand selbst verwaltet wird
- PS: extreeeeem coole Sache 😉
- 04. für die Wissenschaftler:
- OSSV auf den OnCommand Server und die Files per OSSV vom OnCommand auf ein weiteres Storage sichern
- PS: Ob das geht, konnte ich noch nicht testen, hört sich aber spaßig an 🙂