Punti chiave
- NinjaOne Backup è compatibile con VSS: le applicazioni e i database che supportano il Volume Shadow Copy Service possono essere sottoposti a backup in uno stato coerente a livello applicativo come parte di un normale backup dell’immagine, senza alcuna configurazione particolare.
- Microsoft SQL Server è compatibile con VSS, quindi un normale backup dell’immagine produce una copia del database utilizzabile e ripristinabile, senza passaggi aggiuntivi.
- Non tutte le applicazioni sono compatibili con VSS. In questi casi, un file di backup generato tramite script (come un file BAK di SQL) ti offre una copia pulita e nativa dell’applicazione da proteggere insieme al backup dell’immagine.
- Nei database SQL in modalità di ripristino Simple, i log delle transazioni possono essere troncati automaticamente a ogni checkpoint.
- I backup dell’immagine possono essere montati per recuperare singoli file, ad esempio un singolo file di database, senza dover ripristinare l’intera immagine.
Eseguire il backup di un server Windows è semplice, finché non si considera ciò che ci gira sopra. Un database non resta fermo come un file statico: è nel mezzo di una transazione, di una scrittura, e cambia di continuo. Un backup eseguito nel momento sbagliato può lasciarti una copia apparentemente completa, ma che non si ripristina correttamente. NinjaOne Backup® risolve il problema grazie al riconoscimento delle applicazioni, affidando parte del lavoro al Volume Shadow Copy Service (VSS) di Microsoft.
Come funziona il backup con riconoscimento delle applicazioni
VSS è un servizio di Windows che si coordina con le applicazioni per creare una shadow copy – uno snapshot di un volume in un preciso momento – senza arrestare l’applicazione né interrompere il lavoro degli utenti. Le applicazioni che supportano VSS utilizzano un componente chiamato VSS writer, che indica al processo di snapshot come congelare i dati dell’applicazione in uno stato coerente prima che venga creata la copia.
NinjaOne Backup dialoga direttamente con questi VSS writer nell’ambito di un normale backup dell’immagine. Per qualsiasi applicazione compatibile con VSS, questo significa che il backup acquisisce automaticamente l’applicazione in uno stato coerente a livello applicativo, senza un processo di backup separato né script particolari: basta un normale backup dell’immagine, che protegge anche ciò che gira sopra l’OS.
Detto questo, la compatibilità con VSS dello strumento di backup non sostituisce le indicazioni del fornitore dell’applicazione: verifica sempre cosa consiglia il fornitore per il backup della sua specifica applicazione, perché alcune hanno requisiti aggiuntivi rispetto a quanto copre il solo VSS.
SQL Server: l’esempio di applicazione compatibile con VSS
Microsoft SQL Server è compatibile con VSS per impostazione predefinita, grazie al proprio VSS writer integrato. Un normale backup dell’immagine di un server su cui gira SQL Server produce una copia del database utilizzabile e ripristinabile, senza alcuna configurazione aggiuntiva.
Vale la pena conoscere un paio di aspetti pratici:
- Troncamento del log in modalità di ripristino Simple: quando il database è in modalità di ripristino Simple, SQL Server tronca automaticamente il proprio log delle transazioni a ogni checkpoint.
- Troncamento del log in modalità di ripristino Full: in modalità Full, il log viene troncato solo quando viene eseguito un backup del log delle transazioni. Non basta un backup completo del database, e nemmeno il backup dell’immagine: il log continua quindi a crescere finché qualcosa non ne esegue davvero il backup. Se i tuoi database sono in modalità di ripristino Full, ti serve un piano di manutenzione SQL che includa i backup del log, non solo quelli completi: è parte della routine di backup nativa di SQL descritta più avanti.
- Recupero granulare dei file: con i backup dell’immagine di NinjaOne archiviati in destinazioni Hybrid o Cloud-only, puoi montare l’immagine ed estrarre un singolo file – ad esempio un determinato file di database – senza ripristinare l’intera immagine. È utile quando ti serve recuperare un solo file e non vuoi avviare un ripristino completo solo per ottenerlo.
Come gestire le applicazioni non compatibili con VSS
Non tutti i database vanno d’accordo con VSS. Ecco due esempi comuni.
MySQL non è compatibile con VSS. Di conseguenza, l’approccio standard adottato da NinjaOne consiste nell’eseguire prima uno script che genera un backup del database, per poi includere il file risultante in un processo di backup dell’immagine oppure di file e cartelle.
Anche QuickBooks Desktop non è compatibile con VSS. Un normale backup dell’immagine produce comunque una copia crash-consistent, ma non garantisce la coerenza a livello applicativo. Consigliamo di utilizzare lo strumento di backup interno di QuickBooks, pianificato in modo autonomo, per ottenere una copia nativa dell’applicazione più affidabile. In questo caso, NinjaOne Backup si limita a proteggere il file generato da quello strumento, oltre al backup dell’immagine che già copre la macchina.
In entrambi i casi lo schema è lo stesso. Quando un’applicazione non supporta VSS, lascia che sia l’applicazione (o uno script) a produrre prima un file di backup pulito e nativo, poi proteggi quel file con il tuo normale processo di backup.
Perché un file BAK resta comunque utile
Anche per SQL Server, che è pienamente compatibile con VSS, ha senso generare anche un file di backup dedicato. Uno script preliminare può eseguire il comando di backup nativo di SQL Server per produrre un file BAK, che NinjaOne Backup protegge poi come qualsiasi altro file.
In questo modo ottieni una seconda opzione di ripristino, più flessibile, accanto al backup dell’immagine. Ecco alcuni motivi per cui vale la pena predisporla.
- Ripristini più rapidi e mirati: ripristinare direttamente da un file BAK con gli strumenti nativi di SQL Server può essere più veloce che ripristinare un’intera immagine solo per recuperare il database.
- Obiettivi di punto di ripristino più stringenti: i processi di backup e i piani di manutenzione specifici per SQL possono essere eseguiti più spesso rispetto alla pianificazione del backup dell’immagine. Se ti serve una finestra di ripristino più breve di quella consentita da un backup dell’immagine giornaliero nel cloud, puoi eseguire i backup SQL con maggiore frequenza e proteggere solo quei file con un processo di backup di file e cartelle.
- Un backup indipendente dall’OS: un file BAK è portabile e viene interpretato nativamente dagli strumenti di SQL Server, il che lo rende utile anche per scenari come la migrazione di un database su un altro server, e non solo per il disaster recovery.
Se scegli questa strada, conviene archiviare i backup e i piani di manutenzione specifici per SQL su un volume non incluso nel processo di backup dell’immagine, e utilizzare poi un processo separato di backup di file e cartelle per proteggere solo quei file. In questo modo le due strategie di backup restano nettamente separate, senza sovrapposizioni.
Perché il riconoscimento delle applicazioni è decisivo per il ripristino
Un backup completato con successo non equivale a un backup che si ripristina con successo, ed è proprio questa distanza che il riconoscimento delle applicazioni colma. Il supporto VSS significa che i tuoi backup dell’immagine acquisiscono SQL Server in uno stato davvero utilizzabile al momento del bisogno, senza lavoro aggiuntivo da parte tua. Per le applicazioni che VSS non copre vale lo stesso principio: lascia che sia l’applicazione a produrre una copia pulita dei propri dati, poi esegui il backup di quella copia.
Impostare tutto correttamente fa la differenza tra una giornata rovinata nel tentativo di recuperare un database che sembrava protetto ma non lo era e un semplice ripristino di routine.
