← Tutte le guide

Installare e mantenere · Guida operativa

Backup e prova di ripristino

Un backup utile comprende dati e chiavi necessarie a leggerli. Il ripristino va verificato in un ambiente isolato con un'operazione reale, senza sovrascrivere i servizi attivi.

Per chi: Responsabile installazione · Tecnico autorizzato

Prima di iniziare

  • Accesso tecnico autorizzato e destinazione protetta per dati e segreti.
  • Una finestra coerente con le scritture applicative e il runbook della release.

Passo dopo passo

  1. Leggi la procedura di backup e identifica se l'app scrive da container o da sorgenti locali. Usa l'opzione prevista per il caso effettivo.
  2. Esegui scripts/backup.ps1 secondo il runbook. La procedura deve gestire in modo ordinato i propri writer e riavviarli nel percorso finale previsto.
  3. Controlla manifest e checksum: database, file, configurazioni, identità locali e chiavi devono appartenere alla stessa fotografia.
  4. Avvia scripts/restore-check.ps1 con il percorso del backup in ambiente isolato. Verifica non solo import del database ma anche lettura, decifratura e un'operazione applicativa.
  5. Conserva l'esito e proteggi l'archivio. Per un recupero reale segui la procedura con nuova installazione e verifica prima di spostare traffico; valuta la revoca delle sessioni ripristinate.

Risultato atteso

Un backup identificabile e una prova di restore con evidenza dell'operazione reale eseguita.

Limiti e recupero

  • IdP/broker, HR, SMTP e Qlik esterni hanno backup propri e sono esclusioni dichiarate.
  • La prova non sostituisce la scelta di RPO, RTO, durata e archivio cifrato, né autorizza cancellazioni sui volumi attivi.
← All guides

Install and maintain · Practical guide

Backups and restore checks

A usable backup includes data and the keys required to read it. Verify restoration in an isolated environment through a real operation without overwriting active services.

For whom: Installer · Authorised technical operator

Before you start

  • Authorised technical access and protected storage for data and secrets.
  • A window consistent with application writes and the release runbook.

Step by step

  1. Read the backup procedure and identify whether writers run in containers or from local source. Use the option matching the actual deployment.
  2. Run scripts/backup.ps1 according to the runbook. The procedure must manage its own writers cleanly and restart them through the intended finalisation path.
  3. Inspect the manifest and checksums: database, files, configuration, local identities and keys must belong to the same snapshot.
  4. Run scripts/restore-check.ps1 with the backup path in an isolated environment. Verify not only database import but reading, decryption and a real application operation.
  5. Retain the outcome and protect the archive. For real recovery, follow the new-installation procedure and verify before moving traffic; consider revocation of restored sessions.

Expected result

An identifiable backup and a restore check with evidence of an actual application operation.

Limits and recovery

  • External IdP/broker, HR, SMTP and Qlik systems need their own backups and are declared exclusions.
  • The check does not define RPO, RTO, retention or encrypted storage, and authorises no deletion of active volumes.
Apri immagine originale