Solved

Backup di Microsoft filesystem deduplicato


Userlevel 3

Sottopongo alla community un tema dal quale non riesco a trovare via di uscita.

Ho un file server windows con filesystem deduplicato che ogni fine settimana esegue il processo di garbage collection. Il processo di garbage muove in quella circostanza 700GB-1TB di dati che Veeam tratta e backuppa di conseguenza. 

Questo delta significativo incide in maniera importante sullo spazio del repository ( repository linux con file system xfs + immutabilità ) portandolo a riempirsi.

Chiedo se qualcuno ha un consiglio su come aggirare il problema, agendo lato Microsoft o lato Veeam, o se siete a conoscenza di best practices per queste circostanze di cui tener conto.

Grazie

Luca  

icon

Best answer by LucaDM 15 April 2022, 12:29

View original

12 comments

Userlevel 7
Badge +7

ciao hai gia letto questo articolo?

KB2023: Best Practices for Microsoft Deduplication (veeam.com)

 

Dovresti rimuovere la compressione dal job nativo di veeam.

 

Data deduplication using both Windows Server 2016 and Veeam

 

Userlevel 7
Badge +13

Penso sia proprio quello indicato da @Link State la soluzione al problema.

@LucaDM ti faccio solo una domanda veloce OT: immutable backup come principale o secondario?

Userlevel 3

ciao hai gia letto questo articolo?

KB2023: Best Practices for Microsoft Deduplication (veeam.com)

 

Dovresti rimuovere la compressione dal job nativo di veeam.

 

Data deduplication using both Windows Server 2016 and Veeam

 

Perdonatemi, credo di essere stato poco chiaro io, il filesystem deduplicato che cito non è usato come repository di backup per Veeam, è quello del fileserver di cui Veeam fa il backup. Il processo di garbage sul fileserver in questione e come poter gestire la quantità di blocchi che modifica è il nocciolo della questione. I blocchi che vengono modificati dalla garbage diventano blocchi da backuppare per Veeam e questo produce gli incrementali con i valori che indicavo, cosa che vorrei provare quanto meno a contenere.  

Userlevel 3

Penso sia proprio quello indicato da @Link State la soluzione al problema.

@LucaDM ti faccio solo una domanda veloce OT: immutable backup come principale o secondario?

Principale

Userlevel 7
Badge +13

ciao hai gia letto questo articolo?

KB2023: Best Practices for Microsoft Deduplication (veeam.com)

 

Dovresti rimuovere la compressione dal job nativo di veeam.

 

Data deduplication using both Windows Server 2016 and Veeam

 

Perdonatemi, credo di essere stato poco chiaro io, il filesystem deduplicato che cito non è usato come repository di backup per Veeam, è quello del fileserver di cui Veeam fa il backup. Il processo di garbage sul fileserver in questione e come poter gestire la quantità di blocchi che modifica è il nocciolo della questione. I blocchi che vengono modificati dalla garbage diventano blocchi da backuppare per Veeam e questo produce gli incrementali con i valori che indicavo, cosa che vorrei provare quanto meno a contenere.  

Grazie Luca, adesso ho capito.

Prima di risponderti ho provato un attimo ad analizzare la situazione: quanto il GC interviene sposta dei blocchi. Veeam ovviamente rileva un cambiamento di blocco e quindi lo backuppa. E da qui non si scappa. Ecco perchè ti ritrovi con questa problematica. 

L’unica cosa che puoi fare è volendo configurare un active full dopo che il GC interviene, potrebbe (e sottolineo potrebbe) risultare in un task più veloce rispetto a un incrementale con una grande quantità di blocchi cambiati e successivo synthetic.

Lato Windows invece navigando ho trovato questo, MA NON L’HO MAI TESTATO NE VERIFICATOhttps://docs.microsoft.com/en-US/troubleshoot/windows-server/backup-and-storage/full-garbage-collection-performance-issue
 

Userlevel 7
Badge +13

@LucaDM molto interessante questo case sul forum

https://forums.veeam.com/vmware-vsphere-f24/windows-dedup-and-cbt-t66016.html

che un utente si ritrova con una situazione simile.

Userlevel 3

@LucaDM molto interessante questo case sul forum

https://forums.veeam.com/vmware-vsphere-f24/windows-dedup-and-cbt-t66016.html

che un utente si ritrova con una situazione simile.

Questo è molto interessante, lo approfondirò e testerò di sicuro. Se ottengo i risultati voluti aggiorno il Topic.
Grazie 

Userlevel 7
Badge +13

@LucaDM molto interessante questo case sul forum

https://forums.veeam.com/vmware-vsphere-f24/windows-dedup-and-cbt-t66016.html

che un utente si ritrova con una situazione simile.

Questo è molto interessante, lo approfondirò e testerò di sicuro. Se ottengo i risultati voluti aggiorno il Topic.
Grazie 

Facci sapere!!

Userlevel 2
Badge

Ciao,

butto li una idea che mi è venuta leggendo il topic, più che come soluzione, come spunto di scambio:

Backuppare i dischi non deduplicati (es il disco del sistema operativo) con veeam B&R andando a fare le exclusion dei dischi deduplicati e poi con un veeam agent for win backuppare i dischi deduplicati della VM?

Non escludo che usandolo Volume-Level il problema ci sia ugualmente, ma usando file-level potrebbe funzionare.

 

Ciao.

Userlevel 7
Badge +13

Ciao,

butto li una idea che mi è venuta leggendo il topic, più che come soluzione, come spunto di scambio:

Backuppare i dischi non deduplicati (es il disco del sistema operativo) con veeam B&R andando a fare le exclusion dei dischi deduplicati e poi con un veeam agent for win backuppare i dischi deduplicati della VM?

Non escludo che usandolo Volume-Level il problema ci sia ugualmente, ma usando file-level potrebbe funzionare.

 

Ciao.

Più che altro con una soluzione simile in caso di disaster recovery ti troveresti con il doppio di backup da dover gestire, ripristinando prima i volumi del OS e poi quelli dei dati. A livello logico non mi sembra una gran mossa.

Detto questo, il file level è by design più lento rispetto a un volume level, oltre che il cambio dei blocchi avviene ugualmente, andando a vanificare la scelta fatta.

Userlevel 3

Ciao,

butto li una idea che mi è venuta leggendo il topic, più che come soluzione, come spunto di scambio:

Backuppare i dischi non deduplicati (es il disco del sistema operativo) con veeam B&R andando a fare le exclusion dei dischi deduplicati e poi con un veeam agent for win backuppare i dischi deduplicati della VM?

Non escludo che usandolo Volume-Level il problema ci sia ugualmente, ma usando file-level potrebbe funzionare.

 

Ciao.

Più che altro con una soluzione simile in caso di disaster recovery ti troveresti con il doppio di backup da dover gestire, ripristinando prima i volumi del OS e poi quelli dei dati. A livello logico non mi sembra una gran mossa.

Detto questo, il file level è by design più lento rispetto a un volume level, oltre che il cambio dei blocchi avviene ugualmente, andando a vanificare la scelta fatta.

Ciao e grazie per i vostri suggerimenti. Vi aggiorno su quanto fatto nel mio caso. Alla fine la soluzione indicata e legata al cbt non ha avuto risultati positivi, almeno non nel nostro specifico caso, abbiamo quindi approcciato sfruttando il backup NAS di veeam che ha aggirato l’ostacolo. Quindi backup del solo disco di sistema del fileserver escludendo il resto dei dischi e beackup nas per il filesystem deduplicato. Avevamo valutato anche l’uso dell’agente, ma nel nostro specifico ci dava meno elasticità.     

Userlevel 7
Badge +13

Ciao,

butto li una idea che mi è venuta leggendo il topic, più che come soluzione, come spunto di scambio:

Backuppare i dischi non deduplicati (es il disco del sistema operativo) con veeam B&R andando a fare le exclusion dei dischi deduplicati e poi con un veeam agent for win backuppare i dischi deduplicati della VM?

Non escludo che usandolo Volume-Level il problema ci sia ugualmente, ma usando file-level potrebbe funzionare.

 

Ciao.

Più che altro con una soluzione simile in caso di disaster recovery ti troveresti con il doppio di backup da dover gestire, ripristinando prima i volumi del OS e poi quelli dei dati. A livello logico non mi sembra una gran mossa.

Detto questo, il file level è by design più lento rispetto a un volume level, oltre che il cambio dei blocchi avviene ugualmente, andando a vanificare la scelta fatta.

Ciao e grazie per i vostri suggerimenti. Vi aggiorno su quanto fatto nel mio caso. Alla fine la soluzione indicata e legata al cbt non ha avuto risultati positivi, almeno non nel nostro specifico caso, abbiamo quindi approcciato sfruttando il backup NAS di veeam che ha aggirato l’ostacolo. Quindi backup del solo disco di sistema del fileserver escludendo il resto dei dischi e beackup nas per il filesystem deduplicato. Avevamo valutato anche l’uso dell’agente, ma nel nostro specifico ci dava meno elasticità.     

Eh purtroppo al cbt non si scappa :)

Felice abbiate risolto!
Luca ricordati di chiudere il case segnando una risposta come corretta.

Comment