Esistono molte soluzioni di backup, ma cosa fare se i server gestiti sono sparsi in diverse regioni e clienti e dobbiamo utilizzare gli strumenti del sistema operativo?
Buongiorno, Habr!
Mi chiamo Natalya. Sono il team leader del gruppo di amministratori delle applicazioni presso NPO 'Krista'. Siamo gli Ops per il gruppo di progetti della nostra azienda. Abbiamo una situazione piuttosto specifica: installiamo e manteniamo il nostro software sia sui server della nostra azienda che su quelli dei clienti. In questo caso, non è necessario eseguire il backup completo del server. Sono importanti solo i "dati essenziali": il DBMS e alcune directory del file system. Naturalmente, i clienti hanno (o non hanno) le proprie normative sui backup e spesso forniscono una sorta di archivio esterno per depositarvi i backup. In tal caso, dopo la creazione del backup ci assicuriamo di inviarlo all'archivio esterno.
Per un certo periodo, per esigenze di backup, ci siamo affidati a uno script bash, ma man mano che aumentavano le opzioni di configurazione, cresceva anche la complessità di questo script, e a un certo punto ci siamo trovati nella necessità di "distruggerlo fino alle basi, e poi....".
Le soluzioni già pronte non ci andavano bene per diversi motivi: a causa della necessità di decentralizzare i backup, dell'obbligo di conservare i backup localmente presso il cliente, della complessità di configurazione, del desiderio di sostituzione delle importazioni e delle limitazioni di accesso.
Ci è sembrato più semplice scrivere qualcosa di nostro. Volevamo però ottenere qualcosa che fosse sufficiente per la nostra situazione per i prossimi N anni, ma con la possibilità di un potenziale ampliamento dell'ambito di applicazione.
Le condizioni del compito erano le seguenti:
- l'istanza di backup di base è autonoma e funziona localmente
- la conservazione dei backup e dei log avviene sempre all'interno della rete del cliente
- l'istanza è composta da moduli – una sorta di "costruttore"
- è necessaria la compatibilità con le distribuzioni Linux utilizzate, comprese quelle obsolete, è desiderabile una potenziale portabilità tra piattaforme
- per lavorare con l'istanza è sufficiente l'accesso tramite ssh, l'apertura di porte aggiuntive non è necessaria
- massima semplicità di configurazione e utilizzo
- è possibile (ma non obbligatorio) che esista un'istanza separata che consenta di visualizzare centralmente lo stato dei backup da diversi server
Quello che abbiamo ottenuto può essere visto qui:
Il software è scritto in python3; funziona su Debian, Ubuntu, CentOS, AstraLinux 1.6.
La documentazione è disponibile nella cartella docs del repository.
Concetti principali utilizzati dal sistema:
action – azione, che implementa una singola operazione atomica (backup DB, backup di una cartella, trasferimento dalla cartella A alla cartella B, ecc.). Le azioni esistenti si trovano nella cartella core/actions
task – compito, insieme di azioni che descrive un'unica 'attività di backup' logica
schedule – programma, insieme di compiti con indicazione opzionale dell'orario di esecuzione del compito
La configurazione del backup è memorizzata in un file yaml; struttura generale della configurazione:
- impostazioni comuni
- sezione actions: descrizione delle azioni utilizzate su questo server
- sezione schedule: descrizione di tutti i compiti (insiemi di azioni) e pianificazione delle loro esecuzioni tramite cron, se necessaria
Cosa può fare l'applicazione attualmente:
- supporta le principali operazioni per noi: backup di PostgreSQL tramite pg_dump, backup di una cartella del filesystem tramite tar; operazioni con storage esterno; rsync tra directory; rotazione dei backup (eliminazione delle copie più vecchie)
- chiamata di uno script esterno
- esecuzione manuale di un singolo compito
/opt/KristaBackup/KristaBackup.py run make_full_dump - è possibile aggiungere (o rimuovere) un singolo compito o l'intero programma nel crontab
/opt/KristaBackup/KristaBackup.py enable all - generazione di un file trigger in base ai risultati del backup. Questa funzione è utile in connessione con 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à: in webapi non c'è un'interfaccia web vera e propria, ma l'applicazione risponde alle richieste di un'altra istanza. Per la modalità web è necessario installare flask e alcuni pacchetti aggiuntivi, che non sono sempre accettabili, ad esempio in AstraLinux SE certificato.
Tramite l'interfaccia web è possibile visualizzare lo stato e i log dei backup dei server connessi: l' 'istanza web' richiede dati dalle 'istanze di backup' tramite API. L'accesso al web richiede autenticazione, l'accesso al webapi – no.
I log dei backup non riusciti vengono contrassegnati con un colore: warning – giallo, error – rosso.
Se l'amministratore non ha bisogno di un promemoria sui parametri e i sistemi operativi dei server sono omogenei, è possibile compilare il file e distribuire già il pacchetto pronto.
Distribuiamo principalmente questo strumento tramite Ansible, distribuendolo inizialmente a una parte dei server meno importanti, e dopo testarlo su tutti gli altri.
Alla fine abbiamo ottenuto un'utilità di copia compatta e autonoma, automatizzabile e utilizzabile anche da amministratori poco esperti. È comodo per noi – magari sarà utile anche a voi?
Fonte: habr.com
