Costa Sano MediaWiki – Survivability and Continuity Plan

Purpose

This document explains how the system remains operational for many years with:

limited budget
volunteer maintenance
hardware replacement
possible administrator change

The focus is continuity, not features.

Historical background

Experience has shown that data loss can be catastrophic.

In the past, insufficient backups caused:

equipment loss
weeks of redevelopment work
high financial cost

Therefore survivability is a primary design requirement.

Backups and portability are not optional.

Core strategy

The system must be:

rebuildable
portable
independent
well documented

No single component should be irreplaceable.

3-2-1 Backup Strategy

Always maintain:

3 copies of data
2 different media types
1 off-site copy

This policy has been used successfully for decades and must continue.

Backups include:

VM images
database dumps
uploaded files
configuration files

Virtual Machines

All services run inside VMs.

Benefits:

hardware independence
easy migration
snapshot capability
fast recovery
simple replication

If hardware fails: → copy VM → boot → continue

No reinstall required.

Hardware Independence

The system must run on:

old PCs
small servers
consumer hardware

No specialised hardware required.

This reduces cost and ensures availability of replacement parts.

Software Independence

Avoid:

paid licenses
proprietary platforms
cloud lock-in
subscriptions

Use:

Linux
MediaWiki
MariaDB
Apache
WordPress

All are free and long-term stable.

Migration Plan (future)

Today

Hyper-V + Windows Server

Possible future

Proxmox or Linux hypervisor

Because:

no licenses
lower cost
simpler maintenance

Migration is easy due to VM architecture.

Disaster Recovery Procedure (summary)

If total failure occurs:

Install hypervisor
Restore VM images
Start database
Start web server
Test access

Target: System operational within one day.

Knowledge Transfer

Survivability also depends on people.

Therefore:

document everything in ICT:
avoid complex tricks
keep configuration readable
follow consistent patterns

A successor should understand the system quickly.

Golden Rules for Future Maintainers

Do:

keep backups running
keep documentation updated
keep architecture simple
reuse existing patterns

Do NOT:

introduce unnecessary complexity
depend on paid software
mix many new technologies
redesign without strong reason

Final Philosophy

The goal is not the newest technology.

The goal is:

A system that quietly works for the next 10 years.

Boring, simple systems survive.

That is success.