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?
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.
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
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 VERIFICATO: https://docs.microsoft.com/en-US/troubleshoot/windows-server/backup-and-storage/full-garbage-collection-performance-issue
@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.
@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
@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!!
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.
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,
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à.
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.
