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.

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

Caddy è un ottimo server web. È più facile da configurare rispetto a nginx e gestisce le richieste/rinnovi dei certificati ssl, quindi non è necessario utilizzare certbot/cron. A volte si potrebbe preferire usare Caddy invece di Nginx/Apache/Lighttpd/etc.

FreeBSD e Caddy funzionano molto bene insieme per siti web statici/reverse proxy, ma spesso abbiamo bisogno di servire siti web dinamici. Aggiungere PHP è abbastanza facile.

Iniziamo con l'installare e abilitare Caddy:

pkg install caddy  
service caddy enable

Ora installiamo PHP - diciamo PHP 8.1 - e abilitiamo php-fpm:

pkg install php81
service php-fpm enable

Preferisco usare php-fpm tramite socket locali, se il server web e php-fpm sono in esecuzione sullo stesso host. Perciò modifichiamo alcune configurazioni modificando /usr/local/etc/php-fpm.d/www.conf:

Cambiamo la configurazione da:

_listen = 127.0.0.1:9000_

a

_listen = /var/run/php81.sock_

Cambiamo ora il proprietario del socket, basta decommentare:

listen.owner = www  
listen.group = www  
listen.mode = 0660

Avviamo ora php-fpm:

service php-fpm start

Ora va modificato /usr/local/etc/caddy/Caddyfile. Basta aggiungere qualcosa del genere:

my.website.com {  
root * /usr/local/www/website  
php_fastcgi unix//var/run/php81.sock  
file_server  
}

Questo configurerà un virtualhost chiamato my.website.com (e Caddy cercherà di ottenere un certificato per esso), con la sua radice su /usr/local/www/website e processerà qualsiasi richiesta di file .php tramite php socket. La direttiva file_server assicura che i file statici possano essere serviti dal percorso principale.

Avviamo ora Caddy:

service caddy start

Questo è tutto. Naturalmente si tratta di una configurazione molto elementare, ma può essere usata come bozza per setup più avanzati. Per esempio, si può aggiungere qualcosa del tipo:

    @disallowed {
        path /xmlrpc.php
        path *.sql
        path /wp-content/uploads/*.php
    }

    rewrite @disallowed '/index.php'

e potrete avere un'installazione di Wordpress funzionante (e abbastanza sicura).