Protection Manager: Verschieben eines SnapVault-Secondary Volumes

Planung hin oder her - es kann vorkommen, dass ein vom Protection Manager verwalteter Ressource-Pool volläuft und keine Möglichkeit besteht, diesen zu vergrössern.
Der Protection Manager bietet (mindestens in der Version 4) keine Boardmittel, um das Secondary-Volume in einen neues Aggregate zu verschieben.

Eine Rundum-Wohlfühl-Lösung habe ich keine gefunden, dafür aber eine Quick- und Dirty-Variante, bei welcher wenigstens keine Backups verloren gehen:

Step 1 - Daten auf das neue Volume spiegeln

vol create svdest_neu -l C.UTF-8 aggr1_sata 2340g
snap reserve svdest_neu 0
snap sched svdest_neu 0
vol restrict svdest_neu
snapmirror initialize -S svdest svdest_neu

Step 2 - Spiegel brechen

snapmirror update svdest_neu
snapmirror quiesce svdest_neu snapmirror break svdest_neu

Step 3 - Dataset bearbeiten
Als nächstes gilt es, das alte SnapVault-Secondary-Volume aus dem Dataset zu entfernen:


Step 4 - Volumes umbenennen / offline nehmen

vol rename svdest svdest_old
vol rename svdest_neu svdest
vol offline svdest_old

Step 5 - SnapVault-Beziehungen wiederherstellen

snapvault start -S 10.0.0.2:/vol/volume1/qtree1 /vol/svdest/qtree1
snapvault start -S 10.0.0.2:/vol/volume2/qtree1 /vol/svdest/qtree2
...
snapvault start -R /vol/svdest/qtree1
snapvault start -R /vol/svdest/qtree2
...

Step 6 - Dataset bearbeiten
Damit die Datensicherung wieder vom PM verwaltet wird, muss das neue Secondary Volume dem Dataset hinzugefügt werden.

Step 7 - Abschliessende Schritte
Altes Volume löschen, Guarantee auf None stellen, ...


Wichtig:
Die alten Backups werden nicht mehr von dem Protection Manager verwaltet und müssen deshalb manuell restored und schlussendlich auch gelöscht werden.

Volume gelöscht, obwohl LUN online & connected

Bei dutzenden Datenübernahmen ist es ziemlich schnell passiert, dass ein Volume auf dem NetApp-Filer gelöscht wird, ohne vorher das LUN auf dem Server zu disconnecten. Windows hat damit grosse Mühe, vorallem wenn das LUN nicht über einen Laufwerksbuchstaben, sondern über einen Volume-Mountpoint eingehängt war. Der Mountpoint ist ab diesem Moment "gelockt" und kann nicht wiederverwendet werden. Ein Reboot würde das Problem bestimmt beheben, je nach Produktivität des Server aber nicht wirklich möglich.

Für diesen Fall gibt es das Windows-interne Tool "mountvol".

Syntax wie folgt:

mountvol /D [mountpoint]

Ab sofort ist der Lock aufgehoben und der Mountpoint lässt sich wieder normal verwenden.

DFM: Report generieren via CLI

Belegte Kapazität der QTrees in einem Volume ausgeben:

dfm report view -F csv qtrees-capacity 7518 > qtrees.csv

Belegte Kapazität der Benutzer auf einem Volume ausgeben:

dfm report view -F csv -g 23723 users-quotas-total > userquotas.csv

SnapManager for SQL: Defaultpfade für neue DBs und Fulltext-Kataloge

Damit Datenbanken mit dem SnapManager für SQL von NetApp gesichert werden können, müssen diese natürlich auch auf NetApp-Storage liegen. Falls die interne Organisation eures Arbeitgebers den Betrieb der Datenbanken vom Betrieb des Backups trennt, kann dies ziemlich mühsam werden.
Kaum hat man das Backup eines SQL-Servers eingerichtet und die Datenbank auf das NetApp-LUN verschoben, so geht es nicht mehr lange bis der DBA eine neue DB oder einen Fulltext-Katalog auf der Systempartition (Non-NetApp-Storage) erstellt.

Zum Glück kann man die Standardpfade für DBs ziemlich einfach ändern:



Beim FullText-Katalog gehts leider nicht mit dem GUI, jedoch über die Registrierung. Unter folgendem Pfad

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer

kann der folgende Schlüssel auf den gewünschten Pfad abgeändert werden:


Diese Konfiguration muss für jede Instanz durchgeführt werden.

SMSQL: Backup-History aufräumen

Bei einer Sicherung der MSSQL-DBs mit dem NetApp SnapManager for SQL, werden bei jeder Ausführung Informationen in die MSDB gespeichert. Nach ein paar Monaten (und > 1000facher Ausführung) kann diese DB deshalb gerne mal um ~100MB anwachsen. Da die MSDB als Systemdatenbank wiederum per Stream-Backup ins SnapInfo-Volume jedesmal voll gesichert wird, können diese 100MB schnell mal zu mehreren GB an Backupdaten führen.

Durch einen wöchentlichen Zeitplan mit folgendem SQL-Statement kann dies verhindert werden:

-- Der folgende Befehl löscht die SQL-Backup-History älter 7 Tage
-- Der SnapManager ist eigentlich gar nicht auf diese Informationen angewiesen.
USE MSDB
DECLARE @backup_date DATETIME
BEGIN
set @backup_date=(select dateadd (dd, -7, getDate()))
EXEC SP_DELETE_BACKUPHISTORY @backup_date
END
GO
DBCC SHRINKFILE (N'MSDBData' , 0)
GO
DBCC SHRINKFILE (N'MSDBLog' , 0)
GO

Robocopy für Datenmigrationen

robocopy %source% %destination% /ZB /COPYALL /DCOPY:T /R:0 /W:0 /MIR /LOG:"%userprofile%/Desktop/copy.log" /NP /NDL /TEE

Erklärung:

/Z: kopiert die Dateien im "restartable mode". Sollte eine Übertragung scheitern, aus welchem Grund auch immer, kann Robocopy die Datei bei der nächsten Ausführung fortsetzen, ohne nochmals die komplette Datei kopieren zu müssen.
/B: Versucht Dateien, mit den Backup-Operator-Privilegien zu kopieren
/COPYALL: Kopiert alle Dateiattribute mit
/DCOPY:T: Übernimmt die Zeitstempel der Verzeichnisse
/R:0 /W:0 : Macht sofort weiter wenn eine Datei im Zugriff sein sollte
/MIR: Macht das Ziel zu einem 1:1 Abbild der Quelle
/LOG:"%userprofile%/Desktop/copy.log": Erstellt ein Log auf dem Desktop
/NP: Gibt im Log keine Prozentzahlen aus
/NDL: Schreibt nicht die ganzen Ordnernamen ins LOG (Log wird kleiner)
/TEE: Gibt trotz Logging die Informationen am Bildschirm aus


Optional:
/XD Verzeichnis1 Verzeichnis2: Schliesst die Verzeichnisse in der Liste aus