Stefano Marinelli's Blog (Articoli su backup)

Backup efficienti di container LXC in Proxmox - ZFS

Stefano Marinelli — Wed, 18 Jan 2023 08:34:19 GMT

NOTA: Il seguente post è la traduzione dell'equivalente in inglese sul blog it-notes. L'originale sarà sempre più aggiornato.

Ho già scritto relativamente ad alcune delle mie strategie di backup in Proxmox. Proxmox Backup Server è un valido strumento, ma non è sempre l'opzione migliore, soprattutto se si utilizzano container lxc.

I container LVM e Ceph RBD sono già stati trattati in un altro post, ma una delle (molte) ottime opzioni, se si usa Proxmox, è ZFS. Utilizzo ampiamente ZFS sia su FreeBSD che su Linux (e ho sempre desiderato che BTRFS potesse raggiungere lo stesso livello di affidabilità).

Quando non ho bisogno di un file system in rete (come Ceph) o voglio superare i limiti di LVM, tendo a installare le VM di Proxmox e i container lxc su ZFS. Concentriamoci ora sul backup dei container lxc.

Proxmox utilizza i dataset ZFS per lo storage dei container lxc, quindi tutti i file si trovano su /nome-pool/subvol-x-disk-y. Possiamo eseguire facilmente il backup come abbiamo fatto nel mio precedente articolo, abbiamo solo bisogno di un modo diverso per eseguire le snapshot di tutti questi dataset.

I dataset ZFS forniscono una directory .zfs, nascosta, che contiene tutte le istantanee attualmente esistenti di quel dataset specifico. "ls" non la mostrerà, ma si può fare un "cd" e sarà utilizzabile.

Naturalmente si può usare zfs send/receive in maniera nativa (o un utile software che uso quotidianamente, zfs-autobackup, sia per le istantanee locali che per la replica remota), ma vogliamo salvare i file, non il dataset zfs, in modo da poter eseguire il backup su un file system diverso. Qualsiasi file system. Quindi useremo borg backup.

Supponiamo che il nostro pool ZFS sia chiamato "proxzfs". Ecco uno script di esempio. Naturalmente, questo è il mio script, funziona per me e non sono responsabile se non funziona per voi/distrugge tutti i vostri dati/mangia il vostro server/ecc.

#!/bin/bash

/usr/sbin/zfs snapshot -r proxzfs@forborg

REPOSITORY=yourpath/server/whatever:borgrepository/
TAG=mytag
borg create -v --stats --compression zstd --progress    \
   $REPOSITORY::$TAG'-{now:%Y-%m-%dT%H:%M:%S}'          \
   /proxzfs/*/.zfs/snapshot/forborg/  \
   --exclude '*subvolYouMayWantToExclude-disk-0*'

/usr/sbin/zfs destroy -vrR proxzfs@forborg

borg prune -v $REPOSITORY --stats --prefix $TAG'-' \
   --keep-daily=31 --keep-weekly=4 --keep-monthly=12

Questo piccolo script creerà un'istantanea @forborg per qualsiasi dataset che troverà sotto "proxzfs", quindi avvierà borg e gli chiederà di attraversare le snapshot forborg montate automaticamente all'interno della directory .zfs di qualsiasi dataset.

Quindi distruggerà le istantanee "forborg" ed eseguirà un prune di borg. Questo eliminerà i vecchi backup, in base alla politica impostata. Questo passaggio può essere evitato, ma io preferisco eseguirlo dopo un backup, in modo che il mio repository sia sempre coerente con la mia politica di data retention.

Backup efficienti di container LXC in Proxmox (e non solo)

Stefano Marinelli — Thu, 10 Sep 2020 12:25:19 GMT

NOTA: Il seguente post è la traduzione dell'equivalente sul blog it-notes. L'originale sarà sempre più aggiornato.

A volte un container lxc può essere un'alternativa più valida rispetto ad ad una macchina virtuale KVM. Ha un overhead inferiore, una gestione delle risorse più semplice ed efficiente e un minore impatto sulla macchina fisica.

Continua la lettura… (ulteriori 4 minuti di lettura)

Proxmox Backup Server - Consigli per una buona implementazione

Stefano Marinelli — Mon, 31 Aug 2020 10:25:19 GMT

NOTA: Il seguente post è la traduzione dell'equivalente sul blog it-notes. L'originale sarà sempre più aggiornato.

Proxmox Backup Server (PBS) è stato rilasciato. È ancora in beta ma è già perfettamente utilizzabile. Dopo molti anni, è ora possibile eseguire backup incrementali delle VM e grazie alle dirty bitmap di qemu, i backup sono anche veloci.

Continua la lettura… (ulteriori 1 minuti di lettura)

BTRFS: effettuare automaticamente snapshot e backup remoti

Stefano Marinelli — Wed, 04 Sep 2019 10:40:19 GMT

Utilizzo con soddisfazione BTRFS (ne ho parlato nel 2014 e, più recentemente, nel blog IT-Notes). Non lo considero ottimale per tutti i tipi di carico, ma risolve molti problemi in moltissime situazioni. Una delle cose che utilizzo con più soddisfazione è la funzione di generazione dinamica di snapshot, che garantisce la possibilità di avere una copia perfetta e immediata di uno specifico volume (o subvolume). Quando è necessario un backup, ad esempio, l'utilizzo delle snapshot è fondamentale e averle a livello di file system è senza dubbio un buon ausilio.

Quando si tratta di volumi BTRFS, però, abbiamo ulteriori opzioni. Ci sono strumenti nativi che sono in grado di inviare e ricevere dati da e verso volumi BTRFS in maniera ottimizzata, sfruttando le caratteristiche intrinseche del file system stesso. Ecco dunque un metodo per fare automaticamente delle snapshot e trasferirle, in maniera ottimale, su un altro volume BTRFS (locale o remoto).

Continua la lettura… (ulteriori 2 minuti di lettura)

Alla Ricerca del Backup Perfetto: Borg e Restic

Stefano Marinelli — Wed, 23 May 2018 07:42:37 GMT

English version here

Backup: tecniche principali

In passato ho già affrontato l'argomento backup ponendo alcune basi e dando alcune indicazioni sulle principali modalità e sul perché è fondamentale farlo, sul perché il RAID non può essere considerato una forma di backup e su alcuni software da me presi in esame e utilizzati in precedenza. Invito dunque a leggere l'articolo collegato, per una base di partenza. Questa volta, però, daro delle guide su come io realizzo i backup e su come io riesca a garantire un certo grado di sicurezza.

Backup: le basi di partenza

Proporrò l'argomento sotto forma di elenco puntato, onde coprire le principali problematiche da gestire:

Sistema Operativo e dati da salvare: ogni sistema operativo è un universo. E' ragionevole pensare che non esista una soluzione universale, anche se molti dei principali software open source sono multi-piattaforma. Il principale divario è tra i sistemi Unix-Like (GNU/Linux, BSD, MacOS, ecc.) e Windows. Lo stesso software, pur essendo disponibile per più piattaforme, potrebbe non essere il migliore per la propria o per le proprie necessità.
Tipo di dati da salvare: ogni tipo di backup richiede soluzioni diverse. Ci sono situazioni in cui si ha la necessità di copie pressoché sempre incrementali in quanto i file crescono ma non vengono modificati. In questo caso, un qualunque sistema appunto incrementale (es: Duplicity ) può essere sufficiente. Nel caso, invece, di backup sempre diversi (es: un database che cambia costantemente), un sistema come quello precedente può essere estremamente inefficiente, specialmente nel lungo periodo.
Necessità di crittografia o meno: i backup delle mie fatture, ad esempio, potrei anche evitare di crittarli...
Rapidità di esecuzione e di recupero: ci sono strumenti che sono estremamente efficienti nell'effettuare l'operazione di copia, ma che rendono estremamente lento il recupero. Una delle (poche) carenze da me riscontrate in BURP Backup, di cui ho parlato nell'articolo precedente e che utilizzo ancora con successo in certe situazioni, è che richiede il restore dei file e non consente, per lo meno direttamente, di navigare nel backup come fosse un file system locale. Stesso discorso vale, ad esempio, per il backup nativo di Proxmox: è comodissimo da impostare, completo e nativo ma il tempo di recupero può essere importante, specialmente se effettuato in postazioni remote e su connessioni lente. Recuperare un file richiederà, molto spesso, il recupero totale della macchina.
Snapshot: ultima in lista, ma questione di primaria importanza. Un backup di un file system "live" avrà un momento di inizio e un momento di fine. Nel frattempo, i dati cambieranno all'interno di esso e potrebbe generarsi incoerenza. In passato ho avuto problemi del genere: un database (mysql) di qualche GB è stato rovinato da un cliente e me ne è stato chiesto il recupero. Ho preso, con baldanza, l'ultimo backup e ho ripristinato i vari file (non un dump). Inutile dire che è stato impossibile farlo ripartire: il file molto grande era cambiato troppo tra l'inizio del backup dello stesso e la fine, per cui era incoerente. Per i maliziosi: avevo anche il dump, ovviamente, per cui ho recuperato quello. Ma la questione resta chiara: fare un backup di un file system live è pericoloso, a meno che non si stia copiando la cartella "Documenti" o "Immagini". Un database aperto, come anche semplicemente quello del browser, ha altissime probabilità di corrompersi e rendere inutile la copia di sicurezza fatta. La tecnica è fare uno snapshot dell'intero file system prima di iniziare la copia. Ci sono margini di rischio anche in questo (il backup avrà all'incirca lo stesso stato che avrebbe la macchina se venisse improvvisamente staccata la spina), ma largamente inferiori. Ad oggi, utilizzando snapshot, sono stato in grado di recuperare tutto.

Continua la lettura… (ulteriori 9 minuti di lettura)

Alla ricerca del Backup Perfetto

Stefano Marinelli — Thu, 17 Dec 2015 10:30:00 GMT

English version here

Backup: perché farlo

Da che mondo è mondo, tutto può essere perso. Sia per ragioni accidentali che per ragioni ben ponderate, qualsiasi cosa può essere fatta sparire o può sparire per errore. Quante volte ci sarà capitato di perdere un oggetto e non trovarlo mai più?

Da quando esiste l'informatica, poi, questo concetto si è espanso a dismisura. Mentre è difficile perdere un oggetto, è molto più facile cancellare un file o una informazione dal computer, oppure voler ripristinare una versione precedente.

Molte persone pensano che sia sufficiente garantire che il supporto di memorizzazione sia ridondato, e si è a posto. SBAGLIATO!: un raid senza dubbio aiuta a non perdere tutto in caso di guasto di un disco, ma cosa accade quando il dato viene accidentalmente cancellato, quando viene compromesso per colpa di un virus o di una qualsiasi entità esterna, oppure quando l'elaboratore (raid o meno) viene rubato, o prende fuoco, o una situazione di questo tipo?

Ho collezionato esperienze di ogni genere. Tanto per elencarne alcune:

sale server finite sott'acqua per colpa di alluvioni
server distrutti dal terremoto, ovvero da crolli murari che hanno investito le sale macchine
ransomware vari, che ultimamente colpiscono molto più che in passato
danno volontariamente causato da qualcuno che ne ha tutto l'interesse (es: aziende informatiche che, poco correttamente, causano danni per crearsi lavoro. Sì, ho visto anche questo, e non una sola volta, purtroppo. E sto gestendo una situazione del genere proprio in questi giorni.)
errori da parte dell'amministratore (può succedere a chiunque)

Se poi parliamo di server esposti su Internet (es: e-commerce, server di posta elettronica, ecc.), la situazione diventa ancor più delicata in quanto oltre che la correttezza dei dati, c'è bisogno di garantire anche la continuità operativa del servizio.

La soluzione migliore, dunque, è avere sempre dei backup a disposizione. Ma quali caratteristiche dovrebbero avere questi backup?

Continua la lettura... … (ulteriori 10 minuti di lettura)