Wiki Backup and Restore

A wiki holds knowledge. Losing it is bad. Backups exist to prevent the loss; restore tests confirm they work.

This page covers wiki-specific backup considerations.

What to back up

Page content

The actual wiki text. The most-obvious thing.

For file-based wikis (markdown in git), git provides this naturally.

For database-backed wikis, regular database dumps.

Page history

Older versions of pages. For wiki-specific revert needs.

For git-based wikis: git history.

For database-backed: depends on the wiki's storage.

Attachments

Uploaded images, documents, files. Often in a separate location.

For typical wikis: `attachments/` or similar directory; database BLOB columns; or external object storage.

User data

Accounts, roles, preferences. For database-backed wikis: the user table and associated.

For wikis using external auth (SSO, OAuth), the wiki itself may have less user data.

Configuration

Wiki settings, plugin configurations, themes, custom CSS, custom permissions.

Often in config files; sometimes in database.

Search index

For some wikis, the search index is large and slow to rebuild. Backing up saves time.

For others, the index is regenerable; back up the underlying data only.

Backup strategies

File-based wiki + git

Git provides versioning, history, and pseudo-backup. Push to remote git server (GitHub, GitLab, internal).

For attachments, git LFS or external storage.

This is the simplest case. The wiki content is naturally backed up.

Database-backed wiki

Standard database backup practices apply. See [DatabaseBackupStrategies](DatabaseBackupStrategies).

Plus: backup attachments separately.

Cloud-managed wiki

Confluence, Notion, etc. Provider backs up; you may have export options.

For data sovereignty, periodic exports to your own storage are valuable. Don't rely solely on the provider.

Restore testing

The most important practice. Backup that hasn't been restored is aspirational.

Test restore process

Periodically:

1. Spin up a test instance

2. Restore from a backup

3. Verify the wiki works

4. Check key pages, links, attachments

5. Tear down

For mature operations: automated.

Specific things to verify

- Pages are present and complete

- Attachments load

- Page history is accessible

- Links work

- Permissions correct

- Search works (or rebuilds correctly)

Practice incident response

Once a year: simulate "wiki is gone." Restore from backup. Time it. Learn what's broken.

This finds problems your normal testing misses.

What can go wrong

Backup happens but isn't tested

Backup runs nightly. Six months later, real disaster. Restore fails because of a bug introduced months ago.

Partial backup

Backed up content but not configuration. Restore brings content; wiki doesn't work.

Encryption key lost

Backup is encrypted; key is lost. Backup useless.

Manage backup encryption keys carefully; redundantly.

Corruption in source

Backup faithfully copies corruption. Need point-in-time recovery to before corruption.

Provider failure

Cloud-managed wiki provider fails. Provider's backups don't help if the provider is gone.

Hence: independent exports.

Specific patterns

Snapshot before major changes

Before plugin upgrade, schema migration, mass content changes: take an explicit snapshot. Easy rollback.

Multiple retention periods

Daily backups: 7 days

Weekly: 4 weeks

Monthly: 12 months

Annual: 7 years (compliance)

Cost-tiered: Standard for recent; Glacier for old.

Cross-region

DR ready. The wiki survives a region outage.

Granular restore

Sometimes you need to restore one page (deleted accidentally), not the whole wiki. Test this scenario.

Read-only backup site

A read-only mirror of the wiki at backup data. Useful as fallback during incidents.

Migration as planned restore

Migrating wikis (different platform; new server) is essentially a restore to a different target. The tooling overlaps.

Plan migrations using backup tools. See [WikiMigrationStrategies](WikiMigrationStrategies).

Common failure patterns

- **Backup not tested.** Doesn't restore when needed.

- **Same-region backups only.** Region outage; both gone.

- **No retention.** Eventually backups cycle out; can't recover from old corruption.

- **Manual backup steps.** Forgotten; missed.

- **Configuration not backed up.** Content restores; wiki doesn't work.

- **Slow restore.** Hours of downtime when minutes were possible.

A reasonable approach

For typical production wikis:

1. Automated daily backups

2. Automated cross-region replication

3. Quarterly restore tests

4. Annual full DR drill

5. Documented restore procedures

6. Backup configuration alongside content

7. Multiple retention tiers