Esistono molti sistemi di backup, ma cosa fare se i server serviti sono sparsi in diverse regioni e client e bisogna accontentarsi del sistema operativo?
Buon giorno, Ci sarà!
Mi chiamo Natalia. Sono il team leader del gruppo di amministratori delle applicazioni presso NPO Krista. Siamo Ops per il gruppo di progetto della nostra azienda. Abbiamo una situazione piuttosto unica: installiamo e manteniamo i nostri software sia sui server della nostra azienda che su server situati presso le sedi dei clienti. In questo caso non è necessario eseguire il backup dell'intero server. Sono importanti solo i “dati essenziali”: il DBMS e le singole directory del file system. Naturalmente, i clienti hanno (o non hanno) le proprie regole di backup e spesso forniscono qualche tipo di spazio di archiviazione esterno per archiviare i backup. In questo caso, dopo aver creato un backup, assicuriamo l'invio su un archivio esterno.
Per qualche tempo, a scopo di backup, ci siamo accontentati di uno script bash, ma man mano che le opzioni di configurazione crescevano, la complessità di questo script cresceva proporzionalmente, e ad un certo punto siamo arrivati alla necessità di “distruggerlo completamente, e poi ...”.
Le soluzioni già pronte non erano adatte per vari motivi: necessità di decentralizzare i backup, necessità di archiviare i backup localmente presso il client, complessità di configurazione, sostituzione delle importazioni, restrizioni di accesso.
Ci è sembrato che fosse più facile scrivere qualcosa di nostro. Allo stesso tempo, volevo ottenere qualcosa che fosse sufficiente per la nostra situazione per i prossimi N anni, ma con la possibilità di ampliare potenzialmente la portata.
Le condizioni dell’incarico erano le seguenti:
- l'istanza di backup di base è autonoma e viene eseguita localmente
- l’archiviazione dei backup e dei log avviene sempre all’interno della rete del cliente
- un'istanza è composta da moduli - una sorta di "costruttore"
- è richiesta la compatibilità con le attuali distribuzioni Linux, comprese quelle obsolete, è auspicabile il potenziale multipiattaforma
- Per funzionare con l'istanza è sufficiente l'accesso tramite ssh; non è necessaria l'apertura di porte aggiuntive
- massima facilità di installazione e funzionamento
- è possibile (ma non necessario) avere un'istanza separata che permetta di visualizzare centralmente lo stato dei backup provenienti da server diversi
Puoi vedere cosa abbiamo inventato qui:
Il software è scritto in python3; funziona su Debian, Ubuntu, CentOS, AstraLinux 1.6.
La documentazione è pubblicata nella directory docs del repository.
Concetti di base su cui opera il sistema:
azione – un'azione che implementa un'operazione atomica (backup del database, backup della directory, trasferimento dalla directory A alla directory B, ecc.). Le azioni esistenti si trovano nella directory core/actions
compito – compito, una serie di azioni che descrivono un “compito di backup” logico
pianificazione: pianificazione, una serie di attività con un'indicazione facoltativa del tempo di esecuzione dell'attività
La configurazione del backup è archiviata in un file yaml; struttura di configurazione generale:
- Impostazioni generali
- sezione azioni: descrizione delle azioni utilizzate su questo server
- sezione pianificazione: descrizione di tutte le attività (serie di azioni) e pianificazione del loro avvio tramite cron, se tale avvio è richiesto
Cosa può fare attualmente l'applicazione:
- Sono supportate le principali operazioni per noi: backup PostgreSQL tramite pg_dump, backup directory del file system tramite tar; operazioni con storage esterno; rsync tra directory; rotazione dei backup (eliminazione delle vecchie copie)
- chiamando uno script esterno
- esecuzione manuale di un'attività separata
/opt/KristaBackup/KristaBackup.py run make_full_dump - puoi aggiungere (o rimuovere) una singola attività o l'intero programma al crontab
/opt/KristaBackup/KristaBackup.py enable all - generazione di un file di trigger in base ai risultati del backup. Questa funzione è utile insieme a Zabbix per monitorare i backup
- può funzionare in background in modalità webapi o web
/opt/KristaBackup/KristaBackup.py web start [--api]
La differenza tra le modalità: webapi non ha un'interfaccia web stessa, ma l'applicazione risponde alle richieste di un'altra istanza. Per la modalità web, è necessario installare flask e diversi pacchetti aggiuntivi, e questo non è accettabile ovunque, ad esempio in AstraLinux SE certificato.
Attraverso l'interfaccia web è possibile visualizzare lo stato e i log dei backup dei server connessi: l'“istanza web” richiede i dati alle “istanze di backup” tramite API. L'accesso al web richiede l'autorizzazione, l'accesso a webapi no.
I registri dei backup errati sono contrassegnati a colori: avviso – giallo, errore – rosso.
Se l'amministratore non ha bisogno di un cheat sheet sui parametri e i sistemi operativi del server sono omogenei, è possibile compilare il file e distribuire il pacchetto già pronto.
Distribuiamo questa utility principalmente tramite Ansible, distribuendola prima ad alcuni dei server meno importanti e dopo averla testata a tutti gli altri.
Di conseguenza, abbiamo ricevuto un'utilità di copia compatta e autonoma che può essere automatizzata e utilizzata anche da amministratori inesperti. Per noi è conveniente, forse sarà utile anche per te?
Fonte: habr.com