~/magostinelli - borg

Backup con Borg e Borgmatic

Unknown — Tue, 17 Feb 2026 00:00:00 +0000

</a> Backup con Borg e Borgmatic</h1>

Se anche tu sei un self-host compulsivo, la questione dei backup non è una scelta, ma una necessità. Dopo anni di utilizzo e varie prove, su tutti i miei server, utilizzo Borg come software per il backup: non solo è molto affidabile (ho avuto bisogno del restore qualche volta) ma anche straordinariamente semplice da gestire.

In questo articolo ti mostrerò perché questi due software hanno conquistato il mio cuore (e i miei dati), come funzionano e soprattutto come iniziare a usarli nel tuo ambiente self-hosted.

</a> Chi è Borg e Perché Dovresti Usarlo</h2>
Borg (BorgBackup) è un software di backup dedicato alla deduplica, compressione e cifratura dei dati. Sviluppato in Python con componenti critici in C, è stato pensato fin dall'inizio per essere veloce, efficiente e sicuro. A differenza di soluzioni più tradizionali, Borg non crea semplici copie dei tuoi file, ma applica una serie di tecniche sofisticate per rendere i backup efficienti e gestibili.
Borgmatic è un'estensione di Borg e permette di configurare il nostro backup attraverso un unico file di configurazione.

</a> Le Tre Caratteristiche che Cambiano il Gioco</h3>
Deduplica: Questo è il punto che rende Borg veramente speciale. Immagina di avere 100 GB di dati e di fare un backup ogni giorno. Con i backup tradizionali, finiresti per avere 2.8 TB di dati in un mese (100 GB × 28 giorni). Con Borg, se solo il 5% dei tuoi dati cambia ogni giorno, utilizzerai solo circa 140 GB di spazio totale (100 GB iniziali + 5 GB × 28 giorni). Borg identifica i file identici e i blocchi di dati duplicati, memorizzandoli una sola volta.
Compressione: Borg comprime i dati utilizzando algoritmi come ZSTD, riducendo ulteriormente lo spazio occupato. Un documento di testo compresso può ridursi del 90%, immagini del 20-30%, database del 40-60%. La compressione avviene durante il backup, non dopo, quindi non impatta sulla velocità di accesso ai dati ripristinati.
Cifratura: Tutti i tuoi backup sono cifrati end-to-end con AES-256. Significa che anche se qualcuno riuscisse ad accedere al tuo repository di backup, non potrebbe leggere nulla senza la passphrase. La cifratura viene applicata sia in transito (se usi SSH) che a riposo sul disco.
Grazie a queste tre caratteristiche puoi usare anche un servizio esterno per il tuo backup, cosi avrai i tuoi dati al sicuro in un luogo diverso rispetto a quello di dove girano i tuoi servizi.
</a> Il Vantaggio Decisivo: Point-in-Time Recovery</h2>
Tra le molte cose che Borg fa bene, il point-in-time recovery è una capacità che raramente ho visto in altri backup tools gratuiti. Cosa significa? Semplicemente che puoi ripristinare i tuoi dati a qualsiasi punto nel tempo in cui hai eseguito un backup.
Facciamo un esempio concreto. Sei lunedì alle 14:30 e realizzi che un file importante è stato eliminato accidentalmente venerdì scorso. Con Borg, puoi accedere al backup di giovedì mattina alle 08:00 e recuperare esattamente quello che ti serve. Non è "il file è sparito, è perso per sempre", ma "posso scegliere quale versione del mio sistema voglio ripristinare".
Questo funziona perché ogni volta che esegui un backup con Borg, viene creato un "snapshot" completo dello stato del tuo sistema in quel momento. Borg poi usa la deduplica per assicurarsi che lo spazio aggiuntivo necessario sia minimo, ma tu mantieni sempre accesso a qualsiasi versione precedente.
borg init --encryption=repokey /mnt/backup borg create /mnt/backup::{now} /home/utente/dati </code></pre> Perfetto per chi vuole un backup fisico nelle vicinanze e non si preoccupa di perdere tutto se la casa prende fuoco (per quello servono i backup remoti).
</a> Self-Hosted: Il Backup su un Altro Server</h3>
Questo è il mio setup preferito per il self-hosting. Hai il tuo server principale dove girano Nextcloud, il tuo Git personale, la tua email, quello che vuoi. E hai un secondo server (anche molto meno potente) dove archi i backup.
Borg comunica via SSH e comprime/cifra tutto prima di inviare i dati. Anche se il server di backup venisse compromesso, non potrebbero leggere nulla. Il comando diventa:
borg create ssh://utente@backup.example.com:22/path/to/repo::{now} /dati/importanti </code></pre> Bellissimo, vero? Un server, una passphrase, tutto cifrato. E lo spazio utilizzato è ridicolmente piccolo grazie alla deduplica.
</a> Un Dettaglio Fondamentale: Il Modello Client-Server</h3>
C'è una cosa importante da capire se decidi di fare il backup su un server remoto: Borg deve essere installato su entrambe le macchine.
A differenza di altri strumenti che usano il protocollo SFTP o rsync "passivo", Borg utilizza un modello client-server. Quando avvii un backup, il tuo server locale (il client) si connette via SSH al server di destinazione e avvia un'istanza di Borg anche lì (il server).
Perché questa complicazione? In realtà è un enorme vantaggio per due motivi:

Efficienza: Il server remoto calcola localmente quali pezzi di dati possiede già, evitando di farti inviare file che sono già nel repository.</li>
Integrità: Il processo remoto verifica che i dati arrivino correttamente e gestisce la scrittura sul disco in modo atomico.</li> </ul>
Ad esempio, se stai usando una VPS Debian come destinazione, ricordati di fare un semplice apt install borgbackup</code>, altrimenti il client non saprà con chi parlare e riceverai un errore del tipo Remote: bash: borg: command not found.
</a> Servizi di Terze Parti: Hetzner e Simili</h3> Se non vuoi gestire il tuo server di backup, ci sono servizi come Hetzner Storage Box che offrono spazio di backup a costi molto bassi (qualche euro al mese per TB). Borg lavora perfettamente con loro e mantiene la stessa garanzia di cifratura end-to-end. Ad esempio, Hetzner (non mi hanno sponsorizzato), offre un servizio molto economico e ben funzionante chiamato storage box: https://www.hetzner.com/storage/storage-box/ (Ci sono pacchetti con vari tagli di spazio disco). </a> Borg e l'Ecosistema Self-Hosted</h2> Due sistemi che uso hanno adottato Borg come soluzione di backup nativa: YunoHost: Se usi YunoHost per gestire il tuo server, i backup sono gestiti di default attraverso Borg. L'interfaccia web di YunoHost ti permette di configurare tutto con pochi click. Scegli la destinazione, inserisci i parametri (credenziali e url), e il sistema si occupa di tutto. Nextcloud AIO (All-in-One): Nextcloud AIO, il modo più moderno di deployare Nextcloud, ha integrato Borg come sistema di backup predefinito. Quando installi Nextcloud AIO, la possibilità di fare backup via Borg è già incorporata. Questo dovrebbe dirvi tutto quello che dovete sapere sulla fiducia che anche i principali progetti ripongono in Borg. </a> Borgmatic: Quando Borg Diventa Semplice</h2> Borg è fantastico, ma ha una curva di apprendimento. I comandi sono molti, le opzioni sono numerose, e ricordare tutti i parametri ogni volta è difficile. Qui entra in gioco Borgmatic. Borgmatic è uno strato di semplificazione costruito sopra Borg. È un software che prende un file di configurazione (YAML, molto leggibile) e trasforma complessi flussi di backup in un singolo comando: borgmatic</code>. Non solo, ma Borgmatic aggiunge funzionalità utili come le notifiche, la verifica automatica dei backup, il controllo della salute del repository e molto altro. </a> Configurare Borgmatic: Un Esempio Pratico</h3> Per iniziare con Borgmatic, installa il pacchetto: pip install --user borgmatic </code></pre> Poi crea la directory di configurazione: mkdir -p ~/.config/borgmatic </code></pre> E un file di configurazione di base: # Configurazione di Borgmatic - salva come ~/.config/borgmatic/config.yaml source_directories: - /home/utente/documenti - /home/utente/progetti - /etc/ repositories: - label: backup_principale path: /mnt/discoesterno/backup # Se vuoi un backup remoto SSH, usa questo: # path: ssh://utente@backup.example.com:22/backups/mio_server retention: keep_daily: 7 keep_weekly: 4 keep_monthly: 12 keep_yearly: 2 checks: - name: repository frequency: 2 weeks - name: archives frequency: 4 weeks hooks: before_backup: - echo "Inizio backup a $(date)" after_backup: - echo "Backup completato con successo" on_error: - echo "ERRORE durante il backup!" </code></pre> Ora, per fare un backup completo, basta eseguire: borgmatic </code></pre> Questo comando: Effettua il backup di tutti i directory elencati</li> Applica la deduplica e la compressione</li> Cifra tutto con la tua passphrase</li> Applica le politiche di retention (mantiene 7 backup giornalieri, 4 settimanali, etc.)</li> Verifica l'integrità del repository secondo il calendario definito</li> Esegue gli hook (comando prima e dopo il backup)</li> </ol> </a> Automazione con Cron</h3> Ora che hai configurato Borgmatic, il passo logico è automatizzare il backup. Aggiungi una voce al crontab: crontab -e </code></pre> E aggiungi questa riga per eseguire il backup ogni giorno alle 02:00 di notte: 0 2 * * * /home/utente/.local/bin/borgmatic -c /home/utente/.config/borgmatic/config.yaml </code></pre> Se vuoi eseguire il backup ogni 6 ore: 0 */6 * * * /home/utente/.local/bin/borgmatic -c /home/utente/.config/borgmatic/config.yaml </code></pre> </a> Il Superpotere di Borgmatic: I Database</h2> Se gestisci servizi come Nextcloud, Ghost o un qualsiasi stack LAMP/LEMP, sai che salvare i file non basta: devi mettere al sicuro il database. Di solito questo significa scrivere uno script che fa il dump, lo salva in una cartella e poi Borg lo carica. Borgmatic fa tutto da solo. Può collegarsi ai tuoi database, farne il dump "al volo" e inviarlo direttamente nel repository di backup senza sporcare il disco con file temporanei. Ecco come aggiungere il supporto per i database nel tuo config.yaml: # Aggiungi questo al tuo file di configurazione databases: - name: nextcloud_db type: postgresql # o mysql / mariadb / sqlite username: nextcloud_user # Se il DB gira in un container, puoi specificarlo qui: # hostname: localhost </code></pre> </a> Perché è fondamentale per Nextcloud?</h3> Nextcloud salva i metadati dei file, i contatti, i calendari e le configurazioni nel database. Se ripristini solo la cartella data ma non il database, ti ritroverai con un'istanza "rotta". Con questa configurazione, Borgmatic: Blocca (se necessario) e interroga il DB.</li> Trasmette il contenuto crittografato al volo.</li> Lo include nello stesso "snapshot" dei file.</li> </ul> In caso di disastro, avrai la certezza matematica che i file e il database siano sincronizzati allo stesso identico istante, evitando inconsistenze che sono l'incubo di ogni sysadmin. </a> Notifiche e Monitoraggio</h3> Una delle feature migliori di Borgmatic è la capacità di avvisarti istantaneamente se un backup fallisce o se è andato a buon fine. Invece di controllare i log ogni mattina, io uso ntfy, un servizio di messaggistica pub-sub semplicissimo (e ovviamente self-hostabile). Puoi configurare le notifiche direttamente nel tuo config.yaml. Ecco come inviare un messaggio al tuo telefono ogni volta che Borgmatic finisce il suo lavoro: ntfy: # L'URL del tuo server ntfy (o quello ufficiale) topic: il_tuo_topic_segreto server: https://ntfy.sh # Invia notifiche solo in caso di errore o sempre? states: [failed, finished] # Puoi anche aggiungere una priorità diversa in base allo stato priority: 5 </code></pre> Se invece preferisci usare i classici hooks per personalizzare il messaggio (magari includendo il nome dell'host), puoi fare così: hooks: on_error: - curl -d "❌ Backup fallito su $(hostname)" https://ntfy.sh/il_tuo_topic_segreto after_backup: - curl -d "✅ Backup completato con successo su $(hostname)" https://ntfy.sh/il_tuo_topic_segreto </code></pre> Con l'app di ntfy installata sullo smartphone, riceverai una notifica push in tempo reale. Se non vedi arrivare nulla, allora sai che c'è qualcosa da controllare. </a> Recuperare i Dati: Quando il Backup Diventa Importante</h2> Tutto questo lavoro di backup è inutile se non puoi effettivamente recuperare i tuoi dati. Con Borg è sorprendentemente semplice. Per elencare tutti i backup disponibili: borg list /mnt/discoesterno/backup </code></pre> Per elencare i file all'interno di un backup specifico: borg list /mnt/discoesterno/backup::backup_2025_01_15 </code></pre> Per estrarre un singolo file: borg extract /mnt/discoesterno/backup::backup_2025_01_15 /home/utente/documenti/importante.txt </code></pre> Per ripristinare l'intero backup in una directory temporanea: mkdir /tmp/ripristino cd /tmp/ripristino borg extract /mnt/discoesterno/backup::backup_2025_01_15 </code></pre> La bellezza di Borg è che il ripristino è altrettanto semplice della creazione del backup. Non c'è magia incomprensibile, solo comandi diretti e intuitivi. </a> Le Limitazioni (Che Non Sono Molte)</h2> Borg è meraviglioso, ma non è perfetto. Vale la pena menzionare un paio di limitazioni: Innanzitutto, per i database, Borg avrebbe bisogno di un dump preventivo su disco. Fortunatamente, come abbiamo visto, Borgmatic risolve il problema gestendo i dump al volo, ma è sempre bene verificare di avere abbastanza spazio temporaneo per queste operazioni se i database sono mastodontici. In secondo luogo, la prima esecuzione di un backup remoto è lenta. Se hai 500 GB da inviare al tuo server di backup via SSH, i tempi saranno significativi. Ma i backup successivi saranno enormemente più veloci grazie alla deduplica. La deduplica cross-archive (tra diversi backup) significa che i cambiamenti incrementali sono davvero incrementali. Infine, il ripristino di backup molto grandi con molti file può essere un po' lento, soprattutto se il repository è su un disco lento. Ma una volta che hai i dati localmente, sei a posto. </a> Conclusione: Perché Ho Scelto Borg</h2> Negli ultimi anni ho usato Borg su ogni server che amministro. A volte ho dovuto recuperare i dati, e ogni singola volta Borg c'è stato, puntuale e affidabile. Ha sempre ripristinato esattamente quello che mi serviva, senza cerimoniali inutili. Borg è ciò che mi piace in un software: semplice nei concetti, potente nell'esecuzione, straordinariamente efficiente, e completamente open source. Borgmatic lo rende ancora più accessibile, anche per chi non vuole passare ore a studiare manuali complessi. Se gestisci un server self-hosted, uno o più personal computer, o semplicemente dati che non puoi permetterti di perdere, Borg e Borgmatic meritano seriamente di essere nella tua cassetta degli attrezzi. Il tempo che dedicherai alla loro configurazione sarà tempo ben speso, e il giorno in cui avrai bisogno di recuperare un file eliminato accidentalmente, ringrazierai te stesso di averlo fatto. Buon backup!



Forgejo con Docker: Git self-hosted senza fronzoli
Unknown — Fri, 11 Jul 2025 00:00:00 +0000
Da tempo utilizzo Git per gestire i miei progetti personali, sia software che di configurazione. Per anni mi sono affidato al pc di qualcunaltro (es: Gitlab o GitHub), ma la dipendenza da un servizio centralizzato, per quanto comodo, inizia a starmi stretta. Così ho cercato una soluzione più allineata alla mia filosofia: Forgejo</strong>, un fork comunitario di Gitea, leggero e facilmente self-hostabile.</p>
</p>
</span></a>
Perché Forgejo</h2>
Forgejo nasce da una comunità che punta alla trasparenza e all’autonomia, senza il rischio che un progetto venga assorbito o piegato a logiche commerciali. La compatibilità con Gitea è totale, e i requisiti minimi lo rendono perfetto per VPS o server casalinghi.</p>
</span></a>
Veniamo subito al dunque e facciamolo partire, cosi potremo provarlo con mano!</h2>
</span></a>
Setup con Docker</h2>
Ci affidiamo a Docker Compose, cosi con un solo file di configurazione abbiamo tutto il necessario.</p>
</span></a>
docker-compose.yaml</h3>
services:</span></span>
</span>  forgejo:</span></span>
</span>    image:</span></span> codeberg.org/forgejo/forgejo:latest</span>
</span>    container_name:</span></span> forgejo</span>
</span>    restart:</span></span> always</span>
</span>    environment:</span></span>
</span>      -</span></span> USER_UID=1000</span>
</span>      -</span></span> USER_GID=1000</span>
</span>    volumes:</span></span>
</span>      -</span></span> ./data:/data</span>
</span>      -</span></span> /etc/timezone:/etc/timezone:ro</span>
</span>      -</span></span> /etc/localtime:/etc/localtime:ro</span>
</span>      -</span></span> ./robots.txt:/data/gitea/public/robots.txt:ro</span>
</span>    expose:</span></span>
</span>      -</span></span> "</span>3000"</span></span></span>
</span>    networks:</span></span>
</span>      -</span></span> forgejo_net</span>
</span>
</span>networks:</span></span>
</span>  forgejo_net:</span></span>
</span>    driver:</span></span> bridge</span>
</span></code></pre>

</span></a>
Reverse Proxy</h3>
E' possibile usare il web server che preferiamo, come ad esempio traefik, caddy, apache o nginx, in questo articolo vedremo un esempio con quest'ultimo.</p>
Qui una configurazione base con https (via Let's Encrypt, gestito esternamente):</p>
/etc/nginx/sites-available/forgejo.conf
</span>
</span>server {
</span>    listen 80;
</span>    server_name git.miodominio.it;
</span>
</span>    return 301 https://$host$request_uri;
</span>}
</span>
</span>server {
</span>    listen 443 ssl;
</span>    server_name git.miodominio.it;
</span>
</span>    ssl_certificate /etc/letsencrypt/live/git.miodominio.it/fullchain.pem;
</span>    ssl_certificate_key /etc/letsencrypt/live/git.miodominio.it/privkey.pem;
</span>
</span>    location / {
</span>        proxy_pass http://localhost:3000;
</span>        proxy_set_header Host $host;
</span>        proxy_set_header X-Real-IP $remote_addr;
</span>        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
</span>        proxy_set_header X-Forwarded-Proto $scheme;
</span>    }
</span>}
</span></code></pre>
Dopo aver creato il file, attivare con:</p>
ln</span></span> -</span>s</span> /etc/nginx/sites-available/forgejo.conf /etc/nginx/sites-enabled/</span>
</span>nginx</span></span> -</span>t</span></span> &&</span> systemctl</span></span> reload nginx</span>
</span></code></pre>

</span></a>
Backup automatico</h2>
Il backup rappresenta un step fondamentale del nostro setup, conviene implementarne subito uno all'avvio del servizio, cosi non ce ne dimenticvheremo e terremo i nostri dati al sicuro. Ricordiamoci che qui salveremo il risultato di diverse ore di programmazione, studio e prove!</p>
I nostri dati si trovano nel volume data di cui sopra, quindi sarà sufficiente salvare il docker file e la directory data.
Io consiglio di usare #borg ma potete usare il softwsre che preferite, trovo particolarmente utile aggiungere questa nuova directory alle procedure di salvataggio che sicuremante avrete già per tutto il resto.
(se non le avete potete anche smettere di leggere questo blog, tornate quando ne avrete implementata una).</p>

</span></a>
Configurazioni iniziali</h2>
A questo punto, dopo l'installazione, non ci resta che accedere via web al nostro software e fare le prime configurazioni.
È possibile creare utenti, organizzazioni, concedere permessi e creare tutti i repository che si desiderano.</p>
Ciascun progetto può essere impostato ad accesso privatp</em> o pubblico</em>.</p>
In questo modo sarà semplicissimo collaborare in più persone allo stesso progetto, tenendo traccia delle varie modifiche.</p>
Infine è anche possibile importare direttamente altri repository git.</p>
</span></a>
Runner e Action</h2>
Forgejo, essendo un fork di Gitea, supporta un sistema di CI/CD</em> integrato chiamato Actions, simile a GitHub Actions, e permette di eseguire job di build o deploy tramite runner personalizzati.</p>
Io stesso ne faccio uso, è uno dei motivi per cui mi sto trovando benissimo con forgejo! Ho varie configurazione a seconda del progetto ospitato, ma essenzialmente queste si occupano di effettuare il "deploy" del codice, cioé copiano a destinazione (server di sviluppo o di produzione a seconda dei casi), il codice modificato, cosi che sia pronto all'uso.
In questo modo, grazie alla history di git, sarà sempre possibile tornare indietro, nonché tenere traccia delle modifiche nel tempo.</p>
</span></a>
Come funziona</h3>
Le Actions sono definite da file YAML nei repository (.forgejo/workflows/), e possono contenere job con step eseguiti su runner registrati.</p>
I runner sono agent installati su macchine (stessa VPS o remote), che si collegano al server Forgejo e attendono job da eseguire.</p>
Una volta definita la condizione scatenante (es: commit su ramo main, rilascio di una nuova versione, ecc) partirà il worksflow che abbiamo definito, con la possibilità di verificarne lo stato di esecuzione in tempo reale. Infine è anche possibile andare a vedere i log delle esecuzione precedenti.</p>
All'interno di una action si possono usare #secret e #variabili, in modo da poter riusare il codice della action e allo stesso tempo mantenere al sicuro le credenziali.</p>
</span></a>
Setup runner base</h3>
Vediamo come creare un nuovo runner, passo passo:</p>
export</span> RUNNER_VERSION</span>=</span>$</span>(</span>curl</span></span> -</span>X</span> '</span>GET'</span></span> https://data.forgejo.org/api/v1/repos/forgejo/runner/releases/latest</span> |</span> jq</span></span> .name -</span>r</span></span> |</span> cut</span></span> -</span>c</span> 2-</span>)</span></span></span></span>
</span>wget</span></span> -</span>O</span> forgejo-runner https://code.forgejo.org/forgejo/runner/releases/download/v$</span>{</span></span>RUNNER_VERSION</span></span>}</span></span>/forgejo-runner-$</span>{</span></span>RUNNER_VERSION</span></span>}</span></span>-linux-amd64</span>
</span>chmod</span></span> +x forgejo-runner</span>
</span>sudo</span></span> mv forgejo-runner /usr/local/bin/forgejo-runner</span>
</span>sudo</span></span> useradd -</span>m</span> -</span>s</span> /bin/bash forgejo-runner</span>
</span>sudo</span></span> usermod -</span>aG</span> docker forgejo-runner</span>
</span></code></pre>
Rechiamoci sull'interfaccia web di Forgejo:
Forgejo > Repository > Settings > Actions > Runners > "Generate new token"</em></p>
sudo</span></span> -</span>i</span> -</span>u</span> forgejo-runner</span>
</span>forgejo-runner</span></span> register</span>
</span></code></pre>
</span></a>
Avvio automatico del runner</h4>
Io ho usato uno script systemd per l'avvio automatico, ve lo riporto di seguito</p>
sudo</span></span> echo "</span>
</span></span></span>[Unit]
</span></span></span>Description=Forgejo Act Runner
</span></span></span>After=network.target docker.service
</span></span></span>Requires=docker.service
</span></span></span>
</span></span></span>[Service]
</span></span></span>User=forgejo-runner
</span></span></span>Group=forgejo-runner
</span></span></span>ExecStart=/usr/local/bin/forgejo-runner daemon
</span></span></span>Restart=always
</span></span></span>WorkingDirectory=/home/forgejo-runner
</span></span></span>
</span></span></span>[Install]
</span></span></span>WantedBy=multi-user.target"</span></span> ></span> /etc/systemd/system/forgejo-runner.service</span>
</span>
</span>sudo</span></span> systemctl daemon-reload</span>
</span>sudo</span></span> systemctl enable forgejo-runner</span>
</span>sudo</span></span> systemctl start forgejo-runner</span>
</span>systemctl</span></span> status forgejo-runner</span>
</span></code></pre>

</span></a>
Vantaggi in breve</h2>

Repository del proprio codice, diviso come si preferisce: singoli progetti, organizzazioni, ecc.</li>
Possibilità di creare utenti per collaboratori/amici con controllo sugli accessi/permessi.</li>
Automatizzo test, build, deploy senza dipendere da servizi esterni.</li>
Nessuna dipendenza da fornitori terzi e nessun limite di spazio, esecuzioni, personalizzazioni.</li>
Versionamento del codice, e nel caso di ci/cd garanzia di riproducibilità</li>
Pocchissime risorse necessarie lato server</li>
Vuoi mettere quanto è figo avere il proprio servizio di versionamento?</li>
</ul>
</span></a>
Uso quotidiano</h2>
Forgejo supporta #git via #ssh, Web UI e #webhooks. Ho configurato alcuni repository con CI locale usando le Actions e i runner integrati. L’interfaccia è leggera e pulita, senza funzionalità inutili.</p>
</span></a>
Conclusioni</h2>
Forgejo è una soluzione Git solida, coerente con un approccio decentralizzato. Semplice da gestire, veloce da installare, e adatta anche per chi – come me – preferisce sapere dove stanno i propri dati. Per ora lo utilizzo solo per progetti personali, ma potrei iniziare a usarlo anche per collaborazioni future.</p>
Non vi resta che provarlo, fatemi sapere le vostre impressioni con un commento nel #fediverso su questo articolo.</p>


Nextcloud
Unknown — Fri, 23 Feb 2024 00:00:00 +0000
Nota Introduttiva: questo articolo sarà solo un'introduzione, seguiranno approfondimenti sui singoli componenti.</em></p>
</span></a>
Cos'è nextcloud</h2>
Software open source che permette di realizzare  un servizio Cloud personale per i propri dati.  Ambiente collaborativo e può anche essere federato con altre installazioni.
È possibile installarlo su un proprio dispositivo o usare quello messo a disposizione da alcune aziende o associazioni.
L'architettura è modulare, questo ci permette di attivare solo le funzionalità che ci servono e se ne possono aggiungere di nuove (via via che gli sviluppatori le rilasciano). C'è un plugin per ogni esigenza!</p>
</p>
</span></a>
Caratteristiche</h2>
Il suo punto di forza è la condivisione</strong> e la sincronizzazione</strong> dei file, che può avvenire tramite semplice browser web o utilizzando l'applicazione disponibile per tutti i sistemi operativi. Possiamo considerarlo un'alternativa a Dropbox, Google drive o onedrive.
Ci sono anche numerosi servizi aggiuntivi</strong>, che coprono diverse esigenze, come ad esenpio:</p>

calendario</li>
contatti</li>
webmail</li>
attività (task)</li>
note (markup language)</li>
chat interna</li>
suite per l'ufficio (via web, basata su libreoffice)</li>
galleria immagini</li>
ebook reader</li>
password manager</li>
gestione bookmark (con possibilità di sync con plugin per il browser)</li>
podcast</li>
libro di ricette</li>
ricerca</li>
forms</li>
</ul>
Questi servizi possono essere usati via web, o con i vari client, con il vantaggio di avere tutto sincronizzato tra più dispositivi</strong>.
Nextcloud diventa così il proprio hub personale dove ci sono tutti i propri dati e le proprie attività.</p>
</p>
</span></a>
Vantaggi</h2>

self hosting: possiamo installarlo su un nostro pc o su una #vps in modo che i nostri dati</strong> siano sempre sotto il nostro controllo.</li>
nel caso si voglia affidarsi al lavoro di altri, possiamo scegliere il provider che vogliamo e cambiarlo in qualsiasi momento (esportando i dati)</li>
tra utenti dello stesso server (o federati) è possibile collaborare</li>
condivisione di file (e immagini) avendo sempre tutto sotto controllo, vedi paragrafo dedicato sotto.</li>
ricerca globale</strong>: usando la casella di ricerca, questa verrà effettuata ovunque: file, note, contatti, calendario, ecc. ecc.</li>
</ul>
</p>
</span></a>
Backup</h2>
Come abbiamo visto nextcloud è la nostra casa personale di tutti i dati e attività, diventa quindi fondentale prevedere un sistema di backup affidabile, a cui far ricorso in caso di problemi.</p>
</span></a>
Cosa salvare</h3>

Database: dipende da quello che avete scelto, ma solitamente si tratta di Mysql</em> (o MariaDB</em>). Le procedure di salvataggio sono quelle consuete (mysqldump</em>), che potete trovare in rete o in questo blog (in futuro).</li>
File: salvataggio della directory nextcloud ospitata dal webserver, che contiene sia il software che i nostri dati</li>
Se non siamo gli unici utilizzatori dell'istanza, è consigliabile impostare l'istanza in modalità manutenzione</strong> durante le operazioni di salvataggio, in modo da avere la consistenza dei dati.</li>
</ol>
Vi consiglio di usare un sistema come #borg, il quale può essere usato in modalità incrementale</strong> così vi garantisce di poter recuperare sempre una certa versione dei vostri documenti e ha il vantaggio che, dopo la prima esecuzione, i backup successivi trasferiranno solo le nuove modifiche sul backup, saranno così molto veloci e occuperanno solo lo spazio strettamente necessario!</p>
</span></a>
Condivisione di file</h2>

cartelle (e file) in sola lettura per utenti anonimi anche protetti da password</li>
possibilità di poter ricevere file da altri (upload)</li>
galleria foto</li>
cartelle collaborative con altri utenti del server (o istanze federate)</li>
supporto nativo a #webdav</li>
applicazione desktop</strong> per sincronizzazione automatica dei file.</li>
supporto al versionamento</li>
</ul>
</span></a>
Calendario e contatti</h2>

configurando un app come #davx5 vi permette di sincronizzare contatti e calendario del vostro smartphone</li>
È possibile sincronizzare anche i client desktop, sfruttando i protocolli standard #caldav e #carddav</li>
import e export da e verso altri sistemi</li>
</ul>
</span></a>
App mobile</h2>

accesso a tutti i propri file in mobilità</li>
auto upload delle foto scattate</li>
</ul>
</span></a>
Task</h2>

gestione categorie</li>
sotto task</li>
date di inizio e scadenza</li>
percentuale avanzamento</li>
</ul>
</span></a>
Note</h2>

accesso web</li>
markup language</li>
categorie</li>
app mobile</li>
</ul>
</span></a>
Nota personale</h3>
Io sto usando tantissimo le note, per segnarmi di tutto: appunti, comandi, persino le bozze che scrivo per il blog. Trovo che sia la vera killer application, ritrovo sempre tutto e l'impaginazione è semplice e funzionale.</p>

</p>
</span></a>
Suite ufficio</h2>
E' possibile editare i documenti</strong> office anche via interfaccia web:</p>

Software basato sul diffuso libreoffice</li>
Editing collaborativo real time (è necessario installare Collabora office</strong>)</li>
</ul>
</span></a>
Utenti di mastodon.uno</h2>
Se vi ho incuriosito e volete provare ad usarlo, vi segnalo che gli utenti di mastodon.uno posso richiedere un account da qui:
https://cloud.mastodon.uno/apps/forms/s/YSCoCC37D9omTN8iXSKkQqz9
(sul server sono già preinstallati diversi software aggiuntivi)</p>

</p>