För några veckor sedan släppte Veeam sin senaste inkarnation av Availability Suite, det vill säga Veeam Backup & Replication och Veeam ONE. Under ytan har en lång rad förbättringar gjorts. Bland annat har vi äntligen fått tillgång till en stand-alone console med resultatet att man numer kan vara flera administratörer inloggade mot Veeam servern, tidigare var vi begränsade till antalet RDS sessioner servern kunde hantera (och oftast var begränsningen 2 samtidiga administratörer för i ärlighetens namn: vem vill lägga på RDS CAL licenser på en backup server?).
En hel del nya funktioner och förbättringar ligger nära att komma in på min topp 3-lista men när inte riktigt hela vägen fram. För att bara nämna några exempel: On-Demand Sandbox for Storage Snapshots, Direct NFS Access, Explorer for Oracle, Active Full för Backup Copy jobs, Parallell hantering av VMs i Backup Copy jobs, VM Tags backup och restore.
Men för att återkomma till rubriken på denna post, vilka är då mina favoriter?
1. Per-VM backup files
Tidigare sparades samtliga VMs som ingick i ett backupjobb i en och samma backupfil, vbkfil, oavsett hur många VMs som valts. Problemet med detta är att resurserna inte används optimalt och backupen tar längre tid än vad som kanske är möjligt.
Med funktionen per-VM backup files påslagen så kommer istället fler skrivströmmar kunna hanteras om hårdvaran tillåter det. Om Backup Repositoryt kan hantera flera strömmar så bör man se kortare backuptider som resultat.
Då man skriver till enskilda Backup repository vinner man möjligtvis en del i prestanda och tid men om man dessutom kombinerar per-VM backupfiler med Scale-Out Backup Repositories så kan man avsevärt öka hastigheten. Mer om Scale-Out Backup Repositories under punkt 2 i min lista.
Det är lätt att förledas tro att per-VM är en inställning man gör på själva backupjobben men de ändras de facto på våra Backup Repositories direkt. Rekommendationen är att slå på funktionen om man använder sig av deduplicating storage appliance som stödjer fler skrivströmma. Per-VM funktionen är som standard påslaget på Scale-Out Backup Repositories men går självklart att enabla även på vanliga Backup Repository.
För att per-VM backup ska fungera så måste man se till att man inte har ställt in någon begränsning i backupjobbet över hur många samtidiga uppgifter som kan hanteras (”Limit maximum concurrent tasks to:”) för att det ska fungera optimalt.
2. Scale-Out Backup Repository
När disken du sparar dina backupfiler på, ditt Backup Repository, börjar ta slut blir det en hel del manuellt arbete för att lägga till mer disk, skapa nya repositories, kanske flytta backup-filerna, ändra target i backupjobben osv. En hel del arbete alltså. Det är här Scale-Out Backup Repository (SOBR hädanefter) kommer in. När man skapar ett SOBR så agerar det som en virtuell mottagare av backupjobb, i ett SOBR så har man flera ”normala” Backup Repositories tillagda – ju fler desto bättre. Man kan blanda olika typer av Backup Repositories i samma SOBR: Windows Backup Repositories, Linux Backup Repositories, Shared folders, Deduplicating storage appliance. Undantaget är Cloud repositories. När ett Backup Repository lagts till i ett SOBR kallas det därefter ett extent. Samtliga extents i ett SOBR bör finnas inom samma site.
När man flyttar in ett Backup Repository, som används av befintliga backupjobb, i ett SOBR så ändras automatiskt backupjobbens target. Man behöver alltså inte gå in i varje backupjobb och ändra target, ganska smidigt! När man väl lagt till ett Backup Repository i ett SOBR så kan man inte längre använda det som ett stand-alone repository.
Det finns några typer av jobb som inte kan använda ett SOBR: Configuration backup job, Replication job, VM copy jobs, Endpoint backup jobs.
Varje Backup Repository man lägger till kan taggas med vilken typ av backupfiler den ska hantera: Fulla backupfiler, inkrementella filer eller båda.
Syftet med detta är att öka upp prestandan där man kan sprida ut lasten över flera olika diskmiljöer. Dessutom finns 2 olika policys man kan ange på ett SOBR. ”Data locality” innebär att alla filer som tillhör en specifik backupkedja (både full- och inkrementella backupfiler) samlas på samma extent. ”Performance” separerar fulla- och inkrementella backupfiler på olika extents.
Ett exempel: Man använder policyn “Performance” och har 2 extents, med 100 GB respektive 200 GB ledigt utrymme, i sitt SOBR. Båda extenten kan hantera både fulla och inkrementella filer. När ett backupjobb kör så kommer Veeam Backup & Replication att välja ut vilket extent som ska användas på följande sätt:
- Vid första körningen kontrolleras vilka extents det finns tillräckligt mycket ledigt utrymme på. Kan båda extenten husera den fulla backupfilen så väljs det extent med mest ledigt utrymme: 200 GBs extentet alltså.
- När sedan nästa backup startar, ett inkrementellt jobb, så kontrolleras var den inkrementella filen kan placeras. Om båda extenten kan hantera inkrementella filer så väljs den extent som INTE hanterar den fulla backupfilen – den med 100 GB ledigt alltså.
I början av varje backupjobb gör Veeam Backup & Replication en grov estimering av det lediga utrymmet som behövs för att lagra backupfilen:
- Storleken på en full backupfil är lika med 50% av den ursprungliga VM:n
- Storleken på av inkrementell backupfil är lika med 10% av den ursprungliga VM:n
Med många extents i ett SOBR finns alltid risken att ett extent försvinner av någon anledning (trasig disk exempelvis), men man har möjlighet att ange en policy som tvingar en ny full backup om någon extent som innehåller filer i backupkedjan saknas – ”Perform full backup when required extent is offline”.
Eftersom ett SOBR kan, och bör, innehålla flera extents så kan det finnas tillfälle då enskilda extents behöver ändras eller hanteras på något sätt. Den underliggande disken kan vara trasig eller man vill kanske sluta använda ett specifikt extent. Då finns det några service funktioner att tillgå:
- Maintenance Mode – När ett extent är i maintenance mode har den begränsad funktionalitet:
- Veeam Backup & Replication startar inte nya jobb där extentet används.
- Du kan inte återställa VM data från backupfiler som ligger på det extentet. Du kan inte heller återställa VM data från backupfiler på andra extents om delar av backupkedjan ligger på extentet i maintenance mode.
Om det finns pågående jobb mot extentet sätts det i maintenance mode först när jobbet är klart.
Kan användas exempelvis vid trasig disk eller om man behöver uppgradera servern som hanterar Backup Repositoryt/extentet
- Backup Files Evacuation – Om man vill ta bort ett extent från ett SOBR måste man först evakuera (flytta) backupfilerna från extentet. Då man evakuerar ett extent så flyttar Veeam Backup & Replication backupfilerna till ett annat extent inom samma SOBR. Backupkedjan bibehålles och man kan använda dem som vanligt. Om inte extentet är satt i maintenance mode före man evakuerar filerna så avbryts jobbet.
Veeams marknadsavdelning har fått bestämma och det officiella namnet är därför ”Unlimited Scale-Out Backup Repository”. Som instruktör för Veeams VMCE kurser så vet jag att detta kommer att ifrågasättas, så jag ställde frågan till Veeam ”Vad är den tekniska begränsningen för hur många extents man kan ha i ett SOBR?”. Svaret jag fick får mig att tro att inte många kunder någonsin kommer ens i närheten av att nå taket:
”Every Scale-Out Backup Repository extent has a UUID. We use a 128 bit UUID, which means we are “limited” to 2^128 extents. That is a lot of extents!”
Funktionen Scale-Out Backup Repository är inte tillgängligt alla licenser utan finns i Enterprise och Enterprise plus licenserna.
Enteprise licensen är begränsad till 1 SOBR med max 3 stycken extents. Det finns inga begränsningar i Enterprise plus licensen.
3. Bitlooker
Nästa funktion som är riktigt bra är bitlooker. Tänk dig att du har en VM som har en 100 GB disk, du kopierar in massor med filer och fyller disken. Därefter tar du bort 50 GB av filerna. I operativsystemet har du nu 50 GB ledigt utrymme, däremot så innehåller blocken på disk fortfarande information även om de är ”raderade”, så kallade dirty bits.
När Veeam Backup & Replication i tidigare versioner har tagit backup av den virtuella maskinen så har man inte vetat om det är ”vanliga” bits eller dirty bits vilket inneburit att alla block som innehåller information har sparats vilket resulterar i att 100 GB backas istället för 50 GB. I version 9 har man nu gjort det möjligt att kryssa i en ruta (Exclude deleted file blocks) under advanced-fliken på backupjobbet.
Exclude deleted file blocks är ingen universallösning för samtliga operativsystem i hela världen, funktionen är specifikt för Windows operativsystem och NTFS filsystem.
Det är Backup Proxy som tar hand om att identifiera och sortera bort dirty blocks när data skickas över till Backup Repositoryt.
Men det slutar inte där, vi kan numer minska ytterligare på vad som backas upp – genom exkludering av filer och/eller kataloger. Kravet för att aktivera denna funktion är dels att den virtuella maskinen använder Windows NTFS filsystem och att Application-Aware processing är enablat på jobbet. Därefter specificerar man vilka enskilda filer, filtyper eller kataloger som ska undantas från backup. Man kan även använda sig av ”Environment Variables” exempelvis %TEMP%.
Man kan lägga till flera olika exkluderingar exempelvis:
C:\report.*;*.pst;%TEMP%
Att lägga till exluderingar kan påverka backuptiden, mer arbete för proxyn innebär förmodligen att det ta längre tid med backupen.
Detta är min topplista, vilka är dina favoriter?
You must be logged in to post a comment.