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

A volte il filesystem si blocca. Non è possibile eseguire alcuna operazione e un "riavvio" causerà solo un tempo di attesa indefinito per l'I/O. È possibile accedere al server tramite ssh (o login tramite console), ma non è possibile eseguire alcuna operazione perché i dispositivi di archiviazione sono bloccati. Questo può accadere a causa di un problema sul file system o di uno strano bug del kernel. È più probabile che questo accada quando si ha a che fare con interfacce esterne collegate via usb.

Esiste un codice "magico" che attiva una condizione specifica del kernel e causa un riavvio.

Attenzione, questi comandi devono essere considerati come l'ultima risorsa. Non verrà eseguito il flush del disco, né verrà avviata la procedura di spegnimento, per cui si rischia di distruggere completamente il file system o qualsiasi file aperto.

Tuttavia, questa potrebbe essere l'opzione migliore che avete a disposizione e non sarà più dannosa di un hard reset o di un "tradizionale" cable pull - ma potete farlo da remoto.

Ricordate di lanciare i comandi con i privilegi di root:

Su Linux:

echo b > /proc/sysrq-trigger

In questo modo si attiverà un riavvio immediato - non verranno eseguite ulteriori operazioni sul disco.

Su FreeBSD:

sysctl debug.kdb.panic=1

Verrà generato un kernel panic che (per impostazione predefinita) causerà un riavvio.

Ho deciso di riprendere a scrivere più regolarmente su questo blog. Nei suoi primi anni di vita ero abbastanza assiduo, avevo anche un discreto seguito sia di lettori che di commentatori. Poi l’avvento dei social network ha freddato e ridotto l’interesse verso i blog e i miei impegni lavorativi hanno portato via sempre più tempo alla stesura dello stesso. Negli ultimi anni mi sono concentrato (un po’) di più sul blog tecnico, IT Notes.

Le cose stanno cambiando. I social non sono più così seguiti come un tempo e i blog stanno vivendo una seconda giovinezza. Proprio per questa ragione ho deciso di tornare ad essere un po’ più assiduo, sempre nei limiti del possibile. Scriverò sia di questioni tecniche, specialmente traducendo gli articoli che scriverò su IT Notes, ma anche di questioni di tutt’altro genere.

Un diario pubblico, uno spazio in cui esternare le mie osservazioni del mondo, della società e dell’evoluzione che, volenti o nolenti, ci travolge giorno per giorno.

Stay tuned :-)

An English version of this article (and following about the same topic, not available in Italian) may be found here

Sono un utente Linux (o GNU/Linux, per i puristi) dal 1996. Sono un utente FreeBSD dal 2002. Ho sempre utilizzato con successo entrambi i sistemi operativi, ognuno per specifici scopi. Ho trovato, in media, i sistemi BSD più stabili rispetto agli equivalenti Linux. Per stabilità non intendo l’uptime (troppo uptime vuol dire pochi aggiornamenti di sicurezza del kernel, il che è sbagliato). Intendo che le cose funzionino come devono, che non si “rompano” da un aggiornamento all’altro e che non si renda necessario rivedere tutto per colpa di un comando base sparito o modificato.

Sono sempre stato a favore dello sviluppo e dell’innovazione a patto che essa non renda (necessariamente, automaticamente e immotivatamente) incompatibile tutto ciò che è già in essere. E la strada che le varie distribuzioni di Linux stanno prendendo sembra proprio quella del modificare cose che funzionano solo per il gusto di farlo oppure per seguire i diktat del Kernel e di chi lo gestisce - ma non solo.

Già da un po’ di tempo ho iniziato un’operazione complessa, continua e non sempre lineare ovvero quella di migrare, ove possibile, buona parte dei server (nostri e dei nostri clienti) da Linux a FreeBSD.

Perché proprio FreeBSD?

Ci sono molti sistemi operativi alternativi a Linux e la famiglia dei *BSD è variegata e completa. FreeBSD, a mio avviso, è ad oggi il sistema “all rounder” per eccellenza, ovvero ben rifinito e adatto sia all’utilizzo su grossi server che su piccoli sistemi embedded. Gli altri BSD hanno punti di forza che, in alcuni campi, li rendono particolarmente adatti ma FreeBSD, a mio avviso, è adatto (quasi) ad ogni scopo.

Tornando dunque all’argomento principale dell’articolo, perché sto migrando molti dei server che gestisco a FreeBSD? Le ragioni sono molte, ne elencherò alcune con le relative spiegazioni.

Il sistema è coerente - kernel e userland sono creati e gestiti dallo stesso gruppo

Uno dei problemi alla base di Linux è che (ricordiamolo) è un kernel, tutto il resto viene creato da persone/aziende diverse. In più di una occasione Linus Torvalds nonché altri tra i principali sviluppatori del kernel Linux hanno rimarcato che a loro interessa lo sviluppo del kernel stesso, non come gli utenti lo utilizzeranno. Nelle scelte tecniche, dunque, non si tiene conto di quello che è il reale utilizzo dei sistemi ma che il kernel vada per la sua strada. Questo è un bene, in quanto lo sviluppo del kernel Linux non viene “frenato” dalla lotta tra le distribuzioni e soluzioni software presenti, ma allo stesso tempo è anche uno svantaggio. In FreeBSD, kernel e relativo userland (dunque tutti i componenti del sistema operativo base) vengono sviluppati dallo stesso team e c’è, dunque, una forte coesione tra le parti. In molte distribuzioni Linux c’è stato bisogno di “deprecare” ifconfig a favore di ip in quanto nuovi sviluppi avvenuti nel kernel non erano più sfruttabili da ifconfig, a meno di romperne la compatibilità con le altre (precedenti) versioni kernel oppure avere funzioni (sulla stessa interfaccia di rete) gestite da tool diversi. In FreeBSD ad ogni release del sistema operativo ci sono sia kernel che userland aggiornati per cui queste modifiche vengono coerentemente inserite e documentate, rendendo i tool compatibili con i relativi aggiornamenti lato kernel.

In parole povere, in FreeBSD non c’è bisogno di “rivoluzionare” tutto ogni pochi anni e le modifiche vengono fatte principalmente sotto forma di aggiunte in grado di arricchire (e non di rompere) ogni aggiornamento. Se una modifica dovesse cambiare il modo di interfacciarsi ai dispositivi di rete, ifconfig verrebbe modificato per trarne beneficio e restare compatibile con la “vecchia” sintassi. A lungo termine, questo tipo di approccio viene decisamente apprezzato dagli amministratori di sistema che si trovano ad avere un percorso di aggiornamenti lineare, coerente e sempre ben documentato.

Lo sviluppo di FreeBSD è (ancora) guidato da interessi tecnici, non strettamente commerciali

Linux e relative distribuzioni hanno ormai contributi da moltissime imprese, molte delle quali (ad esempio: Red Hat) spingono (giustamente) nella direzione di ciò che sia comodo per loro, loro prodotti e loro servizi. Essendo grossi contributori del progetto hanno un grosso peso per cui, di fatto, le loro soluzioni diventano spesso degli standard de-facto. Si pensi a systemd - c’era davvero bisogno di un sistema del genere? Pur apportando alcuni vantaggi, ha aggiunto una certa complessità ad un sistema altrimenti estremamente semplice e funzionale. E’ tutt’ora divisivo e molti si chiedono: “ma era davvero necessario? I vantaggi portati hanno bilanciato gli svantaggi?”. 70 file binari solo per inizializzare e loggare e un milione e mezzo di righe di codice solo per questo? Ma Red Hat ha lanciato il sasso…e molti si sono accodati. Perché a volte è bello seguire la mode, l’hype di una specifica soluzione.

Anche FreeBSD ha grosse realtà dietro, che collaborano in maniera più o meno diretta. La licenza è più permissiva, dunque non tutti coloro che lo utilizzano in maniera commerciale poi contribuiscono, ma sapere che FreeBSD è alla base delle CDN di Netflix, dei server di Whatsapp (in attesa che Meta li sostituisca, per ragioni di coerenza interna, con server Linux), delle Sony Playstation e, in parte, di MacOS, iOS, iPadOS, ecc. sicuramente fornisce rassicurazioni sul suo livello. Queste realtà, però, non hanno un peso tale da guidare lo sviluppo del team principale.

Linux ha Docker, Podman, lxc, lxd, ecc ma… FreeBSD ha le jail!

Le jail di FreeBSD sono potentissimi strumenti per inscatolare e separare i servizi. Ci sono polemiche sul fatto che Docker non giri su FreeBSD ma io credo (come molti) che FreeBSD abbia uno strumento più potente. Le jail sono più vecchie e mature - e di molto - rispetto qualunque soluzione di containerizzazione su Linux. Le jail sono efficienti e sono ben integrate in tutto il sistema operativo. Tutti i principali comandi (ps, kill, top, ecc.) sono in grado di mostrare anche le informazioni relative alle jail. Ci sono molti strumenti di gestione ma, di fatto, tutti fanno la stessa cosa: si interfacciano con FreeBSD base e creano dei file di configurazione su misura. Personalmente mi trovo molto bene con BastilleBSD ma ci sono molti strumenti decisamente validi, nonché una sufficientemente semplice gestione manuale. Quando ho bisogno di Docker lancio una macchina Linux - spesso Alpine, che ritengo essere un’ottima distribuzione minimalista, oppure Debian. Ma sto spostando molti servizi da docker ad una jail dedicata su FreeBSD. I container Docker sono un ottimo strumento di distribuzione rapida (e coerente) di software, ma non sono tutte rose e fiori. I container, ad esempio, si basano su immagini che a volte invecchiano e non vengono più aggiornate. Questo è un problema di sicurezza da non trascurare.

Linux ha ext4, xfs, btrfs… (e zfs, ma con qualche intervento manuale). FreeBSD ha UFS2 e ZFS

UFS2 è un file system ancora molto valido ed efficiente e, configurato per usare i softupdates, in grado di effettuare live snapshot del file system. Questo è ottimo per i backup. Ext4 e XFS non supportano snapshot se non attraverso strumenti esterni (come DattoBD o snapshot attraverso il volume manager). Tutto ciò funziona, certo, però non è nativo. Btrfs è ottimo nelle intenzioni ma non è ancora così stabile come dovrebbe essere dopo tutti questi anni di sviluppo. FreeBSD supporta ZFS in maniera nativa nel base system e questo porta molti vantaggi: separazione dei dataset per le jail, nonché i Boot Environment, per fare delle snapshot prima di aggiornamenti/modifiche e poter fare il boot (da bootloader) anche su un BE differente, ecc.

La procedura di boot di FreeBSD è più semplice e lineare

Linux usa da sempre ottimi strumenti come grub, lilo (oggi ormai superato), ecc. FreeBSD da sempre utilizza un sistema molto lineare e coerente di boot, con il suo bootloader e la sua partizione dedicata di boot. Che sia su mbr, gpt, ecc. le cose sono molto simili e coerenti. Non ho mai avuto problemi a far fare boot ad un sistema FreeBSD dopo uno spostamento o recupero da backup. Su Linux, invece, a volte grub mi ha dato noie, anche dopo un semplice aggiornamento di sicurezza del kernel.

Lo stack di rete di FreeBSD è (ancora) superiore a quello di Linux - e, spesso, lo sono anche le sue prestazioni

Meta, da anni, sta cercando di portare le prestazioni dello stack di rete di Linux a livello di quello di FreeBSD. Molti si chiederanno perché, allora, non spostare i servizi su FreeBSD. Grosse aziende con enormi datacenter non possono cambiare soluzione da un giorno all’altro e i loro tecnici, a qualunque livello, sono esperti Linux. Hanno investito molto su btrfs, su Linux, sulle loro peculiarità. Chiaramente, all’acquisizione di Whatsapp, hanno preferito migrare i “pochi” server di Whatsapp a Linux e spostarli nei loro datacenter. In merito alle reali prestazioni di sistema (ovvero trascurando i benchmark, utili solo fino ad un certo punto), FreeBSD brilla, specialmente in condizioni di alto carico. Dove Linux inizia a boccheggiare (es: in attesa di I/O) con il 100% di CPU, FreeBSD ha un carico di processore più basso e spazio per altre cose. Nel mondo reale (dei miei server e tipi di carico), ho a volte riscontrato dei forti rallentamenti di sistema a causa di un forte I/O, anche sei i dati da processare non dipendevano da letture/scritture. Su FreeBSD ciò non accade e se c’è qualcosa di bloccante, blocca QUELLA operazione, non il resto del sistema. Durante lo svolgimento dei backup o di altre operazioni importanti questo fattore diventa estremamente importante per garantire prestazioni adeguate (e stabili) di sistema.

Semplicità nell'analisi delle prestazioni di sistema

FreeBSD, nel base system, ha tutti gli strumenti per analizzare eventuali problemi e carichi della macchina. “vmstat” , in una riga, mi dice se la macchina sta faticando per CPU, per I/O o per Ram. “gstat -a” mi mostra quanto, disco per disco, partizione per partizione, sia attivo lo storage, anche in percentuale rispetto alle sue prestazioni. “top”, poi, ha anche il supporto per capire, processo per processo, quanto I/O venga utilizzato (opzione “m”). Su Linux, per ottenere gli stessi risultati, bisogna installare applicazioni specifiche, diverse da distribuzione a distribuzione.

Bhyve è più incompleto (ma più prestante) di KVM

Per i miei utilizzi, Bhyve è un ottimo strumento di virtualizzazione. KVM è decisamente più completo ma non avendo esigenze particolari e specifiche non coperte da Bhyve su FreeBSD, con questa combinazione ho trovato (mediamente) prestazioni migliori. Su FreeBSD manca però il KSM che, in alcuni casi, è molto utile.

Abbandonerò dunque Linux per FreeBSD? Ovviamente no, così come non l’ho fatto negli ultimi 20 anni. Entrambi hanno i loro utilizzi, il loro spazio, i loro punti di forza. Però se fino ad oggi ho avuto un 80% Linux e 20% FreeBSD, la prospettiva è quella di invertire le percentuali di utilizzo e, ove possibile, implementare direttamente soluzioni basate su FreeBSD.

Non avrebbe senso descrivere di nuovo ciò che è accaduto, ormai lo sanno praticamente tutti: ho.mobile ha subito un attacco e i dati personali di moltissime persone sono stati trafugati e messi in vendita nel dark web. Il gestore ha prima negato, poi indagato, poi ammesso (in ritardo), minimizzato (incredibilmente, vista la gravità della situazione) e, ad oggi, sembra ci sia un gran pastrocchio (cambiano codici seriali delle SIM ad alcuni utenti, ad altri, anche se "bucati", no...) così come sembra molto difficile cambiare gestore (portabilità bloccate o molto, molto lente).

Tanto per dirla in tono amichevole stanno facendo una magra figura da qualunque punto di vista la si voglia vedere, specialmente considerando che Ho è di Vodafone, dunque dovrebbe avere le spalle e l’esperienza di un colosso abituato a problemi di ogni genere.

Alla mia età sono ancora abbastanza giovane da avere una mente assetata di novità ma abbastanza vecchio da aver fatto esperienza e averne viste di ogni genere.

Intanto dico subito che tutto ciò non mi meraviglia. Può davvero accadere, anche se non dovrebbe. E vi spiego uno dei motivi per cui ciò avviene.

Mi trovo sempre più spesso, per ragioni professionali, a discutere con dei clienti o colleghi. Ormai il motto non è più quello di fare un lavoro fatto bene, con tecnologie e metodi chiari e semplici, mantenerlo in buona salute e far funzionare il tutto. Oggi o si seguono le mode ("tutti vogliono la blockchain, la facciamo anche noi?", "mettiamo su un cluster Kubernetes per il nostro sito statico da 10 visite al giorno") oppure si fanno delle cose, spesso in maniera dozzinale, e si lasciano in produzione per anni, senza curarsi delle conseguenze. Prima o poi se ne paga il prezzo. E, spesso, il prezzo è altissimo.

Alcuni miei clienti si sono rivolti, in passato, a team di sviluppatori cinesi o indiani. I costi erano ridicoli, i presupposti ottimi. Il lavoro svolto è stato pessimo, con una bella facciata ma colonne di sabbia e sono spariti appena incassato il dovuto. Lasciando guai e problemi a chi deve mandare avanti l’infrastruttura.

Un (ex) cliente mi ha telefonato dicendo che il server appena fatto era stato bucato pochi giorni dopo essere stato messo online. Da un’indagine molto breve è venuto fuori che il Wordpress aveva utente amministrativo "admin" e password, da loro impostata, "admin". Come si può tamponare una leggerezza del genere? Ho risolto, mio malgrado, dicendo al cliente che non avremmo più potuto collaborare visti i loro standard di sicurezza.

Caratteristica del mestiere informatico è sempre stata il non richiedere una particolare formazione ma consentire a chiunque di svolgerla, pur senza studi specifici.

Oggi stiamo assistendo alle estreme conseguenze di questa situazione: ci si trova a lavorare molto spesso con persone con scarsa formazione e che fanno esperienza solo sul campo. Mancando però delle basi teoriche e di partenza, volenti o nolenti avranno molto spesso delle lacune. Il guaio è che, come spesso accade, chi sa è pieno di dubbi mentre chi non sa è pieno di certezze. Il risultato è semplice: si mette in produzione qualcosa di insicuro, carente, pericoloso e dozzinale. Il risultato? Ciò che è accaduto ad ho.mobile.

Ammetto con un certo grado di tristezza di essere preoccupato per alcune delle situazioni che gestisco online. Pur essendo abbastanza intransigente, vengo a volte costretto (ubi maior...) a dover chiudere un occhio di fronte a cantonate tecniche, pratiche di sicurezza inesistenti, sistemi non aggiornati e vulnerabili in quanto "non abbiamo tempo per aggiornare" o "i ragazzi sono giovani, non sanno prendere in mano la situazione".

In altri casi passo la vita a ripristinare da backup dei CMS che vengono bucati quotidianamente. "Non abbiamo tempo di aggiornare, tu ripristina poi vedremo". Poi il silenzio, fino all'hack successivo.

No, non è questo il modo corretto di lavorare, purtroppo. Oggi di base mancano due cose: vera formazione (non un corso online ma della vera formazione strutturata) prima di affacciarsi al mondo dell’IT e, come causa e conseguenza di ciò, l’umiltà di capire i propri limiti e mettersi in gioco. Ci sono persone che arrivano senza esperienza ma che, con buona volontà e impegno, imparano sul campo anche meglio di chi magari ha passato anni a studiare certificazioni o in facoltà. Per fortuna ho molti colleghi e amici che rientrano in questa categoria.

Ma molti oggi si affacciano senza titoli, senza esperienza, senza formazione e senza preparazione di alcun genere ma vogliono comandare, decidere, imporre ed avere ragione. Tutto si può imparare ma ci vogliono la volontà di farlo e la giusta umiltà di capire cosa studiare, non quell’estrema tracotanza che contraddistingue, purtroppo, molte figure (specialmente giovani) nel mondo dell’IT.

Dunque no, ciò che è accaduto ad ho.mobile non dovrebbe accadere. Ma fretta, scarsa attenzione, arroganza e incompetenza creano delle voragini che, prima o poi, verranno sfruttate.

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.

Si ottiene (potenzialmente) meno isolamento dalla macchina fisica e si è costretti ad usare il kernel dell’host. Inoltre, non è possibile eseguire un sistema operativo diverso.

Proxmox supporta in maniera nativa i container lxc ed essi sono spesso una buona scelta. Ho recentemente convertito alcune VM in container lxc e sono più veloci, più leggeri e l'occupazione della ram è abbastanza bassa.

Ci sono due grossi svantaggi: non è possibile migrare un container lxc in esecuzione (deve essere spento, spostato e riavviato - se si usa uno storage condiviso, spesso è una questione di secondi) e i backup su Proxmox Backup Server sono più lenti rispetto al backup di una VM.

Questo perché una VM può monitorare, grazie alle dirty bitmap di KVM, le sue operazioni su disco per sapere in anticipo quali blocchi devono essere controllati e copiati. Quando si ha a che fare con i container lxc non è possibile farlo, quindi ogni operazione di backup dovrà controllare ogni singolo file - questo si è dimostrato efficiente in termini di spazio e deduplicazione, ma piuttosto lento in termini di tempo. Una delle mie VM (750 GB memorizzati ma con sporadico accesso al disco) ha richiesto solo alcuni minuti per il backup con dirty bitmap, ma più o meno 2 ore per il backup da quando è stata trasformata in un contenitore lxc.

Il backup con borg si è dimostrato abbastanza efficiente, così ho cercato di trovare un modo per eseguire il backup di quei contenitori eseguendo una snapshot, eseguendo il backup e, poi, rilasciandola.

Non possiamo usare dattobd sul container, quindi dobbiamo fare una snapshot e fare il backup direttamente dall'host. Questo ha un grande vantaggio: non abbiamo bisogno che il container conosca la sua posizione di backup in quanto ogni operazione sarà fatta dall'host Proxmox.

I miei container sono generalmente memorizzati in volumi rbd di Ceph o in thin pool di LVM.

Ho creato uno script per affrontare entrambe queste situazioni - e non dipende da Proxmox, quindi funziona anche se non lo si usa.

Prima di tutto, si dovrebbe creare un utente e un repository borg su una macchina remota e permettere all'host Proxmox di effettuare il login via ssh usando una chiave. Poi, creare una directory (/tobackup nei seguenti script, sull'host) dove verranno montate le snapshot.

Nell'esempio/script seguente, non verrà utilizzata alcuna crittografia per la memorizzazione di backup. Se si desidera crittografare il backup, sarà necessario eseguire piccole modifiche.

Ecco il mio rbd_borg_bck.sh :

#!/bin/bash
set -e

export SOURCE_DISK=$1
export USERNAME=$2
export HOST=$3

PATH="/usr/local/jdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/pkg/bin:/usr/pkg/sbin"
export PATH

export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes;

echo "Creating and mapping snapshot..."
rbd snap create $SOURCE_DISK@tobackup && DDISK=`rbd map $SOURCE_DISK@tobackup`

echo "Creating backup directory..."
mkdir -p /tobackup/$DDISK

echo "Mounting snapshot..."
mount -o noload $DDISK /tobackup/$DDISK

echo "DOING BACKUP..."

REPOSITORY=$USERNAME@$HOST:$USERNAME/
TAG=daily

borg create -v --stats --progress --compression zlib,9                           \
    $REPOSITORY::$TAG'-{now:%Y-%m-%dT%H:%M:%S}'          \
    /tobackup/$DDISK/                                       \
    --exclude '*/home/*/.cache*'                  \
    --exclude '*/home/*/.local*'                  \
    --exclude '*/home/*/.pki*'                    \
    --exclude '*/home/*/Virtualbox VMs*'          \
    --exclude '*/home/*/.vagrant.d*'              \
    --exclude '*/root/.cache*'                    \
    --exclude '*/var/swap*'

sleep 3s;

echo "Unmounting snapshot..."
umount /tobackup/$DDISK

sleep 3s;

echo "Unmapping snapshot..."
rbd unmap $DDISK

echo "Remove snapshot..."
rbd snap remove $SOURCE_DISK@tobackup

echo "Pruning..."
borg prune -v $REPOSITORY --stats --prefix $TAG'-' \
    --keep-daily=14 --keep-weekly=8 --keep-monthly=12

echo "Done!"

Per esempio, per eseguire il backup di un disco memorizzato nel pool "vmrbdpool" denominato vm-101-disk-0 tramite ssh sul server backupserver.mydomain.org, nome utente sul server (e nome del repository, all'interno della directory home di quell'utente, chiamato server01), si può lanciare lo script in questo modo:

/usr/local/bin/rbd_borg_bck.sh vmrbdpool/vm-101-disk-0 server01 backupserver.mydomain.org

Questo può anche essere programmato e lanciato da cron (sull'host Proxmox) o in qualsiasi altro modo.

Per i thin pool di LVM, lo script è un po' diverso. Ecco il mio lvm_thin_borg_bck.sh

#!/bin/bash
set -e

export SOURCE_DISK=$1
export USERNAME=$2
export HOST=$3
export LVM=$4
export DDISK=$4/$2-borgsnap

PATH="/usr/local/jdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/pkg/bin:/usr/pkg/sbin"
export PATH

export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes;

echo "Creating and mapping snapshot..."
lvcreate -n $2-borgsnap -s $1
lvchange -ay -Ky $DDISK


echo "Creating backup directory..."
mkdir -p /tobackup/$DDISK

echo "Mounting snapshot..."
mount -o ro /dev/$DDISK /tobackup/$DDISK

echo "DOING BACKUP..."

REPOSITORY=$USERNAME@$HOST:$USERNAME/
TAG=daily

borg create -v --stats --progress --compression zlib,9                           \
    $REPOSITORY::$TAG'-{now:%Y-%m-%dT%H:%M:%S}'          \
    /tobackup/$DDISK/                                       \
    --exclude '*/home/*/.cache*'                  \
    --exclude '*/home/*/.local*'                  \
    --exclude '*/home/*/.pki*'                    \
    --exclude '*/home/*/Virtualbox VMs*'          \
    --exclude '*/home/*/.vagrant.d*'              \
    --exclude '*/root/.cache*'                    

sleep 3s;

echo "Unmounting snapshot..."
umount /tobackup/$DDISK

sleep 3s;

echo "Remove snapshot..."
yes | lvremove $DDISK

echo "Pruning..."
borg prune -v $REPOSITORY --stats --prefix $TAG'-' \
    --keep-daily=14 --keep-weekly=8 --keep-monthly=12

echo "Done!"

In questo esempio, vogliamo fare il backup di un disco "/dev/prox1/vm-120-disk-0", il nome utente sul server è server01 (stesso nome del repository), il server è backupserver.mydomain.org e, come ultimo argomento, "prox1" che è il pool lvm.

/usr/local/bin/lvm_thin_borg_bck.sh /dev/prox1/vm-120-disk-0 server01 backupserver.mydomain.org prox1

Borg è efficiente e veloce e, grazie a questo tipo di configurazione, posso creare un backup del container da 750 GB in 2 minuti.

Grazie a questo tipo di configurazione, i backup possono essere effettuati in modo coerente ed efficiente.