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.
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.
Older versions of pages. For wiki-specific revert needs.
For git-based wikis: git history. For database-backed: depends on the wiki's storage.
Uploaded images, documents, files. Often in a separate location.
For typical wikis: attachments/ or similar directory; database BLOB columns; or external object storage.
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.
Wiki settings, plugin configurations, themes, custom CSS, custom permissions.
Often in config files; sometimes in database.
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.
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.
Standard database backup practices apply. See DatabaseBackupStrategies.
Plus: backup attachments separately.
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.
The most important practice. Backup that hasn't been restored is aspirational.
Periodically:
For mature operations: automated.
Once a year: simulate "wiki is gone." Restore from backup. Time it. Learn what's broken.
This finds problems your normal testing misses.
Backup runs nightly. Six months later, real disaster. Restore fails because of a bug introduced months ago.
Backed up content but not configuration. Restore brings content; wiki doesn't work.
Backup is encrypted; key is lost. Backup useless.
Manage backup encryption keys carefully; redundantly.
Backup faithfully copies corruption. Need point-in-time recovery to before corruption.
Cloud-managed wiki provider fails. Provider's backups don't help if the provider is gone.
Hence: independent exports.
Before plugin upgrade, schema migration, mass content changes: take an explicit snapshot. Easy rollback.
Daily backups: 7 days Weekly: 4 weeks Monthly: 12 months Annual: 7 years (compliance)
Cost-tiered: Standard for recent; Glacier for old.
DR ready. The wiki survives a region outage.
Sometimes you need to restore one page (deleted accidentally), not the whole wiki. Test this scenario.
A read-only mirror of the wiki at backup data. Useful as fallback during incidents.
Migrating wikis (different platform; new server) is essentially a restore to a different target. The tooling overlaps.
Plan migrations using backup tools. See WikiMigrationStrategies.
For typical production wikis: