💾 Backups

Backups zijn een essentieel onderdeel van de continuïteit van Tulpencraft.

Een Minecraft-server kan altijd opnieuw worden geïnstalleerd. De werelddata, configuraties, databasegegevens en andere unieke gegevens kunnen echter niet zomaar opnieuw worden opgebouwd.

Daarom worden backups gezien als een afzonderlijke beveiligingslaag naast de productieomgeving.

Het doel van backups is het kunnen herstellen van Tulpencraft na bijvoorbeeld:

• 🖥️ een defecte VM;
• 💾 storageproblemen;
• 🗑️ per ongeluk verwijderde bestanden;
• ⚙️ een foutieve configuratie;
• 🔌 een defecte plugin;
• 💥 een servercrash;
• 🦠 een beveiligingsincident;
• 👤 menselijke fouten;
• 🏗️ een migratie naar andere infrastructuur;
• 🖥️ verlies van een fysieke host.

De belangrijkste vraag bij backups is daarom niet:

“Hebben we een backup?”

maar:

“Kunnen we daadwerkelijk herstellen wanneer dat nodig is?”

Tulpencraft draait momenteel op de gedeelde Proxmox-host:

id="kz6n8a"

🖥️ hv002
│
├── 🖥️ mc-proxy001
│   ├── Velocity
│   ├── Lobby
│   ├── Database
│   └── overige diensten
│
├── 🎮 Survival VM
│
├── 🎯 Events VM
│
└── ➕ toekomstige VM's

De host beschikt over NVMe-storage.

De productiegegevens van Tulpencraft bevinden zich daardoor momenteel binnen de infrastructuur van hv002.

Dit betekent ook dat de Proxmox-host zelf geen ideale enige backupbestemming is.

Een Proxmox snapshot is niet hetzelfde als een backup.

Een snapshot kan handig zijn vóór een wijziging:

id="t3j8sk"

VM
 │
 ├── Snapshot vóór wijziging
 │
 └── Wijziging uitvoeren

Een backup is bedoeld om gegevens ook na een ernstiger incident te kunnen herstellen.

Bijvoorbeeld:

id="z7m2wk"

Productie
   │
   ▼
💾 Backup
   │
   ▼
📦 Afzonderlijke opslag

Een snapshot op dezelfde fysieke storage beschermt dus niet tegen het verlies van die storage.

Niet iedere VM hoeft noodzakelijkerwijs op exact dezelfde manier te worden geback-upt.

Voor Tulpencraft zijn vooral de volgende gegevens belangrijk.

De belangrijkste data van een Minecraft-server bestaat uit de werelddata.

Bijvoorbeeld:

id="yqv8d3"

/srv/minecraft/survival/world/
/srv/minecraft/survival/world_nether/
/srv/minecraft/survival/world_the_end/

Deze data is uniek en kan vaak niet opnieuw worden gegenereerd zonder voortgang van spelers te verliezen.

Ook configuratiebestanden zijn belangrijk.

Voorbeelden:

id="x3m7ah"

/srv/minecraft/survival/server.properties
/srv/minecraft/survival/config/
/srv/minecraft/survival/plugins/

Hierin kunnen onder andere instellingen van plugins, permissions en gameplay worden opgeslagen.

Plugin-JAR's zijn meestal opnieuw te downloaden.

Toch kunnen lokale pluginconfiguraties en data essentieel zijn.

Daarom is het verstandig om niet alleen de JAR-bestanden, maar de relevante pluginmappen mee te nemen.

De huidige database draait intern op:

id="8c5q7u"

mc-proxy001

Databasegegevens moeten onderdeel zijn van de backupstrategie.

Daarbij moet rekening worden gehouden met het verschil tussen:

• een volledige VM-backup;
• een database-dump;
• een consistente databasebackup.

Een databasebackup moet bij voorkeur worden gemaakt op een manier die de consistentie van de database waarborgt.

Voor een snelle recovery kunnen ook belangrijke systeemconfiguraties worden bewaard.

Denk bijvoorbeeld aan:

id="6s0g0j"

/etc/systemd/system/
/etc/firewalld/
/etc/ssh/
/etc/selinux/

Niet ieder bestand hoeft afzonderlijk te worden geback-upt wanneer de volledige VM wordt meegenomen.

Omdat Tulpencraft op Proxmox draait, ligt het voor de hand om VM's op VM-niveau te kunnen back-uppen.

Conceptueel:

id="t4f7ra"

             Proxmox
                │
       ┌────────┼────────┐
       │        │        │
       ▼        ▼        ▼
   Proxy VM  Survival  Events
       │        │        │
       └────────┼────────┘
                │
                ▼
             💾 Backup

Een volledige VM-backup kan een belangrijk hulpmiddel zijn bij disaster recovery.

Proxmox VE ondersteunt hiervoor onder andere integratie met Proxmox Backup Server. Voor VM's worden daarbij block-level backups gebruikt.

Een belangrijke regel is:

De backup moet onafhankelijk zijn van de productieomgeving.

Wanneer productie en backup op dezelfde fysieke storage staan, biedt de backup weinig bescherming tegen een fysiek storageprobleem.

Daarom is de gewenste architectuur bijvoorbeeld:

id="v2y8q4"

                 🖥️ hv002
                    │
              Tulpencraft VM's
                    │
                    ▼
                💾 Backup
                    │
                    ▼
          📦 Afzonderlijke storage

In een verdere volwassen infrastructuur kan dit bijvoorbeeld een afzonderlijke backupserver of Proxmox Backup Server zijn.

Een mogelijke toekomstige oplossing is Proxmox Backup Server (PBS).

PBS is specifiek ontworpen voor het maken en beheren van backups van Proxmox-omgevingen.

Een mogelijke architectuur:

id="5t9m9c"

             🖥️ Proxmox
                 │
        ┌────────┼────────┐
        │        │        │
        ▼        ▼        ▼
      Proxy   Survival   Events
        │        │        │
        └────────┼────────┘
                 │
                 ▼
        🗄️ Proxmox Backup Server
                 │
                 ▼
             💾 Backup

Hierdoor wordt de backupomgeving logisch en fysiek gescheiden van de productie-VM's.

Wanneer backups gevoelige gegevens bevatten, kan encryptie worden toegepast.

Proxmox ondersteunt client-side backup-encryptie met AES-256-GCM.

Daarbij geldt een belangrijke regel:

De encryptiesleutel mag niet uitsluitend op de productieserver worden bewaard.

Wanneer de server en de sleutel tegelijkertijd verloren gaan, kan de backup namelijk niet meer worden hersteld. Proxmox waarschuwt hier expliciet voor.

Een veilige situatie is bijvoorbeeld:

🖥️ Productie
      │
      ├── 💾 Encrypted backup
      │
      └── 🔑 Backup key
              │
              ▼
       🔐 Afzonderlijk
          beveiligd opgeslagen

Wanneer encrypted backups worden gebruikt, moeten encryptiesleutels afzonderlijk worden beheerd.

De sleutel hoort niet uitsluitend:

• op dezelfde VM;
• op dezelfde fysieke host;
• op dezelfde backupstorage;

te staan.

De sleutel moet beschikbaar zijn wanneer een restore noodzakelijk is.

Daarom moet bij de backupdocumentatie altijd worden vastgelegd:

• welke sleutel wordt gebruikt;
• waar deze veilig wordt bewaard;
• wie toegang heeft;
• hoe een restore met de sleutel wordt uitgevoerd.

De gewenste frequentie hangt af van het soort data.

Voorbeeld:

De exacte frequenties worden vastgesteld zodra de definitieve backupomgeving is ingericht.

Niet iedere backup hoeft permanent te worden bewaard.

Een retentiebeleid kan bijvoorbeeld bestaan uit:

id="m2j5s4"

Dagelijkse backups
      │
      ├── recente dagen
      │
      ▼
Wekelijkse backups
      │
      ├── langere termijn
      │
      ▼
Maandelijkse backups
      │
      └── langetermijnbewaring

Het exacte beleid wordt bepaald op basis van:

• beschikbare storage;
• belang van de data;
• herstelvereisten;
• groeisnelheid;
• kosten.

Proxmox Backup Server ondersteunt onder andere prune- en retentionbeleid voor het beheren van oude backups.

Een backup die nooit is getest, is geen gegarandeerde backup.

Daarom moet periodiek worden gecontroleerd of backups daadwerkelijk kunnen worden hersteld.

Een eenvoudige test:

id="j8a6qg"

💾 Backup
   │
   ▼
🖥️ Testomgeving
   │
   ▼
▶️ VM starten
   │
   ▼
🔎 Data controleren
   │
   ▼
✅ Restore geslaagd

Bij een restore-test wordt onder andere gecontroleerd:

• start de VM;
• start het operating system;
• zijn bestanden aanwezig;
• start Minecraft;
• zijn configuraties aanwezig;
• is de database beschikbaar;
• zijn werelden bruikbaar;
• functioneren plugins.

Bij een ernstig incident kan een volledige infrastructuurrestore noodzakelijk zijn.

Bijvoorbeeld wanneer:

id="2oz7t6"

🖥️ hv002
   │
   ▼
❌ verloren / onbeschikbaar
   │
   ▼
🗄️ Backup beschikbaar
   │
   ▼
🖥️ Nieuwe Proxmox-infrastructuur
   │
   ▼
💾 VM's herstellen
   │
   ▼
🎮 Tulpencraft opnieuw beschikbaar

Daarom moeten backups niet alleen bestanden bevatten, maar moet ook duidelijk zijn hoe de infrastructuur opnieuw wordt opgebouwd.

De OS-installatie, server-hardening en installatieprocedures worden daarom afzonderlijk gedocumenteerd in deze wiki.

Wanneer Tulpencraft groeit, kan de backuparchitectuur verder worden uitgebreid.

Een mogelijke toekomstige omgeving:

id="r5o2x1"

                 🖥️ Proxmox Node
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
   mc-proxy001    mc-db001       mc-lobby001
        │
        ▼
    Game servers
        │
        ▼
       🎮
        │
        └─────────────────────┐
                              │
                              ▼
                    🗄️ Backup Server
                              │
                              ▼
                       💾 Backup storage

Bij verdere groei kan eventueel een tweede fysieke locatie of externe backup worden toegevoegd.

Een backup op een andere fysieke locatie biedt bescherming tegen incidenten waarbij een volledige locatie verloren gaat.

Denk bijvoorbeeld aan:

• brand;
• stroomproblemen;
• fysieke schade;
• hardwarefalen;
• menselijke fouten;
• ransomware;
• verlies van de volledige hostingomgeving.

Een mogelijke volwassen backupstrategie is daarom:

🏢 Productie
    │
    ▼
🗄️ Lokale backup
    │
    ▼
🌍 Externe/off-site backup

Dit hoeft niet direct bij de start van Tulpencraft volledig te worden ingericht, maar vormt wel een mogelijk toekomstig onderdeel van de infrastructuur.

Backups zijn zelf een belangrijk beveiligingsobject.

Een backup kan immers dezelfde gevoelige gegevens bevatten als de productieomgeving.

Daarom gelden onder andere:

• 🔒 beperkte toegang;
• 🔑 sterke authenticatie;
• 🔐 encryptie waar nodig;
• 📋 logging van beheeractiviteiten;
• 🧹 gecontroleerde retentie;
• 🧪 periodieke restore-tests.

Een backup mag nooit worden beschouwd als een “veilige kopie” die zonder verdere beveiliging kan worden opgeslagen.

De backupomgeving moet zelf eveneens worden gemonitord.

Belangrijke controles zijn bijvoorbeeld:

• laatste succesvolle backup;
• leeftijd van de laatste backup;
• beschikbare backupstorage;
• mislukte backupjobs;
• restore-testresultaten;
• bereikbaarheid van de backupserver.

Een backup die stilletjes drie weken geleden voor het laatst succesvol heeft gedraaid, moet als probleem worden gezien.

Daarom kan Zabbix worden gebruikt om belangrijke backupstatussen te monitoren.

Zie:

• Monitoring & logging

De backuparchitectuur wordt verder uitgewerkt zodra de definitieve backupoplossing en opslaglocatie zijn vastgesteld.

Binnen Tulpencraft gelden de volgende uitgangspunten:

1. 💾 Belangrijke data wordt geback-upt.
2. 🖥️ Backups mogen niet uitsluitend op dezelfde fysieke host staan als productie.
3. 🌍 Kritieke backups worden bij voorkeur ook extern/off-site bewaard.
4. 🔐 Gevoelige backups worden adequaat beveiligd.
5. 🔑 Encryptiesleutels worden afzonderlijk van de backupdata beheerd.
6. 🧊 Snapshots zijn geen backups.
7. 🧪 Backups worden periodiek getest door een restore uit te voeren.
8. 📊 Backupjobs worden gemonitord.
9. 📆 Retentie wordt bewust ingericht.
10. 🚨 Een backupstrategie moet ook een daadwerkelijke disaster recovery mogelijk maken.

• Technische infrastructuur
• OS-installatie
• Rocky Linux 10
• Server hardening
• Firewall
• SELinux
• systemd
• Storage
• Monitoring & logging
• Serverinfrastructuur

• Proxmox VE Administration Guide
• Proxmox Backup Server
• Proxmox Backup Server Documentation