---
title: "Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi"
description: "Server VPS unmanaged bloccato e sviluppatore irreperibile: il caso reale di un Hetzner AX41 recuperato in 3 ore via rescue mode e il decalogo operativo per le PMI italiane."
canonical: "https://www.mauriziofonte.it/blog/post/ripristino-operativita-web-provider-vps-unmanaged.html"
author: "Maurizio Fonte"
date: "2025-06-16T08:12:15+02:00"
modified: "2026-04-14T17:48:55+02:00"
section: "Refactoring"
tags: ["Refactoring", "VPS & Hosting"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html)

# [Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi](https://www.mauriziofonte.it/blog/post/ripristino-operativita-web-provider-vps-unmanaged.html)

Lunedì 16 Giugno 2025, alle 08:12 ![Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi](https://www.mauriziofonte.it/image/001790200-ripristino-operativita-web-provider-vps-unmanaged.jpg)

Il 14 aprile 2025 ho ricevuto un'email allarmata da una società di consulenza B2B romana del settore servizi tecnici per la pubblica amministrazione. Il loro sito istituzionale e il portale clienti erano entrambi giù da poco più di sei ore, e l'unica risorsa tecnica interna che avevano (un dipendente IT generalista, non sistemista) aveva esaurito le proprie opzioni dopo aver provato a riavviare il server dal pannello Hetzner Robot senza risultato. Il loro sviluppatore originale, un freelance di Bari che aveva costruito tutto lo stack quattro anni prima, non rispondeva al telefono né alle email da otto giorni. La situazione tecnica era questa: un Hetzner AX41 con Debian 11, Apache, MySQL 8 e PHP 7.4, su cui non avevano *nessuna* credenziale SSH valida (le chiavi del freelance non erano state mai duplicate o documentate), nessun accesso a phpMyAdmin (la URL era di root e protetta da basic auth con credenziali ignote), nessun backup recente verificato, e nessuna idea di cosa fosse andato storto. L'unico accesso che possedevano era il login al pannello Hetzner Robot, che il titolare aveva creato intestato a sé al momento dell'acquisto del server.

In tre ore di lavoro ho ricondotto il server a piena operatività, recuperando l'accesso SSH tramite la rescue mode di Hetzner, diagnosticando la causa root del crash (un disco riempito al 100% da log Apache mai ruotati), liberando spazio in modo conservativo, riavviando i servizi nell'ordine corretto, configurando logrotate, e producendo un runbook scritto per il cliente con tutte le credenziali e le procedure operative che il freelance non aveva mai documentato. Questo articolo descrive la sequenza esatta di interventi che applico in questi scenari, distillata da una decina di emergenze simili negli ultimi quattro anni, con i comandi precisi e gli strumenti del provider che fanno la differenza fra un recovery di tre ore e un'agonia di tre giorni. È un terreno operativo che si interseca strettamente con il [protocollo di subentro su un progetto PHP quando lo sviluppatore originale è scomparso, su Hetzner, OVH o Aruba](https://www.mauriziofonte.it/blog/post/guida-subentro-progetto-php-server-hetzner-ovh-aruba-developer-scomparso.html), ma con un focus specifico sull'uso degli strumenti del provider come ultima risorsa quando ogni altra strada è chiusa.

## Perché il provider unmanaged non risolve il problema al posto tuo (e cosa invece ti dà davvero)?

Il primo malinteso che devo dissipare quasi sempre con i clienti in emergenza è la confusione fra "server unmanaged" e "server senza supporto". Sono due cose completamente diverse, e capirle è la chiave per usare correttamente le risorse che il provider mette a disposizione. Un server unmanaged significa che il provider è responsabile esclusivamente del livello hardware e di rete: ti consegna una macchina fisica funzionante, con accesso a internet, con un'installazione iniziale del sistema operativo che hai scelto, e con strumenti per intervenire quando il sistema non risponde più via SSH. Da quel momento in poi, qualunque cosa avvenga *dentro* l'OS - pacchetti aggiornati, configurazioni applicative, certificati SSL, log che riempiono il disco, processi che vanno in deadlock - è responsabilità del cliente o del consulente che il cliente ha incaricato. Hetzner non manda un sistemista di notte a riavviarti MySQL, e OVH non patcha il tuo Apache se hai una CVE critica.

Quello che invece il provider unmanaged ti *dà*, e che è oro durante un'emergenza, è una serie di strumenti di disaster recovery che permettono di reintervenire sulla macchina anche quando l'accesso normale non funziona più. La [documentazione ufficiale del Rescue System di Hetzner sul portale Robot](https://docs.hetzner.com/robot/dedicated-server/troubleshooting/hetzner-rescue-system/) descrive il flusso completo per bootare la macchina su un'immagine Linux minimal, montare il filesystem originale, e intervenire dall'esterno sul sistema lockato. La [documentazione equivalente di OVH per IPMI e KVM over IP sui server dedicati](https://help.ovhcloud.com/csm/en-dedicated-servers-kvm?id=kb_article_view&sysparm_article=KB0043571) fornisce gli stessi strumenti via interfaccia diversa. Aruba Cloud, su cui ho clienti italiani con vincoli di sovranità dei dati, fornisce la console del server direttamente nell'interfaccia di gestione, come spiegato nella [knowledge base ufficiale di Aruba Cloud sulla connessione console ai server cloud](https://kb.arubacloud.com/en/computing/cloud-servers/connection-to-cloud-servers-with-console.aspx). Tutti e tre i provider, quindi, ti mettono in mano il martello - sei tu (o chi ti assiste) a dover sapere su quale chiodo battere. Sapere usare questi strumenti è la differenza fra "lo sviluppatore mi ha lasciato a piedi e sono finito" e "lo sviluppatore è sparito ma in tre ore sono di nuovo online". È la stessa differenza fra la dipendenza e la sovranità tecnologica che ho descritto nell'articolo sul tema del [vendor lock-in nei progetti PHP delle PMI italiane](https://www.mauriziofonte.it/blog/post/evitare-vendor-lock-in-software-php-server-linux.html).

## I primi trenta minuti: la check-list di triage che applico in ogni emergenza

I primi trenta minuti di un'emergenza server determinano quasi sempre l'esito complessivo del recovery. Sul cliente romano del 14 aprile 2025, ho applicato la mia check-list di triage in undici punti, completata in 27 minuti, e già al termine di questa fase sapevo esattamente cosa era successo, cosa avrei dovuto fare per risolverlo, e quanto tempo mi avrebbe richiesto. Senza questa fase di diagnosi disciplinata, il rischio è di iniziare a "provare cose" e peggiorare la situazione esistente, distruggendo prove che servirebbero per il post-mortem.

I primi tre punti della check-list sono di natura organizzativa, prima ancora che tecnica. Punto 1: identificare la persona che ha autorità di decisione presso il cliente, perché ogni intervento successivo va concordato con qualcuno che possa autorizzare azioni potenzialmente irreversibili. Punto 2: ottenere l'accesso al pannello del provider (Hetzner Robot, OVH Manager, Aruba Cloud Console), perché senza questo nessuno strumento di rescue è disponibile. Punto 3: bloccare qualunque tentativo di "fare qualcosa di nuovo" finché la diagnosi non è completata, perché ogni riavvio non motivato distrugge la cache dei processi in memoria e i log volatili. Sul cliente romano, il dipendente IT aveva già riavviato il server tre volte prima di chiamarmi, perdendo informazioni preziose sui processi che stavano consumando memoria nel momento del crash.

I punti 4-7 sono tecnici di osservazione: tentare un ping ICMP all'IP del server (per capire se è almeno raggiungibile a livello rete), tentare una connessione SSH sulla porta standard (22) e su eventuali porte custom, controllare se il pannello del provider mostra il server come "online" o "offline" lato hypervisor, e verificare lo stato del traffico di rete sull'interfaccia del server tramite le metriche del provider (Hetzner mostra graphs di traffico in/out con risoluzione 5 minuti direttamente nel Robot, OVH idem nel Manager). Sul cliente romano, queste quattro verifiche hanno mostrato che il server era online lato hypervisor, ma non rispondeva né a ping né a SSH, e che il traffico di rete in uscita era a zero. La combinazione "server up + nessun traffico" puntava chiaramente verso un kernel deadlock o un sistema che aveva perso la connettività di rete a livello applicativo.

I punti 8-11 sono di azione iniziale: bootare il server in rescue mode dal pannello del provider, montare il filesystem principale in sola lettura, ispezionare i log di sistema (`/var/log/syslog`, `/var/log/messages`, `/var/log/kern.log`) per trovare l'ultimo evento utile prima del crash, e controllare lo spazio disco disponibile sui filesystem critici. Sul cliente romano, il punto 11 ha rivelato immediatamente la causa: la partizione `/` era al 100% di occupazione, con `/var/log/apache2/access.log` e `/var/log/apache2/error.log` cresciuti a 47GB e 23GB rispettivamente, perché logrotate non era mai stato configurato dal freelance originale. Apache aveva smesso di rispondere quando non aveva più potuto scrivere log, MySQL era andato in panic per impossibilità di scrivere il binlog, e il disco saturo aveva impedito al sistema di gestire qualunque scrittura, inclusi i tentativi di SSH session establishment.

## Rescue mode di Hetzner: la sequenza esatta dei comandi per recuperare l'accesso

La rescue mode è uno strumento che ti permette di bootare la macchina in un ambiente Linux minimal fornito dal provider, completamente separato dal sistema operativo installato sul disco. Da quell'ambiente puoi montare il filesystem originale come device esterno e operare su di esso come se fosse un disco USB. Su Hetzner, l'attivazione avviene dal pannello Robot, sezione "Rescue", scegliendo l'architettura (linux64), inserendo opzionalmente la propria chiave SSH pubblica, e cliccando "Activate rescue system". Subito dopo si forza un riavvio dal pannello (oppure tramite IPMI se non si fida del riavvio software), e il server bootta in pochi secondi nell'ambiente di rescue. A quel punto puoi connetterti via SSH come `root` con la password fornita dal pannello (o con la tua chiave) e operare. La sequenza esatta che ho eseguito sul cliente romano del 14 aprile 2025, una volta dentro l'ambiente di rescue, è stata questa:

```bash
fdisk -l
mkdir /mnt/rescue
mount /dev/nvme0n1p3 /mnt/rescue
df -h /mnt/rescue

du -sh /mnt/rescue/var/log/apache2/* | sort -h | tail -10

cd /mnt/rescue/var/log/apache2
tail -1000 access.log > /root/last-access.log
tail -1000 error.log  > /root/last-error.log

truncate -s 0 access.log
truncate -s 0 error.log
truncate -s 0 access.log.1
truncate -s 0 error.log.1

df -h /mnt/rescue

sync
umount /mnt/rescue
reboot
```

Le quattro operazioni critiche sono: montare il filesystem originale (la partizione `/` di Debian su un AX41 è tipicamente `/dev/nvme0n1p3` con uno schema GPT classico, ma `fdisk -l` te lo conferma), salvare gli ultimi 1000 record di ciascun log in una directory esterna a `/mnt/rescue` per averli a disposizione anche dopo il reboot, troncare i file di log a dimensione zero senza cancellarli (importante: Apache mantiene aperto il file descriptor anche dopo un truncate, quindi `truncate -s 0` libera lo spazio senza richiedere un restart immediato del demone), e infine smontare pulitamente prima del reboot. Sul cliente romano, dopo il truncate dei file di log, lo spazio occupato è passato da 100% a 31%, e dopo il reboot in modalità normale il sistema è tornato online in 47 secondi con SSH funzionante, Apache che rispondeva sul vhost del cliente, e MySQL operativo. Questo è il momento esatto in cui un'emergenza smette di essere un'emergenza e diventa un'attività di consolidamento, identica nel principio operativo a quella descritta nel mio articolo sulla [difesa proattiva da bot e DDoS su PHP/Laravel Hetzner e OVH](https://www.mauriziofonte.it/blog/post/difesa-proattiva-proteggere-php-server-dedicato-ddos-bot.html): risolvere la causa immediata, e poi mettere in piedi le contromisure perché non si ripeta.

## Configurare logrotate per evitare la prossima esplosione del disco

Aver liberato spazio non serve a nulla se la causa root resta in piedi. Sul cliente romano, dopo il riavvio, ho immediatamente configurato logrotate in modo che Apache, MySQL, Nginx e tutti i log applicativi venissero ruotati con cadenza giornaliera, compressi, e cancellati dopo 14 giorni. La [pagina man di logrotate(8) sul progetto Linux Die](https://linux.die.net/man/8/logrotate) documenta tutte le direttive disponibili, ma per la maggior parte dei casi PMI bastano cinque righe di configurazione per file di log. La configurazione minima che ho lasciato sul cliente romano per Apache è stata questa:

```text
/var/log/apache2/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        if /etc/init.d/apache2 status > /dev/null ; then \
            /etc/init.d/apache2 reload > /dev/null; \
        fi;
    endscript
}
```

Questa configurazione fa girare il logrotate ogni giorno, mantiene 14 file di log compressi (rappresentando 14 giorni di storia accessibile), compatta i log con gzip salvo l'ultimo per evitare problemi di lettura concorrente, ricrea il file di log con permessi corretti dopo la rotazione, e fa il reload di Apache solo se il demone è attivo (importante per evitare che logrotate stesso fallisca su sistemi in stato anomalo). In aggiunta alla configurazione, ho aggiunto un alert su disco al sistema di monitoring del cliente con soglia all'80% di occupazione, in modo che la prossima volta che un filesystem si avvicinasse al limite ricevessero una notifica con 48 ore di anticipo invece di scoprirlo a sito offline. La gestione dei log è una di quelle attività che vanno strutturate fin dal primo giorno di vita di un server, ed è esattamente uno dei capitoli del [piano di consolidamento del debito tecnico nei 90 giorni post-subentro su server Linux Hetzner e OVH](https://www.mauriziofonte.it/blog/post/gestire-debito-tecnico-server-linux-hetzner-ovh-post-subentro.html): senza log ruotati, ogni server è una bomba a orologeria.

Il complemento operativo della rotazione è la disciplina di consultare i log durante il funzionamento normale, non solo in emergenza. Una pratica che applico con tutti i clienti dopo un incidente come questo è programmare un controllo settimanale automatizzato degli ultimi 1000 errori Apache e degli ultimi 1000 errori PHP, con un report inviato via email al titolare e a me. È una contromisura economica ma efficace, perché trasforma il monitoraggio dei log da attività reattiva (qualcosa è andato storto, vado a vedere i log) ad attività proattiva (vado a vedere i log perché è giovedì mattina e potrebbero esserci segnali di qualcosa che andrà storto la settimana prossima). Il principio è lo stesso descritto nell'articolo sulla [gestione strategica dei log Laravel su server dedicati Hetzner e OVH](https://www.mauriziofonte.it/blog/post/gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.html), applicato qui in scala da PMI senza budget di osservabilità.

## Knowledge transfer inverso: ricostruire la documentazione che lo sviluppatore non ha mai prodotto

Una volta superata la crisi tecnica, il problema più importante da risolvere è quello informativo. Sul cliente romano del 14 aprile 2025, una volta riavviato il server, non avevamo nessuna delle informazioni che servono per gestire correttamente quella macchina nei prossimi mesi: non c'era un inventario dei vhost configurati, non c'era una lista degli utenti MySQL, non c'erano le credenziali di accesso al backoffice del CMS, non c'era uno schema della base dati, non c'era una mappa dei cron job in esecuzione. La fase di knowledge transfer inverso consiste esattamente nel ricostruire tutte queste informazioni dal sistema in produzione, perché sono necessarie per qualunque intervento futuro. Il processo che applico richiede tipicamente uno o due giorni di lavoro, e produce una serie di documenti che diventano la base operativa del cliente.

Lo eseguo in cinque fasi: estrazione dell'inventario applicativo (vhost Apache configurati, applicazioni PHP/Laravel/Symfony installate, framework e versioni), estrazione della mappa dei servizi (`systemctl list-units --type=service --state=running`), estrazione dell'inventario degli utenti SSH e MySQL (con le rispettive autorizzazioni), estrazione della lista dei cron job di sistema e per-utente (`cat /etc/crontab`, `crontab -l` per ogni utente), e mappatura delle integrazioni esterne (ricerca di API key, webhook, credenziali SMTP, chiavi SSH per repository Git in `~/.ssh/config`). Ogni elemento estratto viene documentato in italiano in un runbook condiviso col cliente in formato Markdown su un repository Git di sua proprietà, perché è esattamente il tipo di documentazione che gli serve per non trovarsi mai più nella situazione di partenza. Il principio sotto sta nello stesso ragionamento che ho descritto nell'articolo sull'[importanza del versionamento del codice come prerequisito non negoziabile per la sopravvivenza tecnica di una PMI](https://www.mauriziofonte.it/blog/post/importanza-versionamento-codice-git-azienda.html): senza repository Git e senza documentazione versionata, qualunque ottimizzazione futura è costruita sulla sabbia.

Se la tua azienda gestisce un server VPS unmanaged su Hetzner, OVH, Aruba o Contabo per applicazioni critiche al business, e non hai mai messo alla prova la tua capacità di intervento in scenario di emergenza con il sistemista originale irreperibile, [scopri come lavoro con i clienti sui temi di subentro tecnico e gestione dell'emergenza infrastrutturale](https://www.mauriziofonte.it/pages/about): in dieci anni di consulenza ho visto che il fattore decisivo nel recovery non è la potenza del server, ma la qualità della documentazione e degli accessi disponibili nel momento esatto del bisogno. Se invece sei già nella situazione descritta - sito offline, sviluppatore irreperibile, nessun accesso SSH valido, server che non risponde - e ti serve un intervento immediato per ricondurre il sistema in operatività con un piano di consolidamento successivo, [contattami per una consulenza](https://www.mauriziofonte.it/pages/contattami): in poche ore tipicamente ottengo l'accesso alla rescue mode del provider, diagnostico la causa root del crash, ripristino i servizi nell'ordine corretto, configuro le contromisure perché il problema non si ripeta, e ti consegno un runbook operativo che il tuo team può usare in autonomia da subito.

Dall'articolo al lavoro vero

Se questo server lo devi tenere in piedi tu

Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino.

[Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteDifesa proattiva da bot e DDoS su PHP/Laravel Hetzner e OVH: come ho contenuto un attacco di credential stuffing da 14.000 richieste al minuto in 47 minuti con Nginx, Fail2ban e Cloudflare13 Giugno 2025](https://www.mauriziofonte.it/blog/post/difesa-proattiva-proteggere-php-server-dedicato-ddos-bot.html)[Articolo successivo »Sviluppatore sparito con le credenziali del server: come ho restituito a un cliente genovese il controllo di un Hetzner AX51-NVMe in sei giorni tra trasferimento di proprietà, rescue boot e audit completo17 Giugno 2025](https://www.mauriziofonte.it/blog/post/interventi-emergenza-server-dedicato-unmanaged.html)

### Articoli correlati a Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi

- [Ripristino di file system corrotti su VPS senza supporto tecnico: guida immediata Debian e Ubuntu](https://www.mauriziofonte.it/blog/post/ripristino-filesystem-corrotto-vps-debian-ubuntu.html)

  Un VPS Hetzner che non bootava più dopo un kernel panic: filesystem ext4 con journal corrotto, errori I/O nei log, e un gestionale Laravel con · 16 Luglio 2025

  ![Ripristino di file system corrotti su VPS senza supporto tecnico: guida immediata Debian e Ubuntu](https://www.mauriziofonte.it/image/002110070-ripristino-filesystem-corrotto-vps-debian-ubuntu.jpg)
- [Server Debian e Ubuntu in emergenza: checklist operativa rapida per VPS](https://www.mauriziofonte.it/blog/post/checklist-emergenza-debian-ubuntu-vps-unmanaged.html)

  La checklist operativa in 7 fasi che uso quando un VPS Debian o Ubuntu va in crisi: triage in 60 secondi con lo USE method, diagnosi disco pieno, · 9 Luglio 2025

  ![Server Debian e Ubuntu in emergenza: checklist operativa rapida per VPS](https://www.mauriziofonte.it/image/002030070-checklist-emergenza-debian-ubuntu-vps-unmanaged.jpg)
- [Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto](https://www.mauriziofonte.it/blog/post/gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.html)

  A novembre 2024 ho gestito un incidente su un magazzino logistico cuneese in cui il server di produzione era stato fermato da un file laravel.log · 12 Giugno 2025

  ![Gestione strategica dei log Laravel su Hetzner e OVH: come ottantasette gigabyte di laravel.log hanno fermato un magazzino e cosa configurare al suo posto](https://www.mauriziofonte.it/image/001750070-gestione-strategica-log-laravel-server-dedicato-hetzner-ovh.jpg)
- [Subentro forzato su un progetto PHP critico: il protocollo che applico nelle prime 72 ore quando lo sviluppatore non risponde più](https://www.mauriziofonte.it/blog/post/guida-subentro-progetto-php-server-hetzner-ovh-aruba-developer-scomparso.html)

  Quando lo sviluppatore sparisce e il business dipende da un'applicazione PHP su Hetzner, OVH o Aruba, le prime 72 ore decidono se il subentro · 9 Giugno 2025

  ![Subentro forzato su un progetto PHP critico: il protocollo che applico nelle prime 72 ore quando lo sviluppatore non risponde più](https://www.mauriziofonte.it/image/001690070-guida-subentro-progetto-php-server-hetzner-ovh-aruba-developer-scomparso.jpg)
- [Correzione automatica del filesystem su Debian: fsck fatto bene con systemd nel 2026](https://www.mauriziofonte.it/blog/post/debian-correzione-file-system-fsck-automatica-reboot.html)

  Un filesystem che non monta più al riavvio blocca tutto. Le vecchie guide per forzare il controllo del filesystem su Debian si basavano su un · 10 Giugno 2026

  ![Correzione automatica del filesystem su Debian: fsck fatto bene con systemd nel 2026](https://www.mauriziofonte.it/image/000260070-debian-correzione-file-system-fsck-automatica-reboot.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Server VPS unmanaged in emergenza con sviluppatore irreperibile: come ho recuperato un Hetzner AX41 lockato in 3 ore con la rescue mode e cosa fare nei primi 30 minuti di crisi", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/ripristino-operativita-web-provider-vps-unmanaged.html

Pubblicato: 2025-06-16 · Aggiornato: 2026-04-14.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.