Ripristino d'emergenza senza Internet: percorsi di ripristino locali, strategie per i supporti e checklist

Einleitung: Warum lokale RESTore‑Pfadplanung jetzt zählt

Notfallwiederherstellung ohne Internet — dieses Fokus‑Keyword trifft einen realen Betriebsfall: Cloudzugang, zentrale Authentifizierung oder externe Schlüssel sind nicht verfügbar, während Daten wiederhergestellt werden müssen. Entscheider und Administratoren stehen vor konkreten Fragen: Welche Medien halten auch bei Netzausfall? Wie komme ich an Verschlüsselungsschlüssel ohne KMS‑Zugriff? Wie führe ich einen MariaDB‑RESTore lokal und reproduzierbar durch? Dieser Beitrag liefert praxisnahe RESTore‑Pfade, Medien‑Strategien, MariaDB‑Howtos, typische Stolperfallen und eine ausführliche Checkliste für Live‑Runs.

Risiken und typische Ursachen für einen Offline‑RESTore

Ein RESTore ohne Internet tritt selten allein auf; meist ist er Folge eines größeren Incidents. Häufige Auslöser sind:

• Provider‑Ausfall oder regionale Cloud‑Störung — Netzwerk zur Cloud nicht erreichbar.
• Ransomware/Netzwerkisolation — produktive Umgebung bewusst vom Netz getrennt.
• Rechenzentrumsausfall der WAN‑Anbindung — nur lokale Infrastruktur bleibt erreichbar.
• Fehlerhafte PKI/KMS‑Konfiguration mit externen Keys — Schlüssel nicht abrufbar.

Jeder dieser Fälle macht zentral gespeicherte Backups oder cloudbasierte Schlüssel unbrauchbar. Ziel ist deshalb ein getesteter, lokaler RESTore‑Pfad (Disk, Tape, offline NAS oder physische Medien) inklusive Offline‑Schlüsselzugang und klaren Runbooks.

Grundprinzipien für RESTore‑Pfade ohne Internet

Gute lokale RESTore‑Pfade basieren auf fünf Prinzipien:

1. Air‑Gap oder physische Trennung: Backupkopien existieren mindestens einmal auf einem Medium, das nicht permanent mit dem Produktionsnetz verbunden ist (z. B. Band, verschlossene USB‑Archivbox, externe NVMe).
2. Medienvielfalt: Nicht nur ein Medientyp nutzen — Kombination aus schnell verfügbaren lokalen Disks und langfristigen Bandarchiven ist sinnvoll.
3. Sichere, lokale Schlüsselverwaltung: Schlüssel für verschlüsselte Repositories müssen offline verfügbar sein (Hardware‑Token, verschlüsselte Schlüsseldatei in Tresor, dokumentierte Passphrase‑Escalation).
4. Testbare, dokumentierte Runbooks: Schritt‑für‑Schritt‑Anleitungen inklusive Prüfungen und Zeitvorgaben (RTO/Aufgabenverteilung).
5. Verifizierbare Integrität: Checksummen und Signaturen für jedes Backup‑Artefakt, die sich lokal prüfen lassen.

Medienstrategie: Auswahl, Vor‑ und Nachteile

Wählen Sie Medien nicht nach Meinungen, sondern nach Betriebsanforderungen (Datenvolumen, RTO, physische Sicherheit). Hier die gängigen Optionen mit praktischen Hinweisen:

Lokale Disk‑Arrays oder NAS (schnell, aber begrenzt)

Vorteil: Schnelle Wiederherstellung, einfache Automatisierung. Nachteil: Standortrisiko (Brand, Diebstahl). Für Offline‑Recovery empfiehlt sich ein dediziertes, abschließbares Backup‑NAS, das nur periodisch angebunden wird.

Externe NVMe/SSD per USB‑Dublikator (sehr schnell, mobil)

Vorteil: Sehr kurze RESTore‑Zeit bei großen Datenmengen. Nachteil: Kosten pro Terabyte, braucht sicheren Transport und klare Inventur.

Bänder (Tape, z. B. LTO) — langfristig, robust, physisch trennbar

Vorteil: Gutes Langzeitarchiv, einfach offline lagerbar. Nachteil: Lesezeit und Hardwareverfügbarkeit. Tipp: Regelmäßige Tape‑Health‑Checks, Tape‑Catalog lokal archivieren (Datei mit Metadaten und Checksummen).

WORM / Write‑Once Medien (rechtliche Anforderungen)

Wenn Revisionssicherheit gefordert ist, sind WORM‑fähige Repositories sinnvoll. Prüfen Sie Kompatibilität mit Ihrer Backup‑Software und planen Sie Offline‑Zugänge zu den Indexdaten.

Centro dati isolato (air‑gapped) o sito (diversificato fisicamente)

Un secondo centro dati fisicamente separato con copie sincronizzate è costoso, ma offre una protezione reale contro il guasto del sito. Per organizzazioni più piccole una unità di backup locale chiusa a chiave più una strategia di trasporto (georedundante) può essere sufficiente.

Strategie di ripristino specifiche per MariaDB

Con MariaDB (un sistema di gestione di database relazionali compatibile con MySQL) bisogna distinguere tra backup fisici e logici. I backup fisici copiano i file di dati (file InnoDB), i backup logici esportano dump SQL. Entrambi hanno requisiti di ripristino diversi.

Backup fisici: Percona XtraBackup / snapshot del file system

I backup fisici (p.es. Percona XtraBackup o copie snapshot LVM) sono preferibili per database di grandi dimensioni grazie ai tempi di ripristino ridotti. XtraBackup crea copie coerenti dei file di dati InnoDB senza mettere il server offline. In caso di ripristino senza Internet valgono i seguenti punti:

• Salvate la directory completa del backup più i metadati di preparazione (xtrabackup_binlog_info) localmente.
• Conservate i binary logs (binary logs) localmente, in modo da poter eseguire il point‑in‑time recovery.
• Assicuratevi che le versioni di XtraBackup e MariaDB sul host di ripristino siano compatibili.

Esempio: sequenza di preparazione e ripristino con xtrabackup (semplificata):

# Backup-Prepare (offline auf RESTore-Medium oder temporärem Host)
xtrabackup --prepare --target-dir=/mnt/backup/xb-2026-07-01

# Kopieren der vorbereiteten Daten ins Datenverzeichnis (auf eigenem RESTore-Host)
systemctl stop mariadb
rm -rf /var/lib/mysql/*
cp -a /mnt/backup/xb-2026-07-01/* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mariadb

Perché funziona? XtraBackup „prepara“ i file in modo che InnoDB possa avviarli senza eseguire una fase di recovery. Quando fallisce: versioni diverse di MariaDB, file ibd o system‑tablespace mancanti o chiavi mancanti per tablespace cifrati.

Backup logici: mysqldump e ripristini parziali rapidi

mysqldump genera statement SQL. Vantaggio: portabilità semplice, ripristino possibile su versioni diverse. Svantaggio: il ripristino su DB molto grandi è lento. Raccomandato come integrazione per schemi piccoli e critici (es. gestione utenti, tabelle di configurazione).

mysqldump --single-transaction --routines --events --triggers --databases appdb > /media/backup/appdb.sql

# RESTore lokal auf RESTore-Host
mysql -u root -p < /media/backup/appdb.sql

Point‑in‑Time‑Recovery con binary logs

I binary logs registrano tutti gli eventi di modifica. Se archiviate i binary logs localmente, dopo un ripristino fisico potete riprodurre le modifiche fino a un momento specifico. Esempio: applicazione dei binary logs con mysqlbinlog:

# Extrahieren relevanter Statements zwischen Zeiten
mysqlbinlog --start-datetime="2026-07-01 09:00:00" --stop-datetime="2026-07-01 12:00:00" /media/backup/mysql-bin.000123 | mysql -u root -p

Importante: verificate il formato del binlog (ROW, STATEMENT, MIXED). Il formato ROW è spesso più affidabile per replica/point‑in‑time perché registra le modifiche ai record invece del testo SQL.

Ripristino d’emergenza senza Internet: check pratico per MariaDB

Questa sezione riassume controlli e comandi concreti necessari in uno scenario di ripristino offline. Obiettivo: individuare rapidamente il punto di inizio corretto del binlog, verificare la versione e controllare le chiavi.

Leggere e applicare xtrabackup_binlog_info

Il file xtrabackup_binlog_info contiene il file binlog e la posizione valide al momento del backup. Come usare questa informazione:

# Beispielinhalt einer xtrabackup_binlog_info-Datei
cat /mnt/backup/xb-2026-07-01/xtrabackup_binlog_info
# Ausgabe z.B.: mysql-bin.000123    456789

# Anwenden: nur die späteren Binlogs wieder einspielen
mysqlbinlog --start-position=456789 /media/backup/mysql-bin.000123 | mysql -u root -p

Perché questo è utile: in questo modo si assicura che, dopo il ripristino fisico, non vengano applicate transazioni duplicate. Fonte del problema: se mancano binlog o sono stati ruotati, è necessaria una verifica nel catalogo Tape/NAS.

Verifica di versione e dei plugin sull’host di ripristino

Un errore comune è l’incompatibilità tra versioni di MariaDB o la mancanza di plugin per storage engine (p. es. TokuDB, MyRocks). Verifichi localmente:

# MariaDB-Version prüfen
mysql -u root -e "SELECT VERSION();"

# Installierte Storage-Engines prüfen
mysql -u root -e "SHOW ENGINES;"

Se manca un plugin, pianifichi l’installazione prima del ripristino dei dati oppure utilizzi un host con l’ambiente software adeguato.

Ripristino da Tape: passi pratici e insidie

Molte organizzazioni fanno affidamento sul Tape come archivio offline. In caso di emergenza è necessario sapere come montare un nastro ed estrarre i dati. Aspetti importanti: dispositivo drive Tape (/dev/st0), posizionamento (mt), schema di lettura (tar, dar, amanda). Esempio con tar:

# Band zum Anfang spulen
mt -f /dev/st0 rewind

# Inhaltsliste erstellen (falls tar verwendet wurde)
tar -tvf /dev/st0

# Entpacken auf Zielpfad
tar -xvf /dev/st0 -C /mnt/RESTore

Insidie: diverse dimensioni di blocco in scrittura/lettura, nastri danneggiati e software per Tape incompatibile. Testi regolarmente i ripristini da Tape e mantenga un inventario dei nastri con fasi di verifica.

Gestione offline delle chiavi: Shamir, HSM e token hardware

Se i backup sono cifrati, l’accesso alle chiavi è il percorso critico. Opzioni collaudate:

• Shamir’s Secret Sharing (SSS): dividere la chiave in più parti distribuite in casseforti sicure. Per il ripristino è necessario ricomporre un numero sufficiente di share.
• Token hardware (p. es. YubiKey con slot PGP/OpenPGP) o smartcard come fonte di chiavi disponibile offline.
• Fallback HSM: se l’HSM primario viene meno, un HSM di emergenza fisicamente separato deve essere predisposto e documentato.

Importante: testi l’intera catena di decifratura in un ambiente di test isolato. Una copia della chiave senza accesso al software di decifratura non aiuta in caso di emergenza.

Operativo: ruoli, catena di custodia e inventario

Le responsabilità devono essere chiaramente definite: chi può richiedere i supporti, chi firma le consegne, chi esegue le operazioni di ripristino. Un semplice CSV di inventario facilita la tracciabilità e la verifica per audit.

# Beispielinventar CSV (backup_inventory.csv)
# media_id,media_type,serial,created_at,checksum,checksum_sig,responsible,location
TAPE-20260701-01,tape,LT02-12345,2026-07-01T02:15:00Z,sha256:abcd1234,checksums.sha256.sig,admin-max,tresor-raum-3
NVME-20260701-01,nvme,SN987654,2026-07-01T02:10:00Z,sha256:efgh5678,checksums.sha256.sig,admin-anna,safe-depot

Al momento della consegna documentare: orario, ID, firma (digitale o fisica) e scopo. In questo modo è possibile fornire in seguito prova per audit o compliance.

Troubleshooting MariaDB: messaggi di errore tipici e contromisure

Alcuni errori comuni e rimedi concreti:

• Errore: „InnoDB: unable to open table space file“ → Causa: .ibd mancante o configurazione file‑per‑table errata. Azione: verificate i backup per file .ibd, confrontateli con .frm/.cfg e importate i Tablespaces se possibile.
• Errore: „Table is marked as crashed“ → Causa: arRESTo non pulito o errore del file system. Azione: mysqlcheck o myisamchk per MyISAM; InnoDB: xtrabackup‑RESTore o innodb_force_recovery per l’estrazione.
• Errore: „Binary log not found“ durante l’applicazione di mysqlbinlog → Causa: il binlog è ruotato o mancante. Azione: cercate i Binlogs su altri supporti (Tape/NAS) o ricostruiteli tramite i log del livello applicazione.

Test regolari, documentazione e Lessons Learned

L’esperienza pratica mostra: ogni RESTore riuscito è il risultato di molte piccole preparazioni. Dopo ogni drill compilate un protocollo Lessons‑Learned: quali passi hanno richiesto troppo tempo? Quali supporti non sono stati reperibili? Mancavano chiavi o firme? Aggiornate di conseguenza i Runbooks.

Lista di controllo: Ripristino d’emergenza senza Internet (versione breve per i responsabili d’intervento)

1. Verificare la disponibilità: quali supporti sono accessibili fisicamente? (Tape, USB, NAS)
2. Recupero chiavi: chi ha accesso offline? Le passphrase sono disponibili?
3. Predisporre l’host di RESTore: versione MariaDB compatibile, spazio disco, isolamento di rete.
4. Verifica di integrità: convalidare le checksum.
5. Preparare il backup: eseguire XtraBackup prepare o fornire un SQL dump.
6. Ripristinare i dati: copiare i file / importare l’SQL.
7. Applicare i binlog: mysqlbinlog (in modo controllato).
8. Avviare i servizi e verificare i log: journalctl, mysql‑Errorlog.
9. Eseguire smoke test: verificare i percorsi critici dell’applicazione.
10. Documentazione: registrazione dei passaggi, dei tempi e degli errori per il follow‑up.

Conclusione: la preparazione orientata alla pratica è la chiave

Il ripristino d’emergenza senza Internet non è uno scenario teorico: in caso di guasti del provider, ransomware o interruzioni regionali i team devono essere in grado di operare localmente e offline. Cruciali sono test ripetuti, strategie multi‑supporto, recupero delle chiavi documentato e Runbooks chiari per i RESTore MariaDB. Pianificate il percorso di RESTore, testatelo in condizioni realistiche e conservate chiavi e inventario in modo fisicamente sicuro ma accessibile. Solo così un RESTore sarà riproducibile e pianificabile nei tempi in caso di emergenza.

Ulteriori considerazioni: link interni e prossimi passi

Questo articolo è pensato come how‑to operativo: completatelo con un runbook concreto nel vostro ITSM, collegate la lista di controllo ai processi di comunicazione d’emergenza e svolgete un drill di primo test nel prossimo maintenance window. Collegamenti interni a policy di backup, PKI‑runbook e inventario Tape sono misure consigliate come prossimi passi.

Ripristino d’emergenza senza Internet: ambiente di RESTore offline e insidie di integrazione

Un percorso spesso sottovalutato nel ripristino d’emergenza senza Internet è l’ambiente di recupero stesso: server, pacchetti, artefatti di configurazione e immagini container devono essere pronti al boot in modalità offline. Origini pacchetti mancanti o librerie incompatibili bloccano gli script di RESTore più rapidamente della mancanza di backup.

Misure consigliate:

• Repository di pacchetti locali e cache di immagini container: replicate i pacchetti critici (OS, MariaDB, XtraBackup, libaio) su un supporto disponibile offline. Verificate le firme GPG localmente.
• Version‑Pinning und Build‑Artefakte: Conservi le versioni esatte dei binary del database e dei driver di storage per gli host di ripristino (incl. note di rilascio per modifiche incompatibili).
• Vorkonfigurierte, minimale RESTore‑Images: Prepari un’immagine di ripristino “golden”, immutabile (VM o container) con tutte le dipendenze; salvi l’immagine come ISO avviabile o qcow2 su NVMe/Tape.
• Konfigurations‑Inventar und Secrets‑Escrow: Tenga i file my.cnf configurati, le unità systemd e i secret cifrati vicini al backup, con una procedura documentata per lo sblocco.
• Offline‑Monitoring und Log‑Aggregation: Fornisca semplici health‑checks e raccolta locale dei log, in modo da poter eseguire rapidamente controlli di integrità e di performance dopo il ripristino.

Architekturhinweis: Tratti l’ambiente di ripristino come codice dell’infrastruttura. Template IaC versionati (Ansible, Terraform) e artefatti firmati eseguibili offline riducono gli errori e accelerano notevolmente il ripristino.

Per questo tema sono importanti anche i percorsi locali di ripristino e i backup offline. Il contributo inquadra questi aspetti in modo chiaro e mostra su cosa bisogna concentrarsi nella pratica quotidiana.