Windows Server – Backup & Restore

Warum Backups auf dem Server noch wichtiger sind als auf dem PC

Ein Workstation-Absturz ist unangenehm. Ein Server-Absturz ohne Backup ist ein Unternehmensproblem. Auf einem typischen KMU-Server liegen Dateifreigaben, Active-Directory-Datenbanken, ERP-Daten, vielleicht noch Exchange – kurz: alles, was die Firma braucht, um zu arbeiten.

RAID ist kein Backup. RAID schuetzt vor Festplattenausfall, aber nicht vor:

• versehentlichem Loeschen von Dateien oder ganzen Ordnern
• Ransomware (die verschluesselt alle Volumes synchron)
• Fehlkonfigurationen und kaputten Systemupdates
• Brand oder Diebstahl des Servers

Die 3-2-1-Regel auf Server-Niveau

Die Grundlagen der Regel sind in Backup-Strategie: die 3-2-1-Regel ausfuehrlich erklaert. Auf Server-Ebene sieht das konkret so aus:

Fuer KMU ist eine pragmatische Loesung: Lokales Backup auf ein NAS im selben Gebaeude (fuer schnelle Wiederherstellung) + Cloud-Backup (fuer Disaster Recovery).

Die Weiterentwicklung: 3-2-1-1-0

Seit Ransomware gezielt Backup-Repositories und Schattenkopien mitloescht, reicht die klassische Regel nicht mehr. Die erweiterte Fassung ergaenzt zwei Punkte:

Details zur technischen Umsetzung der Immutable-Kopie folgen weiter unten und vertieft in Veeam Immutable Backup gegen Ransomware.

RPO und RTO: Was willst du versprechen?

Bevor du irgendetwas konfigurierst, klaer diese zwei Fragen mit dem Geschaeftsfuehrer oder IT-Verantwortlichen:

• RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel? Wenn RPO = 4 Stunden, muss alle 4 Stunden ein Backup laufen.
• RTO (Recovery Time Objective): Wie lange darf der Server ausfallen? RTO = 2 Stunden bedeutet, du musst innerhalb von 2 Stunden alles wiederhergestellt haben.

Ein Backup-Job, der einmal täglich laeuft und auf Band gespeichert ist, passt nicht zu RTO = 2 Stunden. Das muss vorher stimmen.

Windows Server Backup – das eingebaute Tool

Windows Server Backup (WSB) ist kostenlos, laeuft auf jedem Windows Server und reicht fuer viele KMU-Szenarien. Es unterstuetzt:

• Volume-Backups (ganzes Laufwerk)
• Systemstate-Backup (AD, Registry, COM+, SYSVOL)
• Bare Metal Recovery (BMR) – Wiederherstellung auf neuer Hardware
• Einzeldatei-Wiederherstellung

Feature installieren

WSB ist nicht standardmaessig aktiv. Installation ueber Server Manager oder PowerShell:

# Feature installieren
Install-WindowsFeature -Name Windows-Server-Backup -IncludeManagementTools

# Pruefen ob es geklappt hat
Get-WindowsFeature Windows-Server-Backup

Oder per Server Manager: Rollen und Features hinzufuegen > Features > Windows Server-Sicherung anhaaken.

Backup per GUI einrichten

1. Server Manager > Tools > Windows Server-Sicherung (wbadmin.msc)
2. Links: Lokale Sicherung > rechts: Sicherungszeitplan
3. Sicherungskonfiguration: Vollstaendiger Server (empfohlen) oder benutzerdefiniert
4. Sicherungszeit festlegen (z.B. 02:00 Uhr)
5. Ziellaufwerk auswaehlen: dediziertes Backup-Volume (kein Produktivlaufwerk!)
6. Bestaetigen und speichern

Backup per wbadmin (Kommandozeile)

wbadmin laeuft als erhoehte Eingabeaufforderung (Als Administrator ausfuehren). Ideal fuer Skripting oder Server Core.

:: Einmaliges vollstaendiges Backup auf Laufwerk F:
wbadmin start backup -backupTarget:F: -allCritical -quiet

:: Systemstate-Backup (fuer Active Directory unverzichtbar)
wbadmin start systemstatebackup -backupTarget:F: -quiet

:: Verfuegbare Backup-Versionen anzeigen
wbadmin get versions

:: Status eines laufenden Backups pruefen
wbadmin get status

:: Backup abbrechen
wbadmin stop job

Der Parameter -allCritical sorgt dafuer, dass alle fuer das OS notwendigen Volumes mitgesichert werden – also Windows, Bootpartition, System Reserved und EFI. Das ist die Mindestanforderung fuer eine spaetere Bare-Metal-Wiederherstellung.

Backup per PowerShell (WindowsServerBackup-Modul)

# Modul laden (nach Feature-Installation verfuegbar)
Import-Module WindowsServerBackup

# Alle verfuegbaren Cmdlets anzeigen
Get-Command -Module WindowsServerBackup

# Backup-Policy erstellen: alle kritischen Volumes auf Volume E:
$Policy = New-WBPolicy
$BackupLocation = New-WBBackupTarget -VolumePath E:
Add-WBBackupTarget -Policy $Policy -Target $BackupLocation
Set-WBVssBackupOption -Policy $Policy -VssFull
Add-WBBareMetalRecovery -Policy $Policy
Set-WBSchedule -Policy $Policy -Schedule 02:00

# Policy anwenden
Set-WBPolicy -Policy $Policy

# Manuellen Backup-Job starten
Start-WBBackup -Policy $Policy

Systemstate-Backup: Pflicht bei Active Directory

Wenn dein Server ein Domain Controller ist, brauchst du zusaetzlich zum normalen Backup zwingend ein Systemstate-Backup. Darin ist die AD-Datenbank (ntds.dit), SYSVOL und die Registry enthalten.

# Systemstate in Backup-Policy aufnehmen
$Policy = Get-WBPolicy
Add-WBSystemState -Policy $Policy
Set-WBPolicy -Policy $Policy

Ohne Systemstate-Backup ist eine AD-Wiederherstellung nach einem Totalverlust extrem aufwaendig bis unmoeglich. Systemstate-Backups gelten maximal so lange wie die Tombstone-Lifetime des Forests – bei allen seit Windows Server 2003 SP1 erstellten Forests standardmaessig 180 Tage, bei sehr alten, nie angepassten Forests teils nur 60 Tage. Danach werden geloeschte Objekte (Tombstones) endgueltig aus der AD-Datenbank entfernt und ein aelteres Backup fuehrt beim Einspielen zu einem inkonsistenten, nicht replizierbaren DC.

# Aktuelle Tombstone-Lifetime des Forests pruefen
Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=ch" `
  -Partition "CN=Configuration,DC=contoso,DC=ch" -Property tombstoneLifetime |
  Select-Object tombstoneLifetime

Vollstaendiges AD-Forest-Recovery-Runbook

Ein einzelner kaputter DC ist ein Restore. Ein komplett verlorener oder durchgehend kompromittierter Forest (z.B. nach einem Ransomware-Befall mit DCSync/Golden-Ticket) ist ein Projekt mit eigenem Ablaufplan. Das folgende Runbook orientiert sich am offiziellen AD Forest Recovery Guide von Microsoft (unten verlinkt) und fasst die Schritte praxisnah zusammen. Drucke ihn aus oder lagere ihn ausserhalb des ADs (z.B. im Passwort-Tresor) – wenn AD down ist, ist auch dein Wiki wahrscheinlich nicht erreichbar.

1. Schadensbeurteilung und Containment Welche DCs sind betroffen? Gibt es noch einen sauberen, isolierbaren DC? Netzwerk segmentieren, betroffene Server vom Netz trennen, Vorfall dokumentieren (siehe Incident-Response-Plan fuer KMU).

2. Tombstone-Grenze pruefen Nur Backups verwenden, die juenger sind als die Tombstone-Lifetime (siehe oben). Aeltere Systemstate-Backups sind fuer eine Wiederherstellung wertlos.

3. Ersten DC in isoliertem Netzwerksegment wiederherstellen Idealerweise den Forest-Root-DC mit der PDC-Emulator-Rolle. Wiederherstellung per Bare Metal Recovery oder Systemstate-Restore (wbadmin start systemstatebackup / -sysrecovery), aber in einem VLAN ohne Gateway und ohne Verbindung zu Clients oder anderen DCs. So verhinderst du, dass ein wiederhergestellter, aber noch veralteter DC Replikationsfehler oder USN-Rollbacks in die Produktion traegt.

4. In den Verzeichnisdienste-Wiederherstellungsmodus (DSRM) booten

:: DSRM beim naechsten Neustart erzwingen
bcdedit /set safeboot dsrepair
shutdown /r /t 0

Anmeldung im DSRM erfolgt mit dem lokalen DSRM-Administrator-Konto und -Passwort (festgelegt bei der DC-Promotion). Falls unbekannt, im Normalbetrieb vorher zuruecksetzen:

ntdsutil "set dsrm password" "reset password on server null" q q

5. Autoritative Wiederherstellung einzelner Objekte/OUs (falls noetig) Ein normaler Systemstate-Restore ist standardmaessig nicht-autoritativ – die wiederhergestellten Objekte wuerden bei der naechsten Replikation von den (noch aelteren, aber “neueren” laut USN) Partnern ueberschrieben. Sollen geloeschte oder durch Ransomware manipulierte Objekte gezielt zurueckgeholt werden, braucht es eine autoritative Wiederherstellung per ntdsutil:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "OU=Vertrieb,DC=contoso,DC=ch"
quit
quit

ntdsutil erhoeht die Versionsnummer der betroffenen Objekte automatisch um 100’000 pro seit dem Backup vergangenem Tag, damit sie sich gegenueber den anderen DCs durchsetzen. Eine autoritative Wiederherstellung der gesamten Datenbank (restore database) ist nur im absoluten Ausnahmefall sinnvoll – im Normalfall reicht restore subtree oder restore object fuer einzelne Objekte.

6. DSRM verlassen und normal starten

bcdedit /deletevalue safeboot
shutdown /r /t 0

7. krbtgt-Kennwort zweimal zuruecksetzen Vor allem nach einer Kompromittierung zwingend, um Golden-Ticket-Angriffe zu unterbinden. Zwischen den zwei Resets muss die Replikation an alle DCs abgeschlossen sein (sonst gibt es Kerberos-Fehler):

Reset-ADAccountPassword -Identity krbtgt
# warten bis vollstaendig repliziert (repadmin /replsummary), dann:
Reset-ADAccountPassword -Identity krbtgt

8. Metadaten-Cleanup fuer nicht wiederherstellbare DCs Verhindert Lingering Objects und Replikationsfehler durch tote DC-Objekte:

ntdsutil
metadata cleanup
connections
connect to server DC01
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers in site 0
select server 1
quit
remove selected server
quit
quit

9. Restliche DCs neu aufsetzen statt aus altem Backup wiederherstellen Weitere DCs per sauberer Neuinstallation und anschliessender Replikation aus dem wiederhergestellten DC hinzufuegen – nicht aus einem eigenen, moeglicherweise noch aelteren Backup. Das vermeidet einen USN-Rollback (DC “vergisst” Aenderungen, weil seine USN-Zaehler zurueckspringen).

10. FSMO-Rollen, DNS und Netzwerk schrittweise validieren

netdom query fsmo
dcdiag /v
repadmin /replsummary
repadmin /showrepl

Erst wenn dcdiag und repadmin sauber durchlaufen, Clients und weitere Netzwerksegmente schrittweise wieder anschliessen.

Wiederherstellung – so geht’s

Einzelne Dateien/Ordner wiederherstellen

1. wbadmin.msc > Wiederherstellung
2. Sicherungsversion auswaehlen (Datum/Uhrzeit)
3. Dateien und Ordner auswaehlen
4. Zielordner angeben (original oder anderer Pfad)
5. Fertigstellen

Oder per wbadmin:

:: Verfuegbare Versionen zeigen (Identifier notieren)
wbadmin get versions

:: Einzelne Dateien aus einer Version wiederherstellen
wbadmin start recovery -version:06/23/2026-02:00 -itemType:File -items:D:\Freigaben\Projekte\Bericht.docx -recursive -overwrite:yes

Bare Metal Recovery (BMR) – Wiederherstellung auf neuer Hardware

Wenn der Server physisch kaputt ist oder auf neue Hardware umgezogen werden soll:

1. Windows Server Installationsmedium booten (USB oder ISO)
2. Bei der Sprachauswahl: Computerreparaturoptionen (unten links)
3. Problembehandlung > System Image Recovery (oder wbadmin start sysrecovery in der Wiederherstellungskonsole)
4. Backup-Quelle auswaehlen (lokales Laufwerk, Netz, oder externes Medium)
5. Version auswaehlen und Wiederherstellung starten

:: In der Windows Recovery Environment (WinRE) – nicht im normalen Betrieb
wbadmin start sysrecovery -version:06/23/2026-02:00 -backupTarget:F: -quiet

Der Prozess dauert je nach Datenmenge 30 Minuten bis mehrere Stunden. Danach bootet der Server in den Zustand zum Zeitpunkt des Backups.

Veeam als Alternative (empfohlen fuer KMU)

Fuer etwas mehr Komfort, VM-Backups und zentrales Monitoring empfehle ich Veeam Backup & Replication Community Edition – kostenlos fuer bis zu 10 Workloads.

Vorteile gegenueber Windows Server Backup:

• Zentrales Dashboard mit Backup-Status aller Jobs
• Granulare Wiederherstellung einzelner AD-Objekte, SQL-Datenbanken
• E-Mail-Benachrichtigungen bei Fehlern
• Direktes Backup in Cloud (Azure, S3-kompatibel)
• Tape-Unterstuetzung

Veeam-Backup fuer physischen Server einrichten

1. Veeam installieren (auf dem Backup-Server, nicht dem Produktivserver)
2. Backup Infrastructure > Add Server > Produktivserver hinzufuegen
3. Home > Backup Job > Windows/Linux Computer
4. Backup-Repository auswaehlen (NAS, lokale HDD, Cloud)
5. Zeitplan und Aufbewahrungsrichtlinie setzen (z.B. 14 Wiederherstellungspunkte)

Immutable und Air-Gapped Backups gegen Ransomware

Moderne Ransomware sucht gezielt nach Backup-Repositories, Schattenkopien und Veeam-Servern und loescht oder verschluesselt sie zuerst – ein normales, jederzeit loeschbares Backup schuetzt dann nicht mehr. Die Antwort darauf ist Immutability: mindestens eine Backup-Kopie, die fuer einen definierten Zeitraum von niemandem – auch nicht von einem kompromittierten Domain-Admin-Konto – veraendert oder geloescht werden kann. Eine vollstaendige Vertiefung dazu findest du unter Veeam Immutable Backup gegen Ransomware; hier die wichtigsten Bausteine im Ueberblick.

Veeam Hardened Repository

Ein Hardened Repository ist ein gehaerteter Linux-Server (empfohlen: XFS-Dateisystem wegen Block-Cloning/Fast-Clone), auf dem Veeam Backup-Dateien per chattr-Immutable-Flag schuetzt. Selbst root auf dem Linux-Server kann die Dateien waehrend der Immutability-Periode nicht loeschen.

Kurzablauf der Einrichtung:

1. Dedizierten Linux-Host (Rocky Linux/RHEL, minimal, keine weiteren Dienste) bereitstellen, Root-SSH-Zugriff nur temporaer fuer die Ersteinrichtung erlauben
2. In Veeam: Backup Infrastructure > Repositories > Add Repository > Direct Attached Storage > Linux
3. Server per SSH hinzufuegen, XFS-Volume auswaehlen
4. Option “Make recent backups immutable for X days” aktivieren und Immutability-Periode setzen (z.B. 14 Tage)
5. Backup-Job muss Forward Incremental mit Active oder Synthetic Full verwenden (Reverse Incremental ist mit Immutability nicht kompatibel)

Object Lock (S3-Immutability)

Alternativ oder zusaetzlich unterstuetzt Veeam S3-kompatible Object Storage (AWS S3, Wasabi, Backblaze B2, MinIO) mit S3 Object Lock als Immutability-Mechanismus:

• Compliance Mode – strikteste Variante, niemand (auch nicht der Storage-Account-Owner) kann die Aufbewahrungsfrist verkuerzen oder Objekte vorzeitig loeschen. Von Veeam standardmaessig verwendet.
• Governance Mode – Objekte sind ebenfalls gesperrt, aber Nutzer mit speziellen Rechten koennen die Sperrfrist aendern oder aufheben. Muss in Veeam per Registry-Schluessel S3GovernanceImmutabilityMode (unter HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication) explizit aktiviert werden – gilt dann serverweit fuer alle S3-Repositories.

Bucket-Konfiguration (am Beispiel AWS-CLI):

# Versionierung aktivieren (Object Lock erfordert Versionierung)
aws s3api put-bucket-versioning --bucket kmu-backup-immutable \
  --versioning-configuration Status=Enabled

# Object Lock beim Erstellen des Buckets aktivieren
aws s3api create-bucket --bucket kmu-backup-immutable \
  --object-lock-enabled-for-bucket

# Wichtig: Object-Lock-Konfiguration auf dem Bucket selbst auf "None" lassen –
# Veeam verwaltet die Retention pro Objekt beim Hochladen selbst

In Veeam wird der Bucket anschliessend als Object Storage Repository hinzugefuegt; die Immutability-Periode wird beim Erstellen des Backup-Jobs bzw. der Scale-Out-Repository-Extent-Konfiguration festgelegt.

Air-Gap als zusaetzliche Schicht

Immutability schuetzt vor Loeschen, aber die Kopie bleibt netzwerkerreichbar. Ein echter Air-Gap trennt die Kopie physisch oder logisch komplett vom Netz:

• Tape (LTO) – nach dem Backup-Job wird die Kassette ausgeworfen und im Tresor gelagert, kein Netzwerkzugriff moeglich
• Wechseldatentraeger, die nach dem Job explizit ausgesteckt werden (Rotation von 2-3 Festplatten)
• Cloud-Tiering mit separaten, restriktiven Zugangsdaten, die nicht im selben Tenant/derselben AD-Domaene wie die Produktivumgebung verwaltet werden

Fuer ein KMU ist eine pragmatische Kombination: Hardened Repository oder Object Lock als “immer verfuegbare” immutable Kopie plus eine wöchentliche Air-Gap-Rotation auf externe Platte oder Tape fuer den Worst Case.

Backup-Verschluesselung und Aufbewahrungspflichten in der Schweiz

Verschluesselung

Backups enthalten oft die sensibelsten Daten im ganzen Unternehmen – Personalakten, Kundendaten, AD-Datenbank mit Passwort-Hashes. Zwei Ebenen gehoeren dazu:

• Transportverschluesselung: TLS zwischen Backup-Server und Ziel (Cloud-Repository, Offsite-NAS)
• Verschluesselung im Ruhezustand: In Veeam auf Job-Ebene aktivierbar (Backup Job > Storage > Advanced > Storage > “Enable backup file encryption”, AES-256). Fuer Windows Server Backup gibt es keine native Backup-Verschluesselung – dort das Zielvolume per BitLocker verschluesseln.

Aufbewahrungspflichten nach revDSG/FADP

Das revidierte Schweizer Datenschutzgesetz (revDSG, seit 1.9.2023 in Kraft) verlangt in Art. 8 “angemessene technische und organisatorische Massnahmen” zum Schutz von Personendaten – Verschluesselung und Zugriffskontrolle auf Backups gehoeren explizit dazu. Gleichzeitig gilt der Grundsatz der Datenminimierung: Personendaten duerfen nicht laenger aufbewahrt werden als noetig.

Das kollidiert in der Praxis mit gesetzlichen Aufbewahrungspflichten fuer Geschaeftsunterlagen (Obligationenrecht Art. 958f: 10 Jahre fuer Buchhaltungsunterlagen). Fuer die Backup-Praxis heisst das:

• Aufbewahrungsfristen der Backup-Policy dokumentieren und begruenden (welche Daten muessen wie lange aufbewahrt werden und warum)
• Kurze Retention fuer operative Backups (Tage bis Wochen) von Langzeit-Archiven fuer buchhaltungsrelevante Daten (Jahre) trennen
• Loeschkonzept auch fuer Backups definieren – ein Recht auf Loeschung nuetzt wenig, wenn die Daten in einem 5 Jahre alten Backup unveraendert weiterleben

Eine vertiefte, rechtliche Einordnung inklusive Meldepflichten bei Datenschutzverletzungen findest du unter DSGVO/nDSG in der IT-Praxis.

Anwendungs-aware Backups: SQL Server und Exchange

Ein reines Datei- oder Volume-Backup reicht bei Datenbank-Workloads nicht: Waehrend des Backups laufen Transaktionen weiter, offene Dateien sind inkonsistent. Die Loesung ist der VSS-Writer-Mechanismus (Volume Shadow Copy Service) – Anwendungen wie SQL Server und Exchange registrieren einen eigenen Writer, der beim Schattenkopie-Erstellen kurz “einfriert”, damit ein konsistenter Snapshot entsteht.

# Registrierte VSS-Writer und ihren Status pruefen
vssadmin list writers

Relevante Writer:

Veeam Application-Aware Processing nutzt diese Writer aktiv: Es fuehrt nicht nur einen VSS-Snapshot durch, sondern kuerzt nach erfolgreichem Backup die Transaktionslogs von SQL Server und Exchange (analog zu einer nativen vollstaendigen Sicherung). Aktivierbar unter Backup Job > Guest Processing > “Enable application-aware processing”.

Windows Server Backup allein sichert SQL- und Exchange-VSS-Writer zwar mit (sofern -allCritical bzw. Volume-Auswahl passt), truncatet aber die Transaktionslogs nicht zuverlaessig granular pro Datenbank – fuer produktive SQL-/Exchange-Server ist ein anwendungsbewusstes Tool wie Veeam oder eine native Sicherung deutlich robuster.

Backup-Test: Die wichtigste Aufgabe

Ein Backup, das nie getestet wurde, ist kein Backup. Plane feste Test-Intervalle:

Dokumentiere jeden Test im Ticketsystem oder als Checkliste. Falls ein Kunde oder Vorgesetzter fragt, willst du Beweise haben.

Isolated Recovery Environment: Restores gefahrlos testen

Ein Restore-Test in der Produktivumgebung ist riskant, wenn das Backup selbst bereits verschluesselte oder mit Malware infizierte Dateien enthaelt – ein zu frueh eingespielter Restore kann die Produktion reinfizieren. Die Loesung ist eine Isolated Recovery Environment (IRE): ein Netzwerksegment ohne Verbindung zu Produktiv-DNS, -DHCP oder -Gateway, in dem Restores erst validiert werden, bevor sie “scharf geschaltet” werden.

Praktische Umsetzung je nach Budget:

• Veeam SureBackup: startet wiederhergestellte VMs automatisiert in einer isolierten virtuellen Lab-Umgebung, prueft Boot-Faehigkeit, Anwendungsdienste und optional per Skript die Applikationslogik – ohne dass die VM je mit dem Produktivnetz verbunden wird
• Veeam Secure Restore: scannt Wiederherstellungspunkte vor dem eigentlichen Restore mit einer Antiviren-Engine (z.B. Windows Defender) auf Schadsoftware und bricht bei Fund ab
• Minimalvariante fuer kleine KMU: ein dedizierter, physisch getrennter Hyper-V-Host oder ein VLAN ohne Routing-Eintrag (kein Gateway, keine DNS-Weiterleitung zu Produktiv-DCs), in dem Restores manuell geprueft werden, bevor Daten zurueck in die Produktion kopiert werden

Troubleshooting haeufiger Backup-Probleme

VSS-Diagnose

VSS (Volume Shadow Copy Service) ist der Mechanismus, der konsistente Backups laufender Systeme ermoeglicht. Bei Problemen:

# VSS-Schreiber-Status pruefen
vssadmin list writers

# Alle Schattenkopien anzeigen
vssadmin list shadows

# VSS-Dienste neu starten
Restart-Service VSS
Restart-Service VDS

Schreiber im Zustand [8] Failed oder Waiting for completion verhindern konsistente Backups. Oft hilft ein Neustart des betreffenden Dienstes (z.B. SQL Server VSS Writer).

Weiterlernen

• Windows Server Backup – Befehlsreferenz (Microsoft Learn)
• wbadmin – Referenz aller Unterkommandos (Microsoft Learn)
• AD Forest Recovery – Vollstaendige Serverwiederherstellung (Microsoft Learn)
• Veeam Backup & Replication Community Edition – Dokumentation
• Systemstate und Bare Metal Recovery mit Azure Backup (Microsoft Learn)
• Veeam Hardened Repository – Dokumentation
• Veeam Immutability – Funktionsweise (Help Center)

Verwandte Seiten:

• Active Directory Grundlagen – was im Systemstate gesichert wird
• Windows Server Dateifreigaben – was auf dem Server schuetzenswert ist
• PowerShell im IT-Alltag – Backup-Jobs automatisieren und ueberwachen
• IT-Security Grundlagen fuer KMU – Ransomware-Schutz und immutable Backups
• Veeam Immutable Backup gegen Ransomware – Hardened Repository und Object Lock im Detail
• Backup-Strategie: die 3-2-1-Regel – Grundlagen der Backup-Strategie
• AD Security Hardening & Tier-Modell – Haertung nach einer Forest-Recovery
• DSGVO/nDSG in der IT-Praxis – Aufbewahrung und Datenschutz im Detail
• SQL Server Hochverfuegbarkeit fuer KMU – Datenbank-Verfuegbarkeit ueber Backup hinaus