Skip to content
Windows.HomesUnofficial

Backup and incident response for a Windows web server

Verified 1 min read

Back up config, content, certificates and data separately, test restore, and run a containment-to-recovery incident sequence.

Tested onStandard / Datacenter · Build 26100.33650 · x64
E1
Build
26100.33650
Edition
Standard / Datacenter
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Method

The short answer

Section titled “The short answer”

Back up separately:

  • Config — IIS applicationHost.config/site XML, Nginx conf, service definitions.
  • Content — site files and uploads (with ACLs).
  • Certificates — PFX + private keys, exportable and access-controlled.
  • Data — databases/app state, with a consistent backup method.
  • Secrets — vault/secret store, not a text file on the web root.

A VM snapshot is not a backup strategy: it is not off-host, not retention, and not a restore test.

IIS config

Section titled “IIS config”
Terminal window
C:\Windows\System32\inetsrv\appcmd.exe add backup "before-change"
C:\Windows\System32\inetsrv\appcmd.exe list backup

Copy backups off the server. Also back up site web.config and app pool identities (gMSA/custom accounts are external).

Restore test

Section titled “Restore test”

At least quarterly:

  1. Restore config to a clean VM.
  2. Restore content + ACLs.
  3. Import certificates.
  4. Start services; test Host header + HTTPS.
  5. Record RTO/RPO actuals.

A backup you have never restored is a hypothesis.

Incident response sequence

Section titled “Incident response sequence”
  1. Detect/validate — alerts, user report, unusual outbound.
  2. Contain — isolate the VM/network, disable compromised accounts, block IPs; preserve evidence.
  3. Eradicate — remove webshell/malware, patch the entry point, rotate credentials/keys.
  4. Recover — rebuild from trusted images/backups, restore data, verify integrity.
  5. Lessons — timeline, root cause, controls, owners.

Do not “clean” a compromised web server and put it back without understanding persistence (services, scheduled tasks, IIS modules, PHP extensions).

Runbook fields

Section titled “Runbook fields”
App:            api-a
RTO/RPO:        1h / 15m
Backups:        config nightly, content daily, DB 15m
Off-host:       yes (bucket/vault)
Restore test:   last date + result
Cert expiry:    date + owner
Contacts:       app owner / security / hosting

Lab boundary

Section titled “Lab boundary”

E1. The lab used PVE snapshots and appcmd backups but did not run a full restore or IR exercise. The runbook is the production plan for Server 2025.

Sources