{"id":93710,"date":"2020-09-09T07:42:42","date_gmt":"2020-09-09T05:42:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/politiki-hraneniya-veeam-br-rasputyvaem-bekapnye-czepi-vmeste-s-tehpodderzhkoj"},"modified":"2020-09-09T07:42:42","modified_gmt":"2020-09-09T05:42:42","slug":"politiki-hraneniya-veeam-br-rasputyvaem-bekapnye-czepi-vmeste-s-tehpodderzhkoj","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/politiki-hraneniya-veeam-br-rasputyvaem-bekapnye-czepi-vmeste-s-tehpodderzhkoj","title":{"rendered":"Le politiche di conservazione di Veeam B&R: sciogliamo le catene di backup insieme al supporto tecnico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Saluto i lettori del nostro blog! In parte ci conosciamo gi\u00e0: i miei post in inglese sono apparsi qui nella traduzione della mia cara collega polarowl<\/a><\/noindex>. Questa volta ho deciso di rivolgermi direttamente al pubblico di lingua russa. <\/p>\n

Per il mio debutto volevo trovare un argomento interessante per un pubblico quanto pi\u00f9 ampio possibile e che richiedesse una trattazione dettagliata. Daniel Defoe affermava che a tutti stanno aspettando la morte e le tasse. Da parte mia, posso dire che tutti gli ingegneri di supporto si trovano di fronte a domande sulle politiche di conservazione dei punti di ripristino (o, se volete, sul retention). Come funziona il retention, ho iniziato a spiegarlo 4 anni fa, essendo un ingegnere junior di primo livello, e continuo a spiegalo adesso, essendo ormai team leader del team di lingua spagnola e italiana. Sono certo che anche i miei colleghi di secondo e persino terzo livello di supporto rispondano regolarmente alle stesse domande. <\/p>\n

In questo contesto, ho voluto scrivere un post finale, il pi\u00f9 dettagliato possibile, a cui gli utenti di lingua russa possano tornare ripetutamente come a un manuale. Il momento \u00e8 opportuno: la recente uscita della decima versione anniversaria ha aggiunto nuove funzionalit\u00e0 al gi\u00e0 consolidato set di strumenti, che non sono cambiati per anni. Il mio post \u00e8 principalmente orientato a questa versione \u2014 sebbene gran parte di quanto scritto sia valido anche per le versioni precedenti, alcuni aspetti funzionali semplicemente non saranno trovati. Infine, guardando un po' al futuro, posso dire che ci sono attese alcune modifiche nella prossima versione, ma ne parleremo quando sar\u00e0 il momento. Quindi, iniziamo.<\/p>\n

\"Politiche
\n<\/a><\/noindex><\/p>\n

Compito di backup (Backup job)<\/h2>\n

\nIniziamo esaminando quella parte che non ha subito cambiamenti nella versione 10. La politica di retention \u00e8 definita da diversi parametri. Apriamo la finestra per creare un nuovo compito e andiamo alla scheda Storage. Qui vedremo un parametro che definisce il numero desiderato di punti di ripristino:<\/p>\n

\"Politiche
\n
\nTuttavia, questo \u00e8 solo una parte dell'equazione. Il numero effettivo di punti \u00e8 determinato anche dalla modalit\u00e0 di backup impostata per il task. Per scegliere questo parametro, \u00e8 necessario fare clic sul pulsante Advanced nella stessa scheda. Questo aprir\u00e0 una nuova finestra con molte opzioni. Numeriamole e consideriamole uno per uno:<\/p>\n

\"Politiche
\n
\nSe \u00e8 attivata solo l'opzione 1, il task funzioner\u00e0 in modalit\u00e0 \u00abincremente infinito\u00bb (forever forward incremental). Qui non ci sono difficolt\u00e0: il task conserver\u00e0 un numero stabilito di punti di ripristino dal backup completo (file con estensione VBK) all'ultimo incremento (file con estensione VIB). Quando il numero di punti supera il valore impostato, l'incremento pi\u00f9 vecchio verr\u00e0 unito con il backup completo. In altre parole, se il task \u00e8 impostato per conservare 3 punti, subito dopo una nuova sessione ci saranno 4 punti sul repository, dopodich\u00e9 il backup completo sar\u00e0 unito con il pi\u00f9 vecchio incremento e il numero totale di punti torner\u00e0 a 3. <\/p>\n

\"Politiche
\n
\nIl retention \u00e8 estremamente semplice per la modalit\u00e0 \"reverse incremental\" (opzione 2). In questo caso, il punto pi\u00f9 recente sar\u00e0 un backup completo, che sar\u00e0 seguito da una catena di cosiddetti rollback (file con estensione VRB); quindi, per applicare il retention, basta semplicemente eliminare il rollback pi\u00f9 vecchio. La situazione sar\u00e0 la stessa: subito dopo la sessione, il numero dei punti superer\u00e0 di 1 quello impostato, per poi tornare al valore desiderato.<\/p>\n

\"Politiche
\n
\nSi noti che con la modalit\u00e0 reverse incremental \u00e8 anche possibile attivare un backup completo periodico (opzione 4), ma questo non cambier\u00e0 il concetto. S\u00ec, ci saranno punti di ripristino completi nella catena, ma continueremo semplicemente a eliminare i punti pi\u00f9 vecchi uno alla volta. <\/p>\n

Finalmente, siamo arrivati a una parte interessante. Se attivi il backup incrementale e, in aggiunta, abiliti le opzioni 3 o 4 (o anche entrambe contemporaneamente), il compito inizier\u00e0 a creare backup completi periodici con il metodo \"attivo\" o sintetico. Il metodo per creare il backup completo non \u00e8 importante: conterr\u00e0 gli stessi dati e la catena incrementale sar\u00e0 divisa in \"sotto-catene\". Questo metodo \u00e8 chiamato forward incremental e suscita molte domande tra i nostri clienti. <\/p>\n

La retention qui si applica eliminando la parte pi\u00f9 vecchia della catena (dal backup completo all'incremento). In questo caso, non elimineremo solo il backup vuoto o solo una parte degli incrementi. L'intera \"sotto-catena\" viene rimossa completamente in una sola volta. Cambia anche il significato dell'impostazione del numero di punti: mentre in altri metodi si tratta del numero massimo consentito, dopo il quale \u00e8 necessario applicare la retention, qui questa impostazione determina il numero minimo. In altre parole, dopo l'eliminazione della \"sotto-catena\" pi\u00f9 vecchia, il numero di punti nella parte restante non deve scendere al di sotto di questo minimo. <\/p>\n

Cercher\u00f2 di rappresentare graficamente questo concetto. Supponiamo che il retention sia impostato su 3 punti, l'attivit\u00e0 si esegue ogni giorno con un backup completo il luned\u00ec. In questo caso, il retention sar\u00e0 applicato quando il numero totale di punti raggiunge 10:<\/p>\n

\"Politiche
\n
\nPerch\u00e9 10, se \u00e8 stato impostato a 3? Luned\u00ec \u00e8 stato creato un backup completo. Da marted\u00ec a domenica, l'attivit\u00e0 ha creato incrementi. Infine, il luned\u00ec successivo viene nuovamente creato un backup completo e solo quando sono stati creati 2 incrementi, l'intera parte vecchia della catena pu\u00f2 finalmente essere eliminata, poich\u00e9 il numero rimanente di punti non scender\u00e0 sotto i 3 impostati. <\/p>\n

Se l'idea \u00e8 chiara, ti propongo di provare a calcolare il retention da solo. Prendiamo queste condizioni: l'attivit\u00e0 viene eseguita per la prima volta gioved\u00ec (ovviamente verr\u00e0 effettuato un backup completo). L'attivit\u00e0 \u00e8 impostata per creare un backup completo il mercoled\u00ec e la domenica e per mantenere 8 punti di ripristino. Quando verr\u00e0 applicato il retention per la prima volta?<\/p>\n

Per rispondere a questa domanda, ti consiglio di prendere un foglio di carta, tracciarlo per giorni della settimana e scrivere quale punto viene creato ogni giorno. La risposta diventer\u00e0 evidente.<\/p>\n

Risposta<\/b>
\n \"Politiche
\nSpiegazione: per rispondere, basta chiedersi \"quando sar\u00e0 applicato il retention\"? La risposta \u00e8: quando possiamo rimuovere i primi 3 punti (VBK, VIB, VIB) e la restante sequenza non scende sotto gli 8 punti previsti. Diventa chiaro che possiamo farlo quando abbiamo un totale di 11 punti, ovvero nella domenica della seconda settimana. <\/p>\n

Alcuni lettori potrebbero obiettare: \"perch\u00e9 tutto questo, se c'\u00e8 rps.dewin.me<\/a><\/noindex>?\u00bb. \u0411\u0435\u0437 \u0441\u043e\u043c\u043d\u0435\u043d\u0438\u044f, \u044d\u0442\u043e \u043e\u0447\u0435\u043d\u044c \u043f\u043e\u043b\u0435\u0437\u043d\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442, \u0438 \u0432 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u044f \u0431\u044b \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u043b \u0438\u043c\u0435\u043d\u043d\u043e \u0435\u0433\u043e, \u043d\u043e \u0435\u0441\u0442\u044c \u0443 \u043d\u0435\u0433\u043e \u0438 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f. \u041f\u0440\u0435\u0436\u0434\u0435 \u0432\u0441\u0435\u0433\u043e, \u043e\u043d \u043d\u0435 \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u0443\u043a\u0430\u0437\u0430\u0442\u044c \u043d\u0430\u0447\u0430\u043b\u044c\u043d\u044b\u0435 \u0443\u0441\u043b\u043e\u0432\u0438\u044f, \u0430 \u0432\u043e \u043c\u043d\u043e\u0433\u0438\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0441\u043b\u0443\u0447\u0430\u0435\u0432 \u0432\u043e\u043f\u0440\u043e\u0441 \u0437\u0432\u0443\u0447\u0438\u0442 \u0438\u043c\u0435\u043d\u043d\u043e \u00ab\u0443 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0442\u0430\u043a\u0430\u044f \u0446\u0435\u043f\u043e\u0447\u043a\u0430, \u0447\u0442\u043e \u0431\u0443\u0434\u0435\u0442, \u0435\u0441\u043b\u0438 \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u0442\u0430\u043a\u0438\u0435-\u0442\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438?\u00bb. \u0412\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0443 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043d\u0435 \u0445\u0432\u0430\u0442\u0430\u0435\u0442 \u043d\u0430\u0433\u043b\u044f\u0434\u043d\u043e\u0441\u0442\u0438. \u041f\u043e\u043a\u0430\u0437\u044b\u0432\u0430\u044f \u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0443 RPS \u043a\u043b\u0438\u0435\u043d\u0442\u0430\u043c, \u044f \u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u043b \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u044f, \u0430 \u0432\u043e\u0442 \u0440\u0430\u0441\u043f\u0438\u0441\u0430\u0432 \u0435\u0435 \u043a\u0430\u043a \u0432 \u043f\u0440\u0438\u043c\u0435\u0440\u0435 (\u0434\u0430\u0436\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f \u0442\u043e\u0442 \u0436\u0435 Paint), \u0434\u0435\u043d\u044c \u0437\u0430 \u0434\u043d\u0435\u043c, \u0432\u0441\u0435 \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u043b\u043e\u0441\u044c \u044f\u0441\u043d\u043e. <\/p>\n

Infine, non abbiamo considerato l'opzione \"Trasforma le catene di backup precedenti in rollback\" (contrassegnata dal numero 5). Questa opzione a volte confonde i clienti che la attivano automaticamente, volendo semplicemente includere un backup sintetico. Tuttavia, questa opzione attiva un modo di backup completamente diverso. Senza entrare nei dettagli, posso gi\u00e0 dire che, in questa fase di sviluppo del prodotto, \"Trasforma le catene di backup precedenti in rollback\" \u00e8 un'opzione obsoleta, e non riesco a pensare a nessuno scenario in cui dovrebbe essere utilizzata. Il suo valore \u00e8 cos\u00ec dubbio che per un certo periodo Anton Gostev stesso ha lanciato un appello attraverso il forum, chiedendo di inviargli esempi di utilizzo utile (se li avete, scrivete nei commenti, mi interessa molto). Se non se ne troveranno (penso di s\u00ec), l'opzione sar\u00e0 rimossa nelle prossime versioni. <\/p>\n

Il task creer\u00e0 incrementi (VIB) fino al giorno in cui \u00e8 previsto il backup completo sintetico. In quel giorno viene effettivamente creato un VBK, ma tutti i punti precedenti a questo VBK vengono trasformati in rollbacks (VRB). Dopo ci\u00f2, il task continuer\u00e0 a creare incrementi al backup completo fino al prossimo backup sintetico. Alla fine, nella catena si creer\u00e0 un mix di file VBK, VBR e VIB. La retention viene applicata molto semplicemente: eliminando l'ultimo VBR.<\/p>\n

\"Politiche
\n<\/p>\n

Problemi<\/h3>\n

\nOltre a comprendere come funziona, la maggior parte dei problemi che si presentano durante l'utilizzo della modalit\u00e0 incrementale \u00e8 generalmente legata al backup completo. Un backup completo regolare \u00e8 necessario per questa modalit\u00e0, altrimenti il repository accumuler\u00e0 punti finch\u00e9 non sar\u00e0 pieno. <\/p>\n

Ad esempio, un backup completo potrebbe essere creato con scarsa frequenza. Diciamo che il compito \u00e8 impostato per conservare 10 punti, ma un backup completo viene eseguito una volta al mese. \u00c8 chiaro che il numero effettivo di punti sar\u00e0 significativamente superiore a quello programmato. Oppure il compito \u00e8 stato impostato per funzionare in modo incrementale illimitato e conservare 50 punti. Poi qualcuno ha accidentalmente creato un backup completo. D'ora in poi, il compito dovr\u00e0 attendere che il punto completo accumuli 49 incrementi, dopodich\u00e9 applicher\u00e0 la retention e torner\u00e0 in modalit\u00e0 completamente illimitata.<\/p>\n

In altri casi, il backup completo \u00e8 impostato per essere creato regolarmente, ma per qualche motivo non avviene. Qui descriver\u00f2 il motivo pi\u00f9 comune. Alcuni clienti preferiscono utilizzare l'opzione di programmazione \"run after\" e impostare le attivit\u00e0 per lavorare in cascata. Prendiamo, ad esempio, 3 attivit\u00e0 che vengono eseguite ogni giorno e creano un backup completo la domenica. La prima attivit\u00e0 inizia alle 22:30, le altre vengono avviate in sequenza. Il backup incrementale richiede 10 minuti, quindi entro le 23:00 tutte le attivit\u00e0 vengono completate. Tuttavia, il backup completo richiede un'ora, quindi la domenica accade quanto segue: la prima attivit\u00e0 lavora dalle 22:30 alle 23:30. La successiva dalle 23:30 alle 00:30. E la terza attivit\u00e0 si avvia gi\u00e0 di luned\u00ec. Il backup completo \u00e8 programmato per la domenica, quindi in questo caso non ci sar\u00e0. L'attivit\u00e0 dovr\u00e0 aspettare il backup completo per applicare la retention. Perci\u00f2, fate attenzione quando utilizzate l'opzione \"run after\" oppure non utilizzatela affatto: impostate le attivit\u00e0 per iniziare contemporaneamente e lasciate che il pianificatore delle risorse faccia il suo lavoro. <\/p>\n

L'opzione complessa \"Remove deleted items\"<\/h2>\n

\nNavigando nelle impostazioni del compito Storage \u2013 Advanced \u2013 Maintenance, \u00e8 possibile imbattersi nell'opzione \u201cremove deleted items data after\u201d, misurata in giorni. <\/p>\n

\"Politiche
\n
\nAlcuni clienti si aspettano che questa sia la retention. In realt\u00e0, \u00e8 un'opzione completamente separata, il cui malinteso pu\u00f2 portare a conseguenze inaspettate. Tuttavia, prima di tutto, \u00e8 necessario spiegare come B&R reagisce alle situazioni in cui durante la sessione solo alcune macchine vengono correttamente sottoposte a backup. <\/p>\n

Immaginiamo questo scenario: un compito di backup incrementale infinito, impostato per mantenere 6 punti. Ci sono 2 macchine nel compito, una sempre sottoposta a backup con successo, l'altra che a volte ha mostrato errori. Alla settima istanza, si \u00e8 presentata la seguente situazione:<\/p>\n

\"Politiche
\n
\n\u00c8 il momento di applicare la retention, ma una macchina ha 7 punti, mentre l'altra solo 4. Viene applicata la retention in questo caso? La risposta \u00e8 s\u00ec, verr\u00e0 applicata. Se anche solo un oggetto \u00e8 stato sottoposto a backup, B&R considera che il punto \u00e8 stato creato. <\/p>\n

Una situazione simile pu\u00f2 verificarsi se una macchina non \u00e8 stata semplicemente inclusa nel compito durante una sessione specifica. Questo pu\u00f2 accadere, ad esempio, quando le macchine vengono aggiunte al compito non in modo individuale, ma come parte di contenitori (cartelle, archivi) e una macchina migra temporaneamente in un altro contenitore. In tal caso, il compito sar\u00e0 considerato completato, ma nelle statistiche troverete un messaggio che invita a prestare attenzione al fatto che una determinata macchina non viene pi\u00f9 elaborata dal compito. <\/p>\n

\"Politiche
\n
\nCosa succede se non si presta attenzione a questo? Nel caso di modalit\u00e0 di backup infinitamente incrementale o retroattivo, il numero di punti di ripristino della \u2018macchina problematica\u2019 diminuir\u00e0 ad ogni sessione, finch\u00e9 non raggiunger\u00e0 1, salvato nel VBK. In altre parole, anche se la macchina non viene sottoposta a backup per un lungo periodo, rimarr\u00e0 comunque un punto di ripristino. La situazione cambia se sono attivati i backup completi periodici. Se si ignorano i segnali da B&R, alla fine l'ultimo punto potrebbe essere rimosso insieme alla parte pi\u00f9 vecchia della catena. <\/p>\n

Chiarito questi dettagli, \u00e8 finalmente possibile considerare l'opzione \"Rimuovi i dati degli elementi eliminati dopo\". Questa opzione rimuover\u00e0 tutti i punti per una determinata macchina, se tale macchina non viene sottoposta a backup per X giorni. Va notato che questa impostazione non tiene conto degli errori (provato - non riuscito). Non deve nemmeno esserci un tentativo di backup della macchina. Sembrerebbe che l'opzione sia utile e dovrebbe sempre rimanere attivata. Se l'amministratore ha rimosso la macchina dal compito, \u00e8 logico liberarsi di dati e collegamenti non necessari dopo un certo periodo. Tuttavia, questa impostazione richiede disciplina e attenzione.<\/p>\n

Ecco un esempio pratico: nel job sono stati aggiunti diversi contenitori con una composizione piuttosto dinamica. A causa della mancanza di RAM, il server B&R ha riscontrato problemi rimasti inosservati. Il job \u00e8 partito e ha tentato di effettuare il backup delle macchine, ad eccezione di una che al momento non era presente nel contenitore. Poich\u00e9 molte macchine hanno restituito errori, per impostazione predefinita B&R deve fare 3 tentativi aggiuntivi di backup delle macchine problematiche. A causa dei continui problemi con la RAM, questi tentativi si sono protratti per diversi giorni. Non c'\u00e8 stata una nuova possibilit\u00e0 di eseguire il backup della VM assente (l'assenza della VM non \u00e8 un errore). Di conseguenza, durante uno dei tentativi di ripetizione, \u00e8 stata soddisfatta la condizione \u201cRimuovi elementi eliminati\u201d e tutti i punti di ripristino della macchina sono stati eliminati. <\/p>\n

A riguardo posso dire quanto segue: se hai impostato avvisi sui risultati dei job, e ancor meglio se utilizzi l'integrazione con Veeam ONE, \u00e8 probabile che ci\u00f2 non accada. Se invece controlli il server B&R una volta alla settimana per verificare che tutto funzioni, \u00e8 meglio rinunciare alle opzioni che potrebbero potenzialmente portare all'eliminazione dei backup. <\/p>\n

Cosa \u00e8 stato aggiunto nella v.10<\/h2>\n

\nCi\u00f2 di cui abbiamo parlato in precedenza \u00e8 esistito in B&R per molte versioni. Comprendendo questi principi operativi, vediamo ora cosa \u00e8 stato aggiunto nella decima edizione del nostro anniversario. <\/p>\n

Ritenzione giornaliera<\/h3>\n

\nIn precedenza abbiamo esaminato la politica di archiviazione 'classica', basata sul numero di punti. Un approccio alternativo \u00e8 quello di impostare nel medesimo menu 'giorni' invece di 'punti di ripristino'. <\/p>\n

\"Politiche
\n
\nL\u2019idea \u00e8 chiara dal nome: la ritenzione conserver\u00e0 un numero definito di giorni, mentre il numero di punti per ogni giorno non ha importanza. Tuttavia, \u00e8 importante ricordare quanto segue:<\/p>\n