Ein abgestürztes SharePoint OnPrem-System ist der Albtraum jedes IT-Administrators. Der Herzschlag beschleunigt sich, der Schweiß bricht aus und die Gedanken rasen: Sind unsere Daten verloren? Wie schnell können wir wieder online sein? Und was ist mit dieser *einen* wichtigen ASPX-Datei, die für eine geschäftskritische Funktion unerlässlich ist? Dieser Artikel ist Ihr Rettungsanker in einer solchen Krise. Wir tauchen tief in die Methoden ein, wie Sie eine ASPX-Datei wiederherstellen können, selbst wenn Ihr SharePoint-System am Boden liegt.
Der Absturz: Ein Blick auf das Worst-Case-Szenario
Wenn wir von einem „abgestürzten SharePoint OnPrem” sprechen, kann das verschiedene Bedeutungen haben. Es könnte bedeuten, dass die SharePoint-Dienste nicht starten, die Webanwendungen nicht erreichbar sind, die Inhaltsdatenbank beschädigt ist oder sogar der gesamte Server nicht bootet. Unabhängig vom Grad des Absturzes ist das Ziel klar: die verlorenen oder unzugänglichen Daten, insbesondere die ASPX-Dateien, zu retten.
ASPX-Dateien sind das Herzstück vieler SharePoint-Anpassungen. Sie können benutzerdefinierte Seitenlayouts, Webparts, Anwendungsseiten oder sogar ganze Startseiten darstellen. Eine verlorene oder beschädigte ASPX-Datei kann eine ganze Abteilung lahmlegen oder kritische Geschäftsprozesse unterbrechen. Daher ist die schnelle und effektive Notfall-Rettung dieser Dateien von größter Bedeutung.
Erste Schritte und Lagebeurteilung
Bevor Sie in Panik verfallen, ist eine ruhige und methodische Lagebeurteilung entscheidend.
1. Was ist genau abgestürzt? Ist es nur eine einzelne Webanwendung, die SharePoint-Farm insgesamt oder der gesamte Server?
2. Welche Ressourcen stehen zur Verfügung? Haben Sie Zugriff auf Backups (Farm-Backup, Datenbank-Backup)? Können Sie auf den Dateisystem des Servers zugreifen? Ist der SQL Server noch erreichbar?
3. Wann war das letzte bekannte gute funktionierende System? Gibt es einen Zeitpunkt, zu dem die gesuchte ASPX-Datei definitiv intakt und vorhanden war?
4. Ist die ASPX-Datei eine Standarddatei oder eine Anpassung? Standarddateien (im 14/15/16 Hive) sind oft einfacher zu ersetzen als maßgeschneiderte Anpassungen.
Diese Fragen helfen Ihnen, den besten Wiederherstellungspfad zu identifizieren.
Wo leben ASPX-Dateien in SharePoint OnPrem?
Um eine ASPX-Datei wiederherzustellen, müssen Sie verstehen, wo SharePoint sie speichert:
* Im Dateisystem (14/15/16-Hive): Dies gilt hauptsächlich für systemweite Seitenlayouts, Masterseiten, Anwendungsseite (Application Pages) und Dateien von Farm-Lösungen (WSP-Pakete), die als `_layouts` oder `_admin` bereitgestellt werden. Diese befinden sich typischerweise unter `C:Program FilesCommon FilesMicrosoft Sharedweb server extensions1xTEMPLATELAYOUTS` oder ähnlichen Pfaden.
* In der Inhaltsdatenbank: Die meisten benutzerdefinierten Seiten, Webpart-Seiten, Wiki-Seiten, Veröffentlichungsseiten und Dateien, die direkt in Dokumentbibliotheken hochgeladen werden (z.B. in der `Seiten`-Bibliothek), werden als Binärdaten in der entsprechenden SharePoint-Inhaltsdatenbank gespeichert. Dies ist der häufigste Fall für kritische, angepasste ASPX-Dateien.
Da die meisten geschäftskritischen, angepassten ASPX-Dateien in der Inhaltsdatenbank liegen, konzentrieren wir uns auf deren Wiederherstellung.
Wiederherstellungsmethoden für ASPX-Dateien
Hier sind die gängigsten und effektivsten Methoden zur Datenwiederherstellung einer ASPX-Datei aus einem abgestürzten SharePoint OnPrem-System, geordnet nach der Wahrscheinlichkeit des Erfolgs und der Komplexität:
Methode 1: Wiederherstellung aus einem Content Database Backup (Empfohlen)
Dies ist die sicherste und zuverlässigste Methode, vorausgesetzt, Sie haben regelmäßige SharePoint Backups Ihrer Inhaltsdatenbanken erstellt.
1. Voraussetzung: Sie haben ein vollständiges und intaktes Backup der Inhaltsdatenbank (MDF/LDF-Dateien oder ein SharePoint-natives Backup). Der SQL Server, der die Datenbank enthält, ist entweder noch erreichbar oder die Backup-Dateien können auf einen anderen SQL Server übertragen werden.
2. Einrichten einer Wiederherstellungsumgebung:
* Erstellen Sie eine *separate und isolierte* SharePoint-Farm (z.B. eine virtuelle Maschine oder einen Testserver). Diese Farm muss nicht voll funktionsfähig sein, aber sie sollte in der Lage sein, eine Webanwendung und eine Website-Sammlung zu hosten. Sie können auch einen einzelnen SharePoint-Server für diesen Zweck verwenden.
* Stellen Sie sicher, dass die Version von SharePoint auf der Wiederherstellungsfarm mit der des Quellsystems übereinstimmt, um Kompatibilitätsprobleme zu vermeiden.
3. Wiederherstellung der Inhaltsdatenbank auf SQL Server:
* Stellen Sie die Inhaltsdatenbank aus dem Backup auf einem SQL Server wieder her. Geben Sie ihr einen temporären Namen (z.B. `Wiederherstellungs_ContentDB`), um Konflikte mit produktiven Datenbanken zu vermeiden.
* Öffnen Sie SQL Server Management Studio, klicken Sie mit der rechten Maustaste auf „Databases”, wählen Sie „Restore Database” und folgen Sie den Anweisungen, um die Datenbank wiederherzustellen.
4. Mounten der Inhaltsdatenbank in SharePoint (Read-Only):
* Öffnen Sie die SharePoint Management Shell auf Ihrer Wiederherstellungsfarm.
* Erstellen Sie eine temporäre Webanwendung, falls noch nicht geschehen:
„`powershell
New-SPWebApplication -Name „WiederherstellungsWebApp” -ApplicationPool „SharePoint – Wiederherstellung” -ApplicationPoolAccount (Get-SPManagedAccount „domainsp_service_account”) -URL „http://wiederherstellungsserver:80” -Port 80 -AllowAnonymousAccess
„`
* Fügen Sie die wiederhergestellte Inhaltsdatenbank der temporären Webanwendung hinzu, aber im schreibgeschützten Modus, um jegliche ungewollte Änderungen zu verhindern:
„`powershell
Mount-SPContentDatabase -Name „Wiederherstellungs_ContentDB” -WebApplication „http://wiederherstellungsserver:80” -AssignNewDatabaseId -Verbose
„`
Der Parameter `-AssignNewDatabaseId` ist wichtig, um GUID-Konflikte zu vermeiden, falls Sie dieselbe Datenbank später produktiv wiederherstellen möchten.
5. Extrahieren der ASPX-Datei mithilfe von PowerShell:
* Sobald die Datenbank gemountet ist, können Sie PowerShell verwenden, um die ASPX-Datei zu exportieren. Sie müssen den Pfad der Datei in der Website-Sammlung kennen.
* Finden Sie die Website-Sammlung:
„`powershell
$site = Get-SPSite „http://wiederherstellungsserver:80/sites/ihre_site_sammlung”
„`
* Wenn die ASPX-Datei eine Seitenbibliothek ist (z.B. in „Seiten” oder „Websiteobjekte”):
„`powershell
$web = $site.RootWeb
$file = $web.GetFile(„Seiten/ihre_seite.aspx”) # Oder „SitePages/ihre_seite.aspx”
$fileBytes = $file.OpenBinary()
[System.IO.File]::WriteAllBytes(„C:Recoveryihre_seite.aspx”, $fileBytes)
$site.Dispose()
„`
* Wenn die ASPX-Datei Teil einer Website ist, die Sie komplett exportieren möchten, können Sie `Export-SPWeb` verwenden:
„`powershell
Export-SPWeb -Identity „http://wiederherstellungsserver:80/sites/ihre_site_sammlung/ihre_unterseite” -Path „C:Recoverysubsite_export.cmp” -IncludeUserSecurity -IncludeVersions All
„`
Nach dem Export müssen Sie die CMP-Datei entpacken (es ist eigentlich eine CAB-Datei, die Sie mit einem Tool wie 7-Zip entpacken können), um die ASPX-Datei zu finden. Sie finden sie normalerweise unter einem Pfad, der die GUID der Liste oder Bibliothek enthält.
6. Übertragung und Einbindung der ASPX-Datei:
* Sobald Sie die ASPX-Datei haben, können Sie sie auf Ihr Produktivsystem übertragen.
* Wie Sie sie wieder einbinden, hängt davon ab, wie sie ursprünglich bereitgestellt wurde:
* Wenn es eine Seite in einer Bibliothek war: Laden Sie sie manuell über die SharePoint-UI oder PowerShell hoch.
* Wenn es eine benutzerdefinierte Anwendungsseite oder ein Layout war: Ersetzen Sie die Datei im 14/15/16-Hive (nachdem Sie eine Sicherungskopie der bestehenden Datei erstellt haben) oder deployen Sie sie über eine Farm-Lösung neu.
Methode 2: Direkter Dateisystemzugriff (für 14/15/16-Hive-Dateien)
Wenn Ihr SharePoint-Server zwar nicht vollständig funktioniert, Sie aber noch Zugriff auf das Dateisystem haben, können Sie Dateien aus dem SharePoint-Hive wiederherstellen.
1. Zugriff auf den Dateisystem des Servers: Melden Sie sich direkt am SharePoint-Server an oder greifen Sie über eine Netzwerkfreigabe auf die Festplatte zu.
2. Navigieren zum SharePoint-Hive: Die relevanten Ordner sind:
* Für SharePoint 2010: `C:Program FilesCommon FilesMicrosoft Sharedweb server extensions14`
* Für SharePoint 2013: `C:Program FilesCommon FilesMicrosoft Sharedweb server extensions15`
* Für SharePoint 2016/2019: `C:Program FilesCommon FilesMicrosoft Sharedweb server extensions16`
3. Suchen der ASPX-Datei: Innerhalb dieser Ordner finden Sie die `TEMPLATELAYOUTS` oder `TEMPLATEADMIN` Ordner. Hier werden oft Masterseiten, Seitenlayouts und Anwendungsseiten abgelegt. Beachten Sie, dass dies *nicht* der Speicherort für Seiten ist, die in der Inhaltsdatenbank erstellt wurden (z.B. Wiki-Seiten oder Veröffentlichungsseiten).
4. Kopieren der Datei: Kopieren Sie die benötigte ASPX-Datei an einen sicheren Ort.
Diese Methode ist nur für Dateien anwendbar, die nicht in der Inhaltsdatenbank gespeichert sind.
Methode 3: Versionsverlauf und Papierkorb (bei versehentlicher Löschung oder Änderung)
Manchmal ist der „Absturz” keine technische Katastrophe, sondern eine versehentliche Löschung oder eine fehlerhafte Änderung, die das System zum Absturz bringt (z.B. Syntaxfehler in einer angepassten ASPX).
1. Erster Papierkorb: SharePoint verfügt über einen ersten Papierkorb für jede Website-Sammlung. Wenn die Seite vor Kurzem gelöscht wurde, kann sie hier wiederhergestellt werden. Navigieren Sie zu den Websiteinhalten und dann zum Papierkorb.
2. Zweiter Papierkorb (Administratoren-Papierkorb): Wenn die Datei aus dem ersten Papierkorb gelöscht wurde, wandert sie in den zweiten Papierkorb, auf den nur Website-Sammlungsadministratoren zugreifen können. Dieser befindet sich unter `/_layouts/15/AdminRecycleBin.aspx` (passen Sie die 15 an Ihre Version an).
3. Versionsverlauf: Wenn die ASPX-Datei in einer Seitenbibliothek gespeichert war und die Versionsverwaltung aktiviert ist, können Sie frühere Versionen der Datei wiederherstellen. Gehen Sie zur Bibliothek, wählen Sie die Datei aus, klicken Sie auf „Versionsverlauf” und stellen Sie eine frühere Version wieder her.
Diese Methoden sind nützlich, wenn die SharePoint-Umgebung zumindest teilweise funktionsfähig ist oder nach einer grundlegenden Wiederherstellung des Systems angewendet werden kann.
Methode 4: Source Control und Entwicklungs-Backups
Für benutzerdefinierte ASPX-Dateien, die von Entwicklern erstellt wurden, sollte der beste und einfachste Weg die Quellcodeverwaltung (z.B. Git, Azure DevOps, TFS) sein.
1. Suchen in der Quellcodeverwaltung: Wenn Ihre Entwicklungsrichtlinien solide sind, finden Sie die neueste funktionierende Version der ASPX-Datei in Ihrem Source Control Repository.
2. Lokale Kopien des Entwicklers: Als letzte Instanz können Entwickler oft lokale Kopien auf ihren Entwicklungsmaschinen haben, die als Backup dienen könnten.
Dies unterstreicht die Wichtigkeit robuster Entwicklungsprozesse und der Verwendung von Source Control für alle SharePoint-Anpassungen.
Schritt-für-Schritt-Anleitung: ASPX-Datei aus Inhaltsdatenbank-Backup exportieren
Nehmen wir an, Sie haben ein Backup Ihrer Inhaltsdatenbank und möchten eine spezifische ASPX-Datei aus einer Seitenbibliothek wiederherstellen.
**Szenario:** Ihr SharePoint-Server ist teilweise oder ganz ausgefallen, aber Sie haben ein Backup Ihrer Inhaltsdatenbank und können einen SQL Server sowie eine temporäre SharePoint-Farm aufsetzen.
1. **Backup bereitstellen:** Stellen Sie sicher, dass Ihr Inhaltsdatenbank-Backup (z.B. `Content_SharePointDB.bak`) auf einem SQL Server verfügbar ist.
2. **SQL Server Management Studio:**
* Verbinden Sie sich mit Ihrem SQL Server.
* Klicken Sie mit der rechten Maustaste auf `Datenbanken` -> `Datenbank wiederherstellen…`.
* Wählen Sie `Gerät` und navigieren Sie zur `.bak`-Datei Ihres Backups.
* Geben Sie der wiederhergestellten Datenbank einen eindeutigen Namen, z.B. `Wiederherstellungs_ContentDB`.
* Stellen Sie die Datenbank wieder her.
3. **SharePoint Management Shell (auf temporärer Farm):**
* Führen Sie die Shell als Administrator aus.
* **Erstellen Sie eine temporäre Webanwendung** (optional, wenn Sie bereits eine leere haben):
„`powershell
$appPool = New-SPServiceApplicationPool -Name „TempRecoveryAppPool” -Account (Get-SPManagedAccount „DOMAINsp_farm_account”)
$webApp = New-SPWebApplication -Name „TempRecoveryWebApp” -ApplicationPool $appPool -Port 8000 -URL „http://temp-sharepoint:8000” -DatabaseName „Temp_WebApp_ConfigDB” -DatabaseServer „SQLSERVERNAME”
„`
* **Entfernen Sie die Standard-Inhaltsdatenbank** der temporären Webanwendung, um Platz für Ihr Backup zu schaffen:
„`powershell
Get-SPContentDatabase -WebApplication $webApp | Remove-SPContentDatabase -Confirm:$false
„`
* **Mounten Sie die wiederhergestellte Inhaltsdatenbank** im schreibgeschützten Modus:
„`powershell
Mount-SPContentDatabase -Name „Wiederherstellungs_ContentDB” -WebApplication $webApp -AssignNewDatabaseId -Verbose
„`
Prüfen Sie die Ausgabe. Sollten Fehler auftreten, stellen Sie sicher, dass die SQL Server-Version und SharePoint-Patches kompatibel sind.
* **Suchen Sie die gewünschte Website-Sammlung:**
„`powershell
Get-SPSite -ContentDatabase „Wiederherstellungs_ContentDB”
„`
Notieren Sie sich die URL der Website-Sammlung, die Ihre ASPX-Datei enthält (z.B. `http://temp-sharepoint:8000/sites/MyCriticalSite`).
* **Extrahieren der ASPX-Datei:**
„`powershell
$site = Get-SPSite „http://temp-sharepoint:8000/sites/MyCriticalSite”
$web = $site.RootWeb # Oder Get-SPWeb -Identity $site.Url | Get-SPWeb -RelativeUrl „MySubWeb” für eine Unterwebsite
$file = $web.GetFile(„Seiten/IhreWichtigeSeite.aspx”) # Passen Sie den Pfad an: z.B. „SitePages/Home.aspx”
$fileBytes = $file.OpenBinary()
[System.IO.File]::WriteAllBytes(„C:RecoveryIhreWichtigeSeite.aspx”, $fileBytes)
$site.Dispose()
„`
Überprüfen Sie den `C:Recovery`-Ordner auf die extrahierte Datei.
* **Aufräumen:** Entfernen Sie die temporäre Inhaltsdatenbank und die Webanwendung, wenn Sie fertig sind.
„`powershell
Dismount-SPContentDatabase „Wiederherstellungs_ContentDB”
Remove-SPContentDatabase -Identity „Wiederherstellungs_ContentDB” -Confirm:$false
Remove-SPWebApplication -Identity $webApp -Confirm:$false
„`
Prävention ist der beste Schutz: Best Practices für SharePoint Disaster Recovery
Die beste Rettung ist die, die man nicht braucht. Eine solide Disaster Recovery-Strategie ist unerlässlich für jedes SharePoint OnPrem-Deployment.
* Regelmäßige Backups: Führen Sie vollständige Farm-Backups, aber insbesondere separate Inhaltsdatenbank-Backups durch. Testen Sie diese Backups regelmäßig, indem Sie sie in einer Testumgebung wiederherstellen.
* Quellcodeverwaltung: Alle benutzerdefinierten Entwicklungen (Webparts, Event Receiver, Masterpages, Layouts, ASPX-Dateien) sollten in einem Source Control System wie Git oder Azure DevOps verwaltet werden.
* Versionsverwaltung in Bibliotheken: Aktivieren Sie die Versionsverwaltung für Dokumentbibliotheken und Seitenbibliotheken, um unbeabsichtigte Änderungen oder Löschungen rückgängig machen zu können.
* Dokumentation: Dokumentieren Sie alle Anpassungen, ihre Speicherorte und ihren Zweck. Dies beschleunigt die Notfall-Rettung erheblich.
* Testumgebung: Pflegen Sie eine aktuelle Testumgebung, die der Produktion so ähnlich wie möglich ist, um Wiederherstellungsszenarien zu üben.
Fazit
Der Verlust einer kritischen ASPX-Datei durch einen SharePoint-Absturz kann eine stressige Situation sein. Doch mit dem richtigen Wissen und den richtigen Werkzeugen ist die Wiederherstellung von SharePoint-Daten in vielen Fällen möglich. Die wichtigste Lehre ist jedoch, dass proaktive Maßnahmen wie regelmäßige Backups, eine sorgfältige Quellcodeverwaltung und eine gut dokumentierte Disaster Recovery-Strategie der beste Schutz vor solchen Katastrophen sind. Nehmen Sie sich die Zeit, diese Best Practices zu implementieren, und Sie werden viel ruhiger schlafen können, wissend, dass Sie auf den Ernstfall vorbereitet sind.