Prevenire un disco pieno e i backup che falliscono in silenzio

Due guasti arrivano senza preavviso anche se si preparano per settimane: il disco che si riempie, e il backup che fallisce ogni notte mentre nessuno legge il rapporto. Il primo ferma un servizio di lunedì mattina. Il secondo si scopre il giorno in cui bisogna ripristinare.

#Il disco pieno

#Una soglia non basta

Un avviso al 90 % arriva troppo tardi per un volume che cresce di 20 GB al giorno, e troppo presto per un volume stabile pieno al 91 % da due anni. La domanda giusta è: a questo ritmo, quando sarà pieno?

#Verificare senza strumenti

1. Annotate lo spazio libero di ogni volume fisso, alla stessa ora, ogni giorno per due settimane.
2. Calcolate la crescita media giornaliera, escludendo i giorni di pulizia o di ampliamento.
3. Dividete lo spazio libero per questa crescita: ottenete il numero di giorni rimanenti.

Get-Volume | Where-Object DriveType -eq 'Fixed' | Select-Object DriveLetter, FileSystemLabel, @{n='Libero (GB)';e={[math]::Round($_.SizeRemaining/1GB,1)}}, @{n='Dimensione (GB)';e={[math]::Round($_.Size/1GB,1)}}

Le cause più frequenti: log applicativi che nulla elimina, una cartella di backup locale che si accumula, profili utente su un server di desktop remoto, e il log delle transazioni di un database SQL Server.

#Il log delle transazioni

Nel modello di recupero FULL, il log delle transazioni di un database si svuota solo dopo un backup del log. Senza questo backup cresce fino a riempire il disco. La colonna log_reuse_wait_desc dice che cosa gli impedisce di svuotarsi: LOG_BACKUP significa che attende un backup del log.

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
ORDER BY name;

Scegliete con cognizione di causa. Il modello FULL permette di ripristinare a un istante preciso e richiede backup del log regolari. Il secondo modello svuota il log da solo: basta se tornare all'ultimo backup del database vi va bene.

#I backup che falliscono in silenzio

#Le cause abituali

• il processo SQL Server Agent fallisce, e l'e-mail di errore parte verso una cassetta che nessuno legge;
• il servizio SQL Server Agent non riparte dopo un aggiornamento, e i processi non girano più;
• lo script di backup pianificato si ferma su un errore senza segnalare nulla;
• un nuovo database è stato creato senza essere aggiunto al piano di backup.

#Verificare i database SQL Server

SELECT d.name, d.recovery_model_desc,
  MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS ultimo_completo,
  MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS ultimo_log
FROM sys.databases d
LEFT JOIN msdb.dbo.backupset b ON b.database_name = d.name
WHERE d.name <> 'tempdb'
GROUP BY d.name, d.recovery_model_desc
ORDER BY ultimo_completo;

Un database con NULL nella colonna ultimo_completo non ha backup noti a questa istanza. Un software che salva le macchine virtuali può però copiare il database senza lasciare traccia in msdb: verificate allora in quel software.

SELECT j.name, h.run_date, h.run_time, h.message
FROM msdb.dbo.sysjobhistory h
JOIN msdb.dbo.sysjobs j ON j.job_id = h.job_id
WHERE h.run_status = 0 AND h.step_id = 0
ORDER BY h.run_date DESC, h.run_time DESC;

Il controllo di integrità (DBCC CHECKDB) conta quanto il backup: il backup di un database già corrotto ripristina un database corrotto. La data dell'ultimo controllo riuscito si legge nel campo dbi_dbccLastKnownGood di DBCC DBINFO WITH TABLERESULTS.

#Verificare uno script di backup

Per uno script pianificato (copia di file, esportazione, backup di un apparato), invertite la logica. Invece di attendere un messaggio di errore, attendete un segnale di riuscita: lo script chiama un indirizzo alla fine del lavoro, e parte un avviso se la chiamata non arriva entro il tempo previsto. Uno script che si blocca, un'attività disattivata o un server spento danno allora lo stesso risultato: nessun segnale, quindi un avviso.

#Provare il ripristino

Un backup vale solo se si ripristina. RESTORE VERIFYONLY verifica che il file sia leggibile, non che il database torni. Ripristinate un database su un'istanza di test almeno una volta a trimestre, e annotate la durata: è il vostro tempo reale di ripristino.

#Che cosa segue FirstSI

La data di saturazione segue il metodo descritto sopra. Ogni giorno FirstSI tiene l'occupazione più alta della giornata, traccia la retta degli ultimi 30 giorni e la prolunga fino al 90 % e al 100 %. Gli servono 7 giorni di misure. Un ampliamento o una grossa pulizia vengono riconosciuti come una rottura, e il calcolo riparte dai giorni successivi. Vedere Previsione di capacità.

Se uno strumento esterno salva i vostri database, spuntate Salvata da uno strumento esterno nell'impostazione dell'istanza: la regola dei backup diventa una constatazione bassa, senza incidente. Vedere Attività in background dei database.

Per un heartbeat, lo script chiama il suo URL di ping alla fine del lavoro. Con $ErrorActionPreference = 'Stop', un errore PowerShell ferma lo script prima della chiamata:

$ErrorActionPreference = 'Stop'
# … comandi di backup …
Invoke-RestMethod -Uri "https://console.exemple.fr/api/heartbeat/<identificativo>/ping" -Method Post

Un programma esterno (robocopy, per esempio) non genera un errore PowerShell: verificatene il codice di uscita prima della chiamata. Vedere HostMonitor: disponibilità dei servizi.

I volumi pieni tra meno di 14 giorni, o già occupati al 95 %, compaiono anche nell'elenco Da gestire della dashboard.

#Per approfondire

• DBMonitor: database: prestazioni, sessioni, blocchi e query di controllo di business.
• Avvisi e notifiche: essere avvisati per e-mail, Teams o Slack.
• Rafforzare i propri server Windows: aggiornamenti, antivirus e persistenza sugli stessi server.

Presentazione: Monitoraggio SQL Server e MariaDB: prestazioni↗

Fonte: · Docs FirstSI · aggiornato il 11/10/2026