{"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\/da\/blog\/administrirovanie\/politiki-hraneniya-veeam-br-rasputyvaem-bekapnye-czepi-vmeste-s-tehpodderzhkoj","title":{"rendered":"Veeam B&R opbevaringspolitikker \u2013 vi griber ind i backup-k\u00e6derne sammen med teknisk support","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Velkommen til l\u00e6serne af vores blog! P\u00e5 en m\u00e5de kender vi allerede hinanden \u2013 mine engelsksprogede indl\u00e6g har v\u00e6ret her oversat af min k\u00e6re kollega. polarowl<\/a><\/noindex>. Denne gang har jeg besluttet at henvende mig direkte til det russisktalende publikum. <\/p>\n

Til min debut \u00f8nskede jeg at finde et emne, der ville interessere s\u00e5 bred en m\u00e5lgruppe som muligt og kr\u00e6ve en detaljeret gennemgang. Daniel Defoe h\u00e6vdede, at enhver person konfronteres med d\u00f8d og skatter. Her fra mit perspektiv kan jeg sige, at enhver supportingeni\u00f8r konfronteres med sp\u00f8rgsm\u00e5l om politikker for opbevaring af gendannelsespunkter (eller hvis man vil, retention). Hvordan retention fungerer, begyndte jeg at forklare for 4 \u00e5r siden, da jeg var junior ingeni\u00f8r p\u00e5 f\u00f8rste niveau, og jeg forts\u00e6tter med at forklare det nu, hvor jeg er teamlead for det spansktalende og italiensktalende team. Jeg er sikker p\u00e5, at mine kolleger p\u00e5 andet og endda tredje supportniveau ogs\u00e5 regelm\u00e6ssigt svarer p\u00e5 de samme sp\u00f8rgsm\u00e5l. <\/p>\n

I denne forbindelse ville jeg skrive et endeligt, s\u00e5 detaljeret indl\u00e6g som muligt, som russisktalende brugere kunne vende tilbage til som en vejledning. \u00d8jeblikket er passende \u2013 den for nylig udgivne jubil\u00e6ums tiende version har tilf\u00f8jet nye funktioner til den grundl\u00e6ggende funktionalitet, som ikke har \u00e6ndret sig i \u00e5revis. Mit indl\u00e6g er prim\u00e6rt rettet mod denne version \u2014 selvom det meste af det skrevne ogs\u00e5 g\u00e6lder for tidligere versioner, vil du ikke finde noget af den beskrevne funktionalitet der. Endelig, n\u00e5r vi kigger lidt ind i fremtiden, vil jeg sige, at nogle \u00e6ndringer forventes i n\u00e6ste version, men vi vil fort\u00e6lle om det, n\u00e5r tiden er inde. Lad os komme i gang.<\/p>\n

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

Backup-opgaver (Backup job)<\/h2>\n

\nTil at begynde med vil vi se p\u00e5 den del, der ikke har \u00e6ndret sig i version 10. Retention-politikken defineres af flere parametre. Lad os \u00e5bne vinduet for oprettelse af en ny opgave og g\u00e5 til fanen Storage. Her vil vi se en parameter, der definerer det \u00f8nskede antal gendannelsespunkter:<\/p>\n

\"Veeam
\n
\nMen dette er kun en del af ligningen. Det faktiske antal punkter bestemmes ogs\u00e5 af backup-tilstanden, som er indstillet for opgaven. For at v\u00e6lge denne parameter skal du klikke p\u00e5 knappen Advanced p\u00e5 samme fane. Dette \u00e5bner et nyt vindue med mange muligheder. Lad os nummerere dem og gennemg\u00e5 dem en ad gangen:<\/p>\n

\"Veeam
\n
\nHvis kun mulighed 1 aktiveres, vil opgaven k\u00f8re i \"uendeligt inkrementelt\" mode (forever forward incremental). Her opst\u00e5r der ingen vanskeligheder - opgaven vil gemme det indstillede antal gendannelsespunkter fra det fulde backup (fil med filtypen VBK) til den seneste inkrement (fil med filtypen VIB). N\u00e5r antallet af punkter overskrider den indstillede v\u00e6rdi, vil den \u00e6ldste inkrement blive fusioneret med den fulde backup. Med andre ord, hvis opgaven er indstillet til at gemme 3 punkter, vil der umiddelbart efter den n\u00e6ste session v\u00e6re 4 punkter i arkivet, hvorefter den fulde backup vil blive fusioneret med den \u00e6ldste inkrement, og det samlede antal punkter vil vende tilbage til 3. <\/p>\n

\"Veeam
\n
\nRetention er ogs\u00e5 meget enkel for den \"omvendt inkrementale\" (reverse incremental) tilstand (mulighed 2). I dette tilf\u00e6lde vil det nyeste punkt v\u00e6re den fulde backup, efterfulgt af en k\u00e6de af s\u00e5kaldte rollback-filer (filer med filtypen VRB), s\u00e5 det er nok at slette den \u00e6ldste rollback for at anvende retention. Situationen vil v\u00e6re den samme: umiddelbart efter sessionen vil antallet af punkter overstige den indstillede med 1, hvorefter det vil vende tilbage til den \u00f8nskede v\u00e6rdi.<\/p>\n

\"Veeam
\n
\nBem\u00e6rk, at der ogs\u00e5 kan aktiveres en periodisk fuld backup med den omvendt inkrementale mode (mulighed 4), men det \u00e6ndrer ikke essensen. Ja, der vil komme fulde gendannelsespunkter i k\u00e6den, men vi vil stadigf bare slette de \u00e6ldste punkter \u00e9n ad gangen. <\/p>\n

Endelig n\u00e6rmer vi os den interessante del. Hvis du aktiverer inkrementel backup, men derudover aktiverer mulighederne 3 eller 4 (eller begge p\u00e5 \u00e9n gang), vil opgaven begynde at oprette periodiske fulde backups ved hj\u00e6lp af \"aktiv\" eller syntetisk metode. Metoden til at oprette den fulde backup er ikke vigtig - den vil indeholde de samme data, og den inkrementelle k\u00e6de vil blive opdelt i \"underskaber\". Denne metode kaldes forward incremental, og det er netop den, der giver anledning til en betydelig del af sp\u00f8rgsm\u00e5lene fra vores kunder. <\/p>\n

Retention anvendes her ved at fjerne den \u00e6ldste del af k\u00e6den (fra den fulde backup til inkrementet). Vi vil ikke kun fjerne en tom backup eller kun en del af inkrementerne. Hele \"underk\u00e6den\" fjernes fuldst\u00e6ndigt p\u00e5 \u00e9n gang. Betydningen af indstillingen for antallet af punkter \u00e6ndres \u2013 hvis det i andre metoder er det maksimalt tilladte antal, hvorefter der skal anvendes retention, s\u00e5 definerer denne indstilling det minimale antal. Med andre ord, efter fjernelsen af den \u00e6ldste \"underk\u00e6de\", m\u00e5 antallet af punkter i den tilbagev\u00e6rende del ikke falde under dette minimum. <\/p>\n

Jeg vil fors\u00f8ge at illustrere dette koncept grafisk. Antag, at retention er indstillet til 3 punkter, og opgaven k\u00f8rer hver dag med en fuld backup om mandagen. Retention vil i dette tilf\u00e6lde blive anvendt, n\u00e5r det samlede antal punkter n\u00e5r 10:<\/p>\n

\"Veeam
\n
\nHvorfor 10, n\u00e5r der er indstillet 3? En fuld backup blev oprettet om mandagen. Fra tirsdag til s\u00f8ndag skabte opgaven inkrementer. Endelig, om den f\u00f8lgende mandag, oprettes igen en fuld backup, og kun n\u00e5r der er oprettet 2 inkrementer, kan hele den gamle del af k\u00e6den fjernes, fordi det resterende antal punkter ikke vil falde under de indstillede 3. <\/p>\n

Hvis ideen er klar, s\u00e5 foresl\u00e5r jeg, at du pr\u00f8ver at beregne retention selv. Lad os tage f\u00f8lgende forhold: opgaven k\u00f8rer f\u00f8rste gang p\u00e5 en torsdag (selvf\u00f8lgelig vil der blive lavet en fuld backup). Opgaven er indstillet til at lave en fuld backup om onsdagen og s\u00f8ndagen og opbevare 8 gendannelsespunkter. Hvorn\u00e5r vil retention blive anvendt f\u00f8rste gang?<\/p>\n

For at besvare dette sp\u00f8rgsm\u00e5l anbefaler jeg, at du tager et stykke papir, tegner det op efter ugedage og skriver ned, hvilket punkt der oprettes hver dag. Svaret vil v\u00e6re \u00e5benlyst.<\/p>\n

Svar<\/b>
\n \"Veeam
\nForklaring: For at besvare sp\u00f8rgsm\u00e5let er det nok at sp\u00f8rge sig selv \"hvorn\u00e5r vil retention blive anvendt\"? Svaret er \u2013 n\u00e5r vi kan fjerne de f\u00f8rste 3 punkter (VBK, VIB, VIB) og den resterende k\u00e6de ikke falder under de 8 punkter. Det bliver klart, at vi kan g\u00f8re det, n\u00e5r vi har i alt 11 punkter, dvs. om s\u00f8ndagen i den anden uge. <\/p>\n

Nogle l\u00e6sere kan indvende: \"hvorfor alt dette, hvis der er 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

Endelig har vi ikke sagt noget om muligheden \"Transform previous backup chains into rollbacks\" (markeret med nummer 5). Denne mulighed forvirrer nogle gange kunder, der aktiverer den \"automatisk\" i \u00f8nsket om blot at inkludere en syntetisk backup. Men denne mulighed aktiverer en helt s\u00e6rlig backup-tilstand. Uden at dykke ned i detaljerne vil jeg hurtigt sige, at i denne fase af produktets udvikling er \"Transform previous backup chains into rollbacks\" en for\u00e6ldet mulighed, og jeg kan ikke komme i tanke om et eneste scenarie, hvor den burde anvendes. Dens v\u00e6rdi er s\u00e5 tvivlsom, at Anton Gostev for nogle tid siden efterlyste eksempler p\u00e5 dens nyttige anvendelse via forumet (hvis du har eksempler, s\u00e5 skriv i kommentarerne, det interesserer mig meget). Hvis der ikke findes s\u00e5danne (jeg tror, der ikke g\u00f8r), vil muligheden blive fjernet i de n\u00e6ste versioner. <\/p>\n

Opgaven vil skabe inkrementer (VIB) indtil den dag, hvor den syntetiske fulde backup er planlagt. P\u00e5 denne dag oprettes der faktisk en VBK, men alle punkter f\u00f8r denne VBK transformeres til rollbacks (VRB). Herefter vil opgaven forts\u00e6tte med at skabe inkrementer til den fulde backup indtil den n\u00e6ste syntetiske backup. Som resultat skabes der en blanding af VBK, VBR og VIB-filer i k\u00e6den. Retentionen anvendes meget enkelt - ved at slette den seneste VBR:<\/p>\n

\"Veeam
\n<\/p>\n

Problemer<\/h3>\n

\nUdover selve forst\u00e5elsen af, hvordan det fungerer, er de fleste problemer, der opst\u00e5r ved brug af inkremental tilstand, normalt relateret til den fulde backup. En regelm\u00e6ssig fuld backup er n\u00f8dvendig for denne tilstand, ellers vil opbevaringsstedet samle punkter, indtil det er fyldt. <\/p>\n

For eksempel kan den fulde backup blive oprettet for sj\u00e6ldent. Lad os sige, at opgaven er indstillet til at opbevare 10 punkter, men en fuld backup oprettes en gang om m\u00e5neden. Det er klart, at det faktiske antal punkter her vil v\u00e6re betydeligt st\u00f8rre end det indstillede. Eller opgaven er i det hele taget sat til at k\u00f8re i en uendeligt inkrementel tilstand og opbevare 50 punkter. S\u00e5 skaber nogen ved et uheld en fuld backup. S\u00e5dan, nu vil opgaven vente, indtil den fulde punkt har samlet 49 inkrementer, hvorefter den anvender retention og vender tilbage til den uendelige fulde tilstand.<\/p>\n

I andre tilf\u00e6lde er den fulde backup indstillet til at blive udf\u00f8rt regelm\u00e6ssigt, men af en eller anden grund sker det ikke. Jeg vil her beskrive den mest popul\u00e6re \u00e5rsag. Nogle kunder foretr\u00e6kker at bruge indstillingen 'run after' og indstille opgaver til at arbejde i en k\u00e6de. Lad os tage dette eksempel: der er 3 opgaver, der k\u00f8rer hver dag og skaber en fuld backup om s\u00f8ndagen. Den f\u00f8rste opgave starter kl. 22.30, og de andre starter i r\u00e6kkef\u00f8lge. Den inkrementelle backup tager 10 minutter, og derfor er alle opgaver afsluttet senest kl. 23.00. Men den fulde backup tager en time, s\u00e5 om s\u00f8ndagen sker f\u00f8lgende: den f\u00f8rste opgave k\u00f8rer fra 22.30 til 23.30. Den n\u00e6ste fra 23.30 til 00.30. Og den tredje opgave starter f\u00f8rst om mandagen. Den fulde backup er planlagt til s\u00f8ndag, s\u00e5 i dette tilf\u00e6lde vil den simpelthen ikke blive udf\u00f8rt. Opgaven vil vente p\u00e5, at den fulde backup anvendes for at kunne anvende retention. S\u00e5 v\u00e6r opm\u00e6rksom ved brug af indstillingen 'run after' eller undg\u00e5 helt at bruge den \u2013 indstil blot opgaverne til at starte samtidig og lad ressourcestyringsv\u00e6rkt\u00f8jet g\u00f8re sit arbejde. <\/p>\n

Den komplekse mulighed 'Remove deleted items'<\/h2>\n

\nVed at g\u00e5 ind under opgaveindstillingerne Storage \u2013 Advanced \u2013 Maintenance kan man finde muligheden 'remove deleted items data after', m\u00e5lt i dage. <\/p>\n

\"Veeam
\n
\nNogle kunder forventer, at dette er retention. Faktisk er det en helt separat mulighed, hvis misforst\u00e5else kan f\u00f8re til uventede konsekvenser. F\u00f8rst og fremmest er det n\u00f8dvendigt at forklare, hvordan B&R reagerer i situationer, hvor kun et par maskiner sikkerhedskopieres succesfuldt i l\u00f8bet af sessionen. <\/p>\n

Lad os forestille os et scenarie: en uendeligt inkrementel opgave, der er indstillet til at gemme 6 punkter. Opgaven har 2 maskiner, den ene sikkerhedskopieres altid succesfuldt, den anden giver nogle gange fejl. Som resultat, ved den syvende punkt, er situationen s\u00e5dan her:<\/p>\n

\"Veeam
\n
\nTid til at anvende retention, men den ene maskine har 7 punkter, mens den anden kun har 4. Vil retentionen blive anvendt her? Svaret er ja, det vil den. Hvis blot \u00e9n objekt er blevet sikkerhedskopieret, anser B&R det for at punktet er oprettet. <\/p>\n

En lignende situation kan opst\u00e5, hvis en maskine simpelthen ikke blev inkluderet i opgaven under en bestemt session. Dette sker for eksempel, n\u00e5r maskiner tilf\u00f8jes til opgaven ikke individuelt, men som en del af containere (mapper, lagre), og en given maskine midlertidigt migrerer til en anden container. I s\u00e5danne tilf\u00e6lde vil opgaven blive betragtet som succesfuld, men i statistikken vil du finde en meddelelse, der opfordrer til at v\u00e6re opm\u00e6rksom p\u00e5, at den p\u00e5g\u00e6ldende maskine ikke l\u00e6ngere behandles af opgaven. <\/p>\n

\"Veeam
\n
\nHvad sker der, hvis man ignorerer dette? I tilf\u00e6lde af uendeligt inkrementelle eller tilbageg\u00e5ende inkrementelle tilstande vil antallet af gendannelsespunkter for den \"problematiske\" maskine falde med hver session, indtil det n\u00e5r 1, som er gemt i VBK. Med andre ord, selvom maskinen ikke bliver sikkerhedskopieret i lang tid, vil der stadig v\u00e6re \u00e9t gendannelsespunkt tilbage. Situationen er anderledes, hvis der er inkluderet periodiske fulde sikkerhedskopier. Hvis man ignorerer signalerne fra B&R, kan det ende med, at det sidste punkt bliver slettet sammen med den gamle del af k\u00e6den. <\/p>\n

N\u00e5r disse detaljer er forst\u00e5et, kan man endelig se p\u00e5 muligheden \"Fjern data for slettede genstande efter\". Den vil slette alle punkter for en bestemt maskine, hvis denne maskine ikke bliver sikkerhedskopieret i l\u00f8bet af X dage. V\u00e6r opm\u00e6rksom p\u00e5, at denne indstilling ikke reagerer p\u00e5 fejl (fors\u00f8gt \u2013 det lykkedes ikke). Der b\u00f8r ikke engang v\u00e6re et fors\u00f8g p\u00e5 at tage backup af maskinen. Det virker tilsyneladende som en nyttig mulighed, og den b\u00f8r altid v\u00e6re t\u00e6ndt. Hvis en administrator har slettet maskinen fra opgaven, er det logisk at rydde op i un\u00f8dvendige data og k\u00e6den efter et stykke tid. Men indstillingen kr\u00e6ver disciplin og opm\u00e6rksomhed.<\/p>\n

Jeg vil give et praktisk eksempel: i opgaven blev der tilf\u00f8jet flere containere, hvis sammens\u00e6tning var ret dynamisk. P\u00e5 grund af mangel p\u00e5 RAM havde B&R serveren problemer, som forblev uopdaget. Opgaven blev startet og fors\u00f8gte at tage backup af maskinerne, undtagen en, som p\u00e5 det tidspunkt ikke var til stede i containeren. Da mange maskiner gav fejl, skulle B&R som standard g\u00f8re 3 ekstra fors\u00f8g p\u00e5 at tage backup af de \"problematiske\" maskiner. P\u00e5 grund af konstante problemer med RAM, strakte disse fors\u00f8g sig over flere dage. Der blev ikke gjort noget fors\u00f8g p\u00e5 at tage backup af den manglende VM (manglen p\u00e5 VM er ikke en fejl). I sidste ende, under et af de gentagne fors\u00f8g, blev betingelsen \u201cFjern slettede elementer\u201d udf\u00f8rt, og alle punkter fra maskinen blev slettet. <\/p>\n

P\u00e5 dette punkt kan jeg sige f\u00f8lgende: hvis du har indstillet notifikationer for opgave resultater, og endnu bedre - bruger integration med Veeam ONE, s\u00e5 vil du sandsynligvis ikke opleve dette. Hvis du derimod tjekker B&R serveren en gang om ugen for at sikre, at alt fungerer, s\u00e5 er det bedre at undg\u00e5 de muligheder, der potentielt kan f\u00f8re til sletning af back-ups. <\/p>\n

Hvad er blevet tilf\u00f8jet i v.10<\/h2>\n

\nDet, vi talte om tidligere, har eksisteret i B&R i mange versioner. Efter at have forst\u00e5et disse arbejdsprincipper, lad os nu se p\u00e5, hvad der er blevet tilf\u00f8jet i den jubil\u00e6ums \"tiende\" version. <\/p>\n

Daglig opbevaring<\/h3>\n

\nVi har tidligere set p\u00e5 den \"klassiske\" opbevaringspolitik, der er baseret p\u00e5 antal punkter. En alternativ tilgang er at indstille \u201cdage\u201d i stedet for \u201cgendannelsespunkter\u201d i samme menu. <\/p>\n

\"Veeam
\n
\nIdeen er tydelig fra navnet - retention vil opbevare det fastsatte antal dage, mens antallet af punkter hver dag ikke har nogen betydning. Det skal dog bem\u00e6rkes:<\/p>\n