Questa nota completa il ciclo sul backup. Discuterà l'organizzazione logica di un server dedicato (o VPS), utile per il backup, e offrirà anche un'opzione per ripristinare rapidamente un server da un backup senza troppi tempi di inattività in caso di disastro.
Dati iniziali
Un server dedicato molto spesso ha almeno due dischi rigidi che servono per organizzare un array RAID di primo livello (mirror). Ciò è necessario per poter continuare a far funzionare il server in caso di guasto di un disco. Se si tratta di un normale server dedicato, potrebbe essere presente un controller RAID hardware separato con tecnologia di caching attiva su SSD, in modo che oltre ai normali dischi rigidi sia possibile collegare uno o più SSD. A volte vengono offerti server dedicati, in cui gli unici dischi locali sono SATADOM (piccoli dischi, strutturalmente una flash drive collegata a una porta SATA), o anche una normale flash drive piccola (8-16 GB) collegata a una speciale porta interna, e il i dati vengono prelevati dal sistema di storage, collegato tramite una rete di storage dedicata (Ethernet 10G, FC, ecc.), e ci sono server dedicati che vengono caricati direttamente dal sistema di storage. Non prenderò in considerazione tali opzioni, poiché in questi casi il compito di eseguire il backup del server passa senza problemi allo specialista che mantiene il sistema di archiviazione; di solito ci sono varie tecnologie proprietarie per la creazione di istantanee, deduplicazione integrata e altre gioie dell'amministratore di sistema , discusso nelle parti precedenti di questa serie. Il volume dell'array di dischi di un server dedicato può raggiungere diverse decine di terabyte, a seconda del numero e delle dimensioni dei dischi collegati al server. Nel caso dei VPS, i volumi sono più modesti: di solito non più di 100 GB (ma ce ne sono anche di più), e le tariffe per tali VPS possono facilmente essere più costose rispetto ai server dedicati più economici dello stesso hoster. Un VPS molto spesso ha un disco, perché sotto di esso ci sarà un sistema di archiviazione (o qualcosa di iperconvergente). A volte un VPS dispone di più dischi con caratteristiche diverse, per scopi diversi:
- piccolo sistema - per l'installazione del sistema operativo;
- di grandi dimensioni: memorizzazione dei dati dell'utente.
Quando si reinstalla il sistema utilizzando il pannello di controllo, il disco con i dati dell'utente non viene sovrascritto, ma il disco di sistema viene completamente riempito. Inoltre, nel caso di un VPS, l'hoster può offrire un pulsante che scatta un'istantanea dello stato del VPS (o del disco), ma se installi il tuo sistema operativo o dimentichi di attivare il servizio desiderato all'interno del VPS, alcuni dei dati potrebbero comunque andare persi. Oltre al pulsante viene solitamente offerto un servizio di archiviazione dei dati, il più delle volte molto limitato. In genere si tratta di un account con accesso tramite FTP o SFTP, a volte insieme a SSH, con una shell ridotta (ad esempio, rbash) o una restrizione sull'esecuzione dei comandi tramite Authorized_keys (tramite ForcedCommand).
Un server dedicato è collegato alla rete tramite due porte con una velocità di 1 Gbps, a volte possono essere schede con una velocità di 10 Gbps. Il VPS molto spesso ha un'interfaccia di rete. Molto spesso, i data center non limitano la velocità della rete all'interno del data center, ma limitano la velocità dell'accesso a Internet.
Il carico tipico di un server dedicato o VPS è un server web, un database e un server applicativo. A volte possono essere installati vari servizi ausiliari aggiuntivi, anche per un server web o un database: motore di ricerca, sistema di posta, ecc.
Come spazio per l'archiviazione delle copie di backup funge da server appositamente predisposto, di cui parleremo più dettagliatamente in seguito.
Organizzazione logica del sistema disco
Se disponi di un controller RAID o di un VPS con un disco e non ci sono preferenze speciali per il funzionamento del sottosistema del disco (ad esempio, un disco veloce separato per il database), tutto lo spazio libero viene suddiviso come segue: una partizione viene creato e sopra di esso viene creato un gruppo di volumi LVM, al suo interno vengono creati diversi volumi: 2 piccoli della stessa dimensione, utilizzati come file system root (modificati uno per uno durante gli aggiornamenti per la possibilità di un rapido rollback, l'idea è stata ripresa dalla distribuzione Calculate Linux), un'altra è per la partizione di swap, il resto dello spazio libero è diviso in piccoli volumi, utilizzato come file system root per contenitori veri e propri, dischi per macchine virtuali, file sistemi per account in /home (ogni account ha il proprio file system), file system per contenitori di applicazioni.
Nota importante: i volumi devono essere completamente autonomi, vale a dire non dovrebbero dipendere l'uno dall'altro o dal file system root. Nel caso di macchine virtuali o container questo punto viene rispettato automaticamente. Se si tratta di contenitori di applicazioni o home directory, dovresti pensare a separare i file di configurazione del server web e degli altri servizi in modo tale da eliminare il più possibile le dipendenze tra i volumi. Ad esempio, ogni sito viene eseguito dal proprio utente, i file di configurazione del sito si trovano nella directory home dell'utente, nelle impostazioni del server web, i file di configurazione del sito non sono inclusi tramite /etc/nginx/conf.d/.conf e, ad esempio, /home//configs/nginx/*.conf
Se sono presenti più dischi, è possibile creare un array RAID software (e configurarne la memorizzazione nella cache su un SSD, se necessario e opportunità), sopra il quale è possibile costruire LVM secondo le regole sopra proposte. Anche in questo caso puoi usare ZFS o BtrFS, ma dovresti pensarci due volte: entrambi richiedono un approccio molto più serio alle risorse, e inoltre ZFS non è incluso nel kernel Linux.
Indipendentemente dallo schema utilizzato, vale sempre la pena stimare in anticipo la velocità approssimativa di scrittura delle modifiche sui dischi, quindi calcolare la quantità di spazio libero che verrà riservata alla creazione degli snapshot. Ad esempio, se il nostro server scrive dati a una velocità di 10 megabyte al secondo e la dimensione dell'intero array di dati è di 10 terabyte, il tempo di sincronizzazione può raggiungere un giorno (22 ore - questo è quanto verrà trasferito tale volume sulla rete 1 Gbps) - vale la pena riservare circa 800 GB . In realtà la cifra sarà più piccola; puoi tranquillamente dividerla per il numero di volumi logici.
Dispositivo server di archiviazione di backup
La differenza principale tra un server per l'archiviazione di copie di backup sono i suoi dischi grandi, economici e relativamente lenti. Poiché i moderni HDD hanno già superato la soglia di 10 TB in un disco, è necessario utilizzare file system o RAID con checksum, perché durante la ricostruzione dell'array o il ripristino del file system (diversi giorni!) il secondo disco potrebbe guastarsi a causa ad un aumento del carico. Sui dischi con una capacità fino a 1 TB questo non era così sensibile. Per semplicità di descrizione, presumo che lo spazio su disco sia diviso in due parti di dimensioni approssimativamente uguali (di nuovo, ad esempio, utilizzando LVM):
- volumi corrispondenti ai server utilizzati per archiviare i dati degli utenti (su di essi verrà distribuito l'ultimo backup effettuato per la verifica);
- volumi utilizzati come repository BorgBackup (i dati per i backup andranno direttamente qui).
Il principio di funzionamento è che vengono creati volumi separati per ciascun server per i repository BorgBackup, dove andranno i dati dei server di combattimento. I repository funzionano in modalità append-only, che elimina la possibilità di eliminare intenzionalmente i dati, e grazie alla deduplicazione e alla pulizia periodica dei repository dai vecchi backup (rimangono copie annuali, mensili per l'ultimo anno, settimanali per l'ultimo mese, giornaliere per ultima settimana, eventualmente in casi particolari - orario per l'ultimo giorno: totale 24 + 7 + 4 + 12 + annuale - circa 50 copie per ogni server).
I repository BorgBackup non abilitano la modalità di sola aggiunta; invece, un ForcedCommand in .ssh/authorized_keys viene utilizzato in questo modo:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Il percorso specificato contiene uno script wrapper sopra borg che, oltre ad avviare il binario con parametri, avvia inoltre il processo di ripristino della copia di backup dopo la rimozione dei dati. Per fare ciò, lo script wrapper crea un file di tag accanto al repository corrispondente. L'ultimo backup effettuato viene automaticamente ripristinato nel volume logico corrispondente al termine del processo di riempimento dei dati.
Questo design consente di ripulire periodicamente i backup non necessari e impedisce inoltre ai server di combattimento di eliminare qualsiasi cosa sul server di archiviazione di backup.
Processo di backup
L'iniziatore del backup è il server dedicato o il VPS stesso, poiché questo schema offre un maggiore controllo sul processo di backup da parte di questo server. Innanzitutto, viene scattata un'istantanea dello stato del file system root attivo, che viene montata e caricata utilizzando BorgBackup sul server di archiviazione di backup. Una volta completata l'acquisizione dei dati, lo snapshot viene smontato ed eliminato.
Se è presente un database di piccole dimensioni (fino a 1 GB per ciascun sito), viene effettuato un dump del database, che viene salvato nel volume logico appropriato, dove si trova il resto dei dati per lo stesso sito, ma in modo che il dump sia non accessibile tramite il server web. Se i database sono grandi, dovresti configurare la rimozione dei dati “a caldo”, ad esempio, utilizzando xtrabackup per MySQL, o lavorare con WAL con archive_command in PostgreSQL. In questo caso il database verrà ripristinato separatamente dai dati del sito.
Se vengono utilizzati contenitori o macchine virtuali, è necessario configurare qemu-guest-agent, CRIU o altre tecnologie necessarie. In altri casi, molto spesso non sono necessarie impostazioni aggiuntive: creiamo semplicemente istantanee di volumi logici, che vengono quindi elaborate allo stesso modo di un'istantanea dello stato del file system root. Una volta acquisiti i dati, le immagini vengono cancellate.
Ulteriore lavoro viene eseguito sul server di archiviazione di backup:
- viene controllato l'ultimo backup effettuato in ciascun repository,
- viene verificata la presenza di un file di contrassegno, che indica che il processo di raccolta dei dati è stato completato,
- i dati vengono espansi al volume locale corrispondente,
- il file di tag viene eliminato
Processo di ripristino del server
Se il server principale muore, viene avviato un server dedicato simile, che si avvia da un'immagine standard. Molto probabilmente il download avverrà tramite la rete, ma il tecnico del data center che configura il server potrà immediatamente copiare questa immagine standard su uno dei dischi. Il download avviene nella RAM, dopodiché inizia il processo di ripristino:
- viene effettuata una richiesta per collegare un dispositivo a blocchi tramite iscsinbd o un altro protocollo simile a un volume logico contenente il file system root del server defunto; Poiché il file system root deve essere piccolo, questo passaggio dovrebbe essere completato in pochi minuti. Anche il bootloader viene ripristinato;
- viene ricreata la struttura dei volumi logici locali, i volumi logici vengono collegati dal server di backup utilizzando il modulo kernel dm_clone: inizia il ripristino dei dati e le modifiche vengono scritte immediatamente sui dischi locali
- viene avviato un container con tutti i dischi fisici disponibili: la funzionalità del server viene completamente ripristinata, ma con prestazioni ridotte;
- al termine della sincronizzazione dei dati, i volumi logici dal server di backup vengono disconnessi, il contenitore viene spento e il server viene riavviato;
Dopo il riavvio, il server disporrà di tutti i dati presenti al momento della creazione del backup e includerà anche tutte le modifiche apportate durante il processo di ripristino.
Altri articoli della serie
Backup Parte 7: Conclusioni
Vi invito a discutere l'opzione proposta nei commenti, grazie per l'attenzione!
Fonte: habr.com