Backup e ripristino

L'applicazione si chiama «Ticket System Backup & Restore». Sta accanto al sistema di ticket e ha un suo collegamento sul desktop.

C'è una versione per Windows e una per Linux. È la stessa applicazione, solo costruita per ciascun sistema operativo.

Ha sei schede. «Restore» elenca i backup che hai, «Create Backup» ne fa uno nuovo, «Schedule» si occupa degli orari, «Encryption» mostra la chiave di ripristino, «Settings» mostra i percorsi e «Log» il protocollo.

Le impostazioni sono già compilate. Al primo avvio l'applicazione capisce da sola dove sta il sistema di ticket.

La cartella dei backup sta in «Backup directory». La puoi cambiare, per esempio su un'altra unità.

Su Windows l'applicazione chiede i diritti di amministratore all'avvio. Le sue impostazioni valgono per tutti gli amministratori del computer e stanno in «%ProgramData%\SMITEY\backup-app».

L'installazione predispone da sola il backup giornaliero. Gira alle 23:00 nel fuso orario del sistema di ticket.

L'orario vive nel sistema operativo. Su Windows è l'Utilità di pianificazione, su Linux il servizio cron. Così non c'è nessun servizio in più che gira solo per i backup.

Il backup non ha bisogno che qualcuno abbia effettuato l'accesso. Su un server in cui non entra mai nessuno gira lo stesso.

La riga sotto i pulsanti ti dice se l'attività esiste davvero nel sistema operativo. Una casella spuntata dice solo che cosa è stato salvato.

I backup vengono tenuti in cinque livelli: 14 giorni, 4 settimane, 12 mesi, 4 trimestri e 5 anni. Un backup resta finché è il più recente del suo periodo in uno di quei livelli.

Contano i giorni di calendario, non i file. Due backup nello stesso giorno sono un giorno.

I backup che crei a mano non vengono mai cancellati automaticamente. È questo che significa lo 0 in «Keep manual».

Se cambi l'orario, la tua modifica sopravvive a un aggiornamento. L'installazione lo imposta solo se non hai mai impostato un orario. Se hai spento il backup, resta spento. Anche «Remove all scheduled tasks» dura: un aggiornamento non reimposta l'orario dopo.

Un backup contiene tutto ciò che compone lo stato del tuo sistema. Cioè la banca dati, i file allegati, l'archivio e le chiavi. Manca solo una banca dati fuori da SMITEY.

Le chiavi sono la parte che sfugge facilmente. Decifrano le credenziali salvate, per esempio quelle del tuo account di posta. Senza di loro un ripristino tornerebbe con credenziali morte.

Ogni nuovo backup è un unico file cifrato con estensione «.smbk». Contiene un file per volume, un elenco del proprio contenuto e, se inclusa, la banca dati come file di testo.

Il sistema continua a funzionare mentre questo succede. I tuoi agenti non si accorgono nemmeno di un backup.

«Estimate size» ti dice in anticipo quanto è grande la banca dati. I volumi con gli allegati si aggiungono. Il backup non è compresso.

Non viene mai sovrascritto niente. Ogni backup è un file a sé, e solo la pulizia rimuove quelli vecchi.

Solo gli amministratori possono leggere i backup. Lo stesso vale per il file di configurazione e per il file con i dati del primo accesso nella cartella di installazione. Il programma di installazione e ogni aggiornamento impostano da sé questi permessi.

Se la tua banca dati gira su un server proprio e non nel container di SMITEY, l'applicazione non può salvarla. In quel caso salvala con i tuoi strumenti. Allora il backup contiene solo gli allegati, gli archivi e le chiavi, cifrati come sempre. Un aggiornamento riconosce da solo una banca dati così e commuta l'applicazione. Fino ad allora il backup giornaliero su un'installazione così non riesce, a meno che tu non la commuti prima a mano. Dalla riga di comando puoi farlo anche a mano con «config --database external». Con «config --database bundled» torni indietro.

Ogni nuovo backup è cifrato. Vale per i backup della pianificazione, per quelli fatti a mano e per quelli prima di un aggiornamento. Non devi attivare nulla.

I backup sono cifrati con AES-256. L'installazione crea la chiave da sola. In un'installazione esistente la chiave viene creata con il primo aggiornamento a una versione con cifratura. È conservata protetta sul server. Solo gli amministratori possono leggerla.

Questo protegge le copie fuori dal server. Chi trova un backup su un'unità di rete, su una chiavetta USB o in un archivio online non può leggerlo senza la chiave. Chi controlla il server stesso ha anche la chiave.

La chiave di ripristino è la stessa chiave in una forma che puoi annotare. Inizia con «SMBK-». La trovi nella scheda «Encryption» e nel file «SMITEY-credentials.txt» nella cartella di installazione. Se hai eliminato quel file, la chiave si trova comunque nella scheda «Encryption».

«Copy» mette la chiave negli appunti. «Save to file...» la salva con l'ID chiave e la data in un file di testo. Conservala per esempio in un gestore di password o su carta in una cassaforte.

Finché non confermi che la chiave è conservata, l'applicazione mostra una barra gialla in alto. Per confermare, fai clic su «I stored the key outside this server» e rispondi alla domanda con «Yes». La barra scompare. La scheda mostra poi quando hai confermato.

L'ID chiave ti dice a quale server appartiene un backup. Se un backup non appartiene a questo server, l'applicazione indica il suo ID chiave. Poi chiede la chiave di ripristino corrispondente.

Se l'applicazione non riesce a leggere la chiave, non fa nessun backup. Non ne fa nemmeno uno non cifrato. In quel caso la scheda «Encryption» dice che la chiave non può essere letta. Se il file della chiave manca del tutto, il backup successivo crea una nuova chiave. La barra gialla compare di nuovo, perché anche la nuova chiave va conservata. I backup più vecchi si possono aprire ancora solo con la vecchia chiave di ripristino.

I backup più vecchi in formato ZIP non sono cifrati. Puoi ancora ripristinarli. La scheda mostra quanti sono. La pulizia li elimina con le stesse regole di ogni altro backup.

Su un server senza desktop «key --show» mostra lo stesso dalla riga di comando.

Nella scheda «Restore» scegli il backup che vuoi indietro. Poi premi «Restore».

L'applicazione chiede prima. Dice che cosa succederà: lo stato di oggi viene sovrascritto e l'applicazione riavvia i container. Se nello stato di oggi ci sono persone anonimizzate, segue una seconda domanda. Indica quante sono e chiede se anonimizzarle di nuovo dopo il ripristino. «Yes» è preselezionato. Con «No» il backup viene ripristinato senza questo passo. Se invece chiudi la finestra, non viene ripristinato nulla.

La spunta «Wipe target volumes before restore» svuota prima i volumi. Così non resta indietro nessun file che non esisteva quando il backup è stato fatto.

I passi compaiono nella scheda «Log». Lì vedi uno per uno che cosa ha fatto l'applicazione. Se alla seconda domanda hai risposto «Yes», una riga alla fine dice quante anonimizzazioni il sistema di ticket applica di nuovo la notte seguente. Se non si possono trasferire, il log mostra invece un avviso. Se ci sono stati avvisi, la riga di stato in fondo alla finestra ne indica il numero.

Se il backup contiene la banca dati, torna lo stato completo. Ticket, commenti, cronologia, file allegati, tempo registrato e base di conoscenza sono di nuovo tutti lì come erano al momento del backup.

Dopo, il sistema è di nuovo utilizzabile. Su un'installazione piccola ci vuole meno di un minuto.

Se il backup contiene la banca dati, questa torna completa o non torna affatto. I volumi seguono dopo. Se un volume non riesce, la banca dati è già tornata ma possono mancare dei file; la scheda «Log» mostra quale passaggio non è riuscito. In ogni caso l'applicazione riavvia poi i container, anche se il ripristino non è riuscito.

Un backup di una versione più vecchia si può ripristinare in una più nuova. Al suo avvio successivo il sistema porta la banca dati alla propria versione.

I consensi e gli annullamenti dell'iscrizione per il sondaggio di soddisfazione vengono trasferiti senza domande. Questo vale anche se rispondi «No» alla seconda domanda. L'applicazione li legge dall'installazione in esecuzione prima del ripristino. Poi una riga nella scheda «Log» indica il numero, per esempio «12 consent and unsubscribe record(s) were carried over.» Il sistema di ticket li riprende al primo avvio. Un consenso o un annullamento dell'iscrizione fatto dopo il backup resta quindi valido. Se il trasferimento non riesce, il log mostra un avviso. Il ripristino conta comunque come riuscito.

L'applicazione controlla prima per intero un backup cifrato. Intanto la riga di stato dice «Checking the encrypted backup before anything is changed...». Solo dopo ferma i container. Se il file è danneggiato o è stato alterato, si ferma e segnala «The backup file is damaged. Nothing was changed.»

Se il backup viene da un altro server, l'applicazione chiede la chiave di ripristino di quel server. Succede dopo le domande. La finestra «Recovery key needed» indica l'ID chiave del backup. La stessa finestra compare se manca la chiave di questo server.

Un errore di battitura viene notato prima che si cambi qualcosa. La riga di stato segnala allora «The recovery key has a typing error. Check each character.» Dopo la finestra chiede di nuovo. Se la chiave appartiene a un altro backup, la riga di stato segnala «This recovery key does not belong to this backup.» Con «Cancel» l'applicazione si ferma e segnala «Restore cancelled. Nothing was changed.»

L'applicazione non adotta la chiave che hai inserito. Mantiene la propria. I nuovi backup si fanno ancora con la chiave di questo server. Se ripristini su un nuovo server, conserva anche la chiave di ripristino di quel server.

Un backup senza banca dati ripristina solo gli allegati, gli archivi e le chiavi. Le chiavi esistenti restano. La banca dati resta com'è. L'applicazione lo dice prima del ripristino e chiede. Con «No» non cambia nulla.

Se l'installazione è impostata su una banca dati propria, l'applicazione salta la parte della banca dati anche quando il backup contiene una banca dati. Questo vale per esempio per un backup più vecchio. L'applicazione chiede prima. Con «No» non cambia nulla.

Spesso un server non ha un desktop. Per questo la stessa applicazione funziona anche come comando.

Nell'uso quotidiano ti servono cinque comandi: «backup» salva, «list» mostra i backup che hai, «restore» ne riporta indietro uno, «schedule» imposta l'orario e «config» mostra le impostazioni. Per la chiave si aggiungono «key» e «decrypt».

Dietro c'è la stessa applicazione della finestra. Non esiste una seconda strada che faccia qualcosa di diverso.

L'applicazione sta in «/opt/smitey/Backup». La chiami con «sudo» e aggiungi il comando. I container girano come «root», quindi anche il backup ha bisogno di quei diritti.

Puoi copiare i sei riquadri qui sotto. Coprono ciò che serve davvero nell'uso quotidiano.

Anche qui il ripristino chiede. Gira solo quando aggiungi «--yes». Trasferisce allora anche le anonimizzazioni dello stato di oggi, come «Yes» nella finestra. Con «--no-reapply» gira senza questo passo.

Sul server c'è un file per leggere tutto questo. Si chiama «BACKUP-RESTORE.txt» e sta in «/opt/smitey». Ripercorre l'orario, tutti i comandi e la strada del ritorno ancora una volta, con i tuoi tempi. Esiste in tedesco e in inglese: se durante l'installazione hai scelto il tedesco, ricevi quello tedesco, altrimenti quello inglese. Entrambe le versioni stanno anche in «/opt/smitey/docs».

«key --show» mostra la chiave di ripristino, l'ID chiave e il numero di backup non cifrati. Quando la chiave è conservata fuori dal server, lo confermi con «key --confirm-stored».

Un backup di un altro server lo ripristini con «--key-file». Il file che indichi contiene la chiave di ripristino. Va bene anche il file di «Save to file...». Al posto del file puoi usare anche la variabile d'ambiente «SMITEY_BACKUP_KEY». Con «sudo» la metti direttamente davanti al programma, cioè «sudo SMITEY_BACKUP_KEY=<key> /opt/smitey/Backup/TicketSystemBackup restore …». La chiave finisce allora nella cronologia della shell. Se la chiave non corrisponde, non cambia nulla.

«decrypt» scrive il contenuto di un backup come file non cifrati in una cartella vuota. Questi file non sono cifrati. Contengono password e dati personali. Eliminali non appena hai finito.

I backup sono file nella cartella che hai impostato. Quella cartella sta sulla stessa macchina del sistema di ticket.

Per i casi più comuni funziona bene. Dati cancellati per sbaglio, un aggiornamento andato storto o un errore nei dati sono tutti coperti.

Non aiuta contro il guasto del disco. Se il disco sparisce, spariscono con lui anche i backup.

Perciò copia i file da un'altra parte. Un'unità di rete, un secondo server o uno spazio di archiviazione nella rete bastano.

Un file copiato si può ricaricare su qualsiasi server. Su un altro server ti serve per questo la chiave di ripristino. Con «Import backup file…» riporti il file nell'elenco.

Le copie sono cifrate. Nessuno può leggerle senza la chiave di ripristino. Quindi non conservare la chiave accanto alle copie. I backup più vecchi con estensione «.zip» non sono cifrati.

Un aggiornamento fa prima un backup proprio. Succede indipendentemente dal tuo orario e senza che tu debba spuntare niente.

Salva le stesse cose di sempre: la banca dati, gli allegati, gli archivi e le chiavi. Se la banca dati gira fuori da SMITEY, l'aggiornamento salva solo allegati, archivi e chiavi.

Questo backup lo fa l'applicazione «Ticket System Backup & Restore». È cifrato come ogni altro e sta nella stessa cartella. Nell'elenco il suo tipo è «Update». I tre backup più recenti di questo tipo vengono conservati. L'applicazione elimina da sola quelli più vecchi.

L'avviso prima dell'aggiornamento te lo dice. Non devi ricordarti di salvare prima.

Se questo backup non riesce, l'aggiornamento si ferma prima di sostituire qualcosa. Una banca dati fuori da SMITEY non blocca l'aggiornamento. L'aggiornamento commuta allora l'applicazione in modo che anche il backup giornaliero lasci fuori la banca dati. Salva questa banca dati con i tuoi strumenti.