{"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":"Politiche di archiviazione Veeam B&R \u2014 districhiamo 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 tema che fosse interessante per il pubblico pi\u00f9 ampio possibile e che richiedesse un'analisi dettagliata. Daniel Defoe sosteneva che ogni persona \u00e8 destinata a due cose: alla morte e alle tasse. Da parte mia, posso dire che ogni ingegnere di supporto si aspetta di ricevere domande sulle politiche di retention dei punti di ripristino (o, pi\u00f9 semplicemente, sul \u2018retention\u2019). Come funziona il retention, ho iniziato a spiegarlo 4 anni fa, quando ero un ingegnere junior di primo livello, e continuo a spiegarlo anche ora, essendo diventato team leader di un team di lingua spagnola e italiana. Sono sicuro che i miei colleghi di secondo e persino terzo livello di supporto rispondono regolarmente alle stesse domande. <\/p>\n

In questa luce, ho voluto scrivere un post definitivo, il pi\u00f9 dettagliato possibile, a cui gli utenti di lingua russa possano tornare continuamente come a un manuale. Il momento \u00e8 opportuno: la recente uscita della decima versione anniversaria ha aggiunto nuove funzionalit\u00e0 al core che non \u00e8 cambiato per anni. Il mio post \u00e8 orientato principalmente su questa versione, anche se gran parte di quanto scritto \u00e8 valido anche per le versioni precedenti; alcune delle funzionalit\u00e0 descritte non le troverete semplicemente l\u00ec. Infine, guardando un po' al futuro, dir\u00f2 che nella prossima versione sono attesi alcuni cambiamenti, ma ne parleremo quando sar\u00e0 il momento. Quindi, cominciamo.<\/p>\n

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

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

\nPer iniziare, analizziamo quella parte che non ha subito modifiche nella versione 10. La politica di retention \u00e8 definita da diversi parametri. Apriamo la finestra di creazione di un nuovo compito e passiamo alla scheda Storage. Qui vedremo un parametro che determina il numero desiderato di punti di ripristino:<\/p>\n

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

\"Politiche
\n
\nSe attivi solo l'opzione 1, il compito funzioner\u00e0 in modalit\u00e0 \"incrementale infinito\" (forever forward incremental). Non ci sono difficolt\u00e0 in questo: il compito conserver\u00e0 un numero impostato di punti di ripristino dal backup completo (file con estensione VBK) fino all'ultimo incremento (file con estensione VIB). Quando il numero di punti supera il valore impostato, il pi\u00f9 antico incremento verr\u00e0 unito al backup completo. In altre parole, se il compito \u00e8 impostato per conservare 3 punti, subito dopo una sessione ci saranno 4 punti nel repository, dopo di che il backup completo verr\u00e0 unito con il pi\u00f9 antico incremento e il numero totale di punti torner\u00e0 a 3. <\/p>\n

\"Politiche
\n
\nAnche il retention per la modalit\u00e0 \"reverse incremental\" (opzione 2) \u00e8 estremamente semplice. Poich\u00e9 in questo caso l'ultima punto sar\u00e0 un backup completo, seguito da una catena di cosiddetti rollback (file con estensione VRB), per applicare il retention \u00e8 sufficiente eliminare il rollback pi\u00f9 vecchio. La situazione sar\u00e0 la stessa: subito dopo una sessione il numero di punti superer\u00e0 il valore impostato di 1, dopodich\u00e9 torner\u00e0 al valore desiderato.<\/p>\n

\"Politiche
\n
\nTieni presente che con la modalit\u00e0 reverse incremental \u00e8 possibile attivare anche backup completi periodici (opzione 4), ma questo non cambia la sostanza. S\u00ec, nella catena appariranno punti di ripristino completi, ma continueremo semplicemente a eliminare i punti pi\u00f9 vecchi uno alla volta. <\/p>\n

Infine, arriviamo alla parte interessante. Se attivi il backup incrementale, ma in aggiunta attivi le opzioni 3 o 4 (o anche entrambe contemporaneamente), il compito inizier\u00e0 a creare backup completi periodici con metodo \"attivo\" o sintetico. Il metodo di creazione del backup completo non \u00e8 importante: conterr\u00e0 gli stessi dati, mentre la catena incrementale sar\u00e0 suddivisa in \"sotto catene\". Questo metodo \u00e8 chiamato forward incremental ed \u00e8 proprio questo che suscita la maggior parte delle domande da parte dei nostri clienti. <\/p>\n

La retention qui viene applicata rimuovendo la parte pi\u00f9 vecchia della catena (dal backup completo all'incremento). In questo caso, non rimuoveremo 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: se in altri metodi \u00e8 il numero massimo consentito, dopo il quale \u00e8 necessario applicare la retention, qui questo parametro definisce il numero minimo. In altre parole, dopo aver rimosso la parte pi\u00f9 vecchia della \"sotto-catena\", il numero di punti nella parte restante non deve scendere al di sotto di questo minimo. <\/p>\n

Cercher\u00f2 di illustrare questo concetto graficamente. Supponiamo che la retention sia impostata su 3 punti, il compito funziona ogni giorno con un backup completo il luned\u00ec. In questo caso, la retention sar\u00e0 applicata quando il numero totale di punti raggiunge 10:<\/p>\n

\"Politiche
\n
\nPerch\u00e9 10, quando \u00e8 stato impostato a 3? Luned\u00ec \u00e8 stato creato un backup completo. Da marted\u00ec a domenica, il compito 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 pi\u00f9 vecchia della catena pu\u00f2 essere rimossa, perch\u00e9 il numero rimanente di punti non scender\u00e0 al di sotto dei 3 impostati. <\/p>\n

Se l'idea \u00e8 chiara, ti invito a provare a calcolare la retention da solo. Prendiamo queste condizioni: il compito viene avviato per la prima volta il gioved\u00ec (naturalmente, verr\u00e0 effettuato un backup completo). Il compito \u00e8 impostato per creare un backup completo il mercoled\u00ec e la domenica e conservare 8 punti di ripristino. Quando sar\u00e0 applicata la 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 ovvia.<\/p>\n

Risposta<\/b>
\n \"Politiche
\nSpiegazione: per rispondere basta chiedersi \"quando sar\u00e0 applicata la retention\"? Risposta: quando potremo rimuovere i 3 primi punti (VBK, VIB, VIB) e la catena rimanente non scender\u00e0 al di sotto dei 8 punti previsti. \u00c8 chiaro che saremo in grado di farlo quando avremo 11 punti in totale, cio\u00e8 la 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

Finalmente, 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 \u00abautomaticamente\u00bb, desiderando semplicemente attivare un backup sintetico. Nel frattempo, questa opzione attiva un modo di backup completamente speciale. Senza entrare nei dettagli, devo dire che a questo punto dello sviluppo del prodotto, \"Trasforma le catene di backup precedenti in rollback\" \u00e8 un'opzione obsoleta e non riesco a pensare a uno scenario in cui dovrebbe essere utilizzata. Il suo valore \u00e8 cos\u00ec dubbio che per un certo periodo Anton Gostev ha lanciato un appello sul forum chiedendo di inviargli esempi del suo utilizzo utile (se ne avete, scrivete nei commenti, mi interessa molto). Se non si trovano (penso che sar\u00e0 cos\u00ec), l'opzione verr\u00e0 rimossa nelle versioni successive. <\/p>\n

L'attivit\u00e0 creer\u00e0 incrementi (VIB) fino al giorno in cui \u00e8 programmato un backup completo sintetico. In quel giorno viene effettivamente creato un VBK, ma tutti i punti fino a quel VBK vengono trasformati in rollback (VRB). Dopo ci\u00f2, l'attivit\u00e0 continuer\u00e0 a creare incrementi per il backup completo fino al successivo backup sintetico. In definitiva, nella catena si crea un mix esplosivo di file VBK, VBR e VIB. La retention si applica in modo molto semplice: rimuovendo l'ultimo VBR:<\/p>\n

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

Problemi<\/h3>\n

\nOltre alla comprensione di come funziona, la maggior parte dei problemi che sorgono durante l'uso della modalit\u00e0 incrementale sono solitamente legati al backup completo. Un backup completo regolare \u00e8 necessario per questa modalit\u00e0, altrimenti il repository accumuler\u00e0 punti fino a quando non si riempir\u00e0. <\/p>\n

Ad esempio, un backup completo potrebbe essere creato troppo raramente. Diciamo che l'attivit\u00e0 \u00e8 impostata per mantenere 10 punti, mentre un backup completo viene creato una volta al mese. \u00c8 chiaro che il numero effettivo di punti qui sar\u00e0 significativamente maggiore di quello impostato. Oppure, l'attivit\u00e0 \u00e8 anche impostata per funzionare in modalit\u00e0 incrementale infinita e mantenere 50 punti. Poi qualcuno ha accidentalmente creato un backup completo. Ecco, da quel momento l'attivit\u00e0 aspetter\u00e0 che il punto completo accumuli 49 incrementi, dopo di che applicher\u00e0 la retention e torner\u00e0 alla modalit\u00e0 completamente infinita.<\/p>\n

Negli altri casi, il backup completo \u00e8 impostato per essere creato regolarmente, ma per qualche motivo non lo fa. Descriver\u00f2 qui la ragione pi\u00f9 comune. Alcuni clienti preferiscono utilizzare l'opzione di programmazione \"esegui dopo\" e impostare i task per lavorare in sequenza. Prendiamo questo esempio: ci sono 3 task che si eseguono ogni giorno e creano un backup completo di domenica. Il primo task inizia alle 22:30, gli altri si attivano in sequenza. Il backup incrementale richiede 10 minuti, e quindi alle 23:00 tutti i task terminano. Il backup completo, invece, richiede un'ora, quindi di domenica accade quanto segue: il primo task lavora dalle 22:30 alle 23:30. Il secondo dalle 23:30 a 00:30. E il terzo task si attiva gi\u00e0 luned\u00ec. Il backup completo \u00e8 programmato per domenica, quindi in questo caso semplicemente non ci sar\u00e0. Il task attender\u00e0 il backup completo per applicare la retention. Pertanto, fate attenzione quando utilizzate l'opzione \"esegui dopo\" o non utilizzatela affatto: semplicemente programmate i task per partire allo stesso orario e lasciate che il pianificatore delle risorse svolga il proprio lavoro. <\/p>\n

L'opzione non semplice \"Rimuovi oggetti eliminati\"<\/h2>\n

\nNavigando tra le impostazioni del task Storage \u2013 Advanced \u2013 Maintenance, ci si pu\u00f2 imbattere nell'opzione \"rimuovi i dati degli oggetti eliminati dopo\", calcolata in giorni. <\/p>\n

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

Immaginiamo questo scenario: un task di backup incrementale continuo, impostato per conservare 6 punti. Nel task ci sono 2 macchine, una viene sempre sottoposta a backup con successo, l'altra d\u00e0 errori di tanto in tanto. Alla settima punto, si \u00e8 presentata la seguente situazione:<\/p>\n

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

Una situazione analoga pu\u00f2 verificarsi se qualche macchina non \u00e8 stata semplicemente inclusa nell'attivit\u00e0 durante una determinata sessione. Questo succede, ad esempio, quando le macchine vengono aggiunte all'attivit\u00e0 non individualmente, ma come parte di contenitori (cartelle, archivi) e una certa macchina migra temporaneamente in un altro contenitore. In tal caso, l'attivit\u00e0 sar\u00e0 considerata completata, ma nelle statistiche troverete un messaggio che invita a prestare attenzione al fatto che tale macchina non \u00e8 pi\u00f9 elaborata dall'attivit\u00e0. <\/p>\n

\"Politiche
\n
\nE cosa succede se non si presta attenzione a questo? Nel caso di modalit\u00e0 di incremento infinito o di decremento inverso, il numero di punti di ripristino della macchina \"problem\u00e1tica\" diminuir\u00e0 ad ogni sessione, fino a raggiungere 1, salvato in VBK. In altre parole, anche se la macchina non viene eseguita il backup per lungo tempo, un punto di ripristino rimarr\u00e0 comunque. La situazione \u00e8 diversa se sono abilitati backup completi periodici. Se si ignorano i segnali da B&R, alla fine l'ultimo punto potrebbe essere eliminato insieme alla vecchia parte della catena. <\/p>\n

Chiariti questi dettagli, \u00e8 finalmente possibile considerare l'opzione \"Remove deleted items data after\". Essa eliminer\u00e0 tutti i punti per una determinata macchina, se questa macchina non viene sottoposta a backup per X giorni. Si prega di notare che questa impostazione non reagisce agli errori (abbiamo provato - non ha funzionato). Non ci deve essere nemmeno un tentativo di eseguire il backup della macchina. Sembrerebbe che l'opzione sia utile e debba sempre rimanere attivata. Se l'amministratore ha rimosso la macchina dall'attivit\u00e0, \u00e8 logico pulire i dati non necessari e la catena dopo un certo periodo di tempo. Tuttavia, l'impostazione richiede disciplina e attenzione.<\/p>\n

Fornir\u00f2 un esempio pratico: nel job sono stati aggiunti diversi contenitori, la cui composizione era piuttosto dinamica. A causa della mancanza di RAM, il server B&R ha riscontrato problemi che sono rimasti inosservati. Il job \u00e8 partito e ha cercato di effettuare il backup delle macchine, tranne una, che in quel momento non era presente nel contenitore. Poich\u00e9 molte macchine hanno generato errori, per impostazione predefinita B&R deve effettuare 3 tentativi aggiuntivi di fare il backup delle macchine \"problema\". A causa dei costanti problemi di RAM, questi tentativi si sono protratti per diversi giorni. Non c'\u00e8 stata una ripetizione del tentativo di effettuare il backup della VM mancante (la mancanza della VM non \u00e8 un errore). Alla fine, durante uno dei tentativi di ripetizione, \u00e8 stata eseguita la condizione \u201cRimuovi elementi eliminati\u201d e tutti i punti di ripristino della macchina sono stati cancellati. <\/p>\n

A questo proposito posso dire quanto segue: se hai impostato le notifiche sui risultati dei job, ancor meglio \u2014 se utilizzi l'integrazione con Veeam ONE, \u00e8 probabile che non ti succeda nulla del genere. Se per\u00f2 controlli il server B&R ogni settimana per verificare che tutto funzioni, \u00e8 meglio rinunciare a 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 prima \u00e8 esistito in B&R per molte versioni. Chiariti questi principi di funzionamento, vediamo ora cosa \u00e8 stato aggiunto nel celebrativo \"dieci\". <\/p>\n

Ritenzione giornaliera<\/h3>\n

\nSopra abbiamo esaminato la politica di conservazione \"classica\", basata sul numero di punti di ripristino. Un approccio alternativo \u00e8 impostare nel medesimo menu \"giorni\" invece di \"punti di ripristino\". <\/p>\n

\"Politiche
\n
\nL'idea \u00e8 chiara dal nome: la ritenzione conserver\u00e0 un numero stabilito di giorni, mentre il numero di punti in ciascun giorno non ha importanza. Occorre per\u00f2 ricordare quanto segue:<\/p>\n