Is Bitlooker from Veeam a game-changer?

Disclaimer: This is not a performance comparison or test in any way, shape or form, it is merely my experience in a lab environment supposed to show an indicative relative difference in performance at a high level. OK, you get the picture?

So as you may know Veeam introduced a new feature in version 9 of Backup & Replication and I thought it would be fun to see if there were any actual benefits of using the feature called ”Bitlooker” by doing some basic tests. The goal of my test was to see if there were any differences in running backup jobs with or without backing up dirty blocks (i.e blocks that contains data but has been marked as deleted and thus the blocks can be reused by the operating system) which is the actual functionality of Bitlooker. My starting position was that logically it makes sense of course that it would be more efficient in a lot of ways using Bitlooker but I wanted to see if it was quantifiable: difference in speed and/or backup file size – again at a high level. And as an extended test I also wanted to see if there was any notable difference between using Bitlooker and SDelete (a tool from Sysinternals that you run inside the guest OS to clean up dirty blocks by writing zeros to those blocks).

Description of the Test environment
A Veeam Backup & Replication environment was set up, using simple deployment (all services on a single VM). A virtual machine running Windows Server 2012 was set up as the VM to be backed up running on a vSphere 5.5 host. Anyone familiar with the VMCE lab environment, that’s basically what I was using with and extended drive on on one of the domain controllers. The domain controller was assigned a 200 GB thin disk. I filled the disk with 190 GB worth of data, deleted 160 GB of data and then went ahead with some comparison tests. To describe what actually happens inside the OS at this point, only pointers to blocks containing information is deleted not the actual data on the blocks themselves which means that the OS will know the actual consumption on disk but for an outside observer (vSphere and Veeam for instance) it makes no difference: a block containing data is a block containing data.

Since I’m running the tests on my brand new toy, a Gen 6 Intel NUC which is not an enterprise server, I’m not that interested in the actual performance figures but rather the relative difference between the different test scenarios – all else equal. Oh, but there’s just one thing: Bitlooker only works with Windows and NTFS filesystem.

I initially performed some tests on a 40 GB VM but felt that, even though I saw some great improvements, I couldn’t draw any actual conclusions based on them.

I quickly realized – ”We’re gonna need a bigger boat!” and went for the 200 GB drive instead.

Since I already had performed some initial tests on my 40 GB environment the relevant scenarios at this point started at Test 8. All backup jobs were set up to take active full backup of the VM:

Test 8: A 200 GB vmdk where approx 40 GB was consumed. Basic backup test without Bitlooker enabled.

23 - Test 8 - Veeam GUI

24 - Test 8 - filesize

The resulting vbk-files from the 200 GB vmdk containing 40 GB of data is 12 GB in size.

Test 9: A lot of files were added to the VM, roughly 150 GB worth of data. Now the total consumed size of the disk is 191 GB. Again a basic backup test without Bitlooker enabled.

25 - Volume size pre-deletion of files

26 - VMDK size pre-deletion of files

A quick look shows the vmdk to be 200 GB in size.

27 - Test 9 - Veeam GUI

28 - Test 9 - filesize

With compression and deduplication the vbk-file ends up 95 GB in size.

Test 10: Now the fun begins, 163 GB of data was deleted and backup runs without Bitlooker.

29 - Size of files to be deleted

30 - VMDK size post deletion

Even though the files inside the OS has been deleted, the actual vmdk-file size doesn’t change and that’s expected behaviour from a thin disk. And it wouldn’t change even if you made a storage vMotion.

31 - Test 10 - Veeam GUI

32 - Test 10 - file size

This is  where it starts getting interesting, the vbk-file size is still the same size as we saw in the previous test: 95 GB! By logic it should be smaller since we’ve deleted 163 GB of data but clearly from the outside it doesn’t matter – a block is a block is a block.

Test 11: This is where we put Bitlooker to the test, same scenario as Test 10 but Bitlooker has been enabled on the backup job. That’s the only difference, a tick in a box.

33 - Test 11 - Veeam GUI

One big thing to highlight on the picture above is time spent backing up the virtual machine, 6 minutes compared almost 36 minutes in ”Test 10”. That’s a huge difference, and the end result will still contain the exact same active data from the VM.

34 - Test 11 - filesize

Massive reduction, we’re now seeing vbk-sizes similar to the first initial backup test in ”Test 8”.

Test 12: So let’s see if all types of ”zeroing”-techniques are equal. We’re now using SDelete to do it’s job on the C-drive zeroing out all deleted blocks and the backup job runs without Bitlooker.

35 - C drive zapped with SDelete

36 - Test 12 - Veeam GUI

It performs faster than ”Test 10” but slower than ”Test 11”, that’s interesting! I wasn’t really expecting such a big difference I must admit.

37 - Test 12 - filesize

The backup file size is identical as ”Test 10” though, and that was expected.

Test 13: So for fun let’s enable Bitlooker on the job, so SDelete and Bitlooker in conjunction.

38 - Test 13 - Veeam GUI

Bitsocker comes in to play again reducing the backup time to 6 minutes.

39 - Test 13 - filesize

No change in backup file size, that was expected. So there’s no benefit what so ever in this scenario of using SDelete.

Test 14 – Extra test: Since there was such a difference between ”Test 12” and ”Test 13” let’s verify the behaviour by disabling Bitlooker and run the job again. This should mean more time spent on the backup, right?

40 - Test 12 verification - Veeam GUI

Yep, we’re back again pushing past 23 minutes for the job.

41 - Test 12 verification - filesize

Backup file size doesn’t change.

Conclusion
Reducing the amount of data to backup from your virtual machines has always been a good thing, how ever historically it has been a manual or at least semi-manual task to accomplish, running SDelete.exe or some eqvivalent tool for instance. Perhaps running as a scheduled task but nonetheless it had to run on the VM itself and would require time and valuable CPU and I/O resoruces in the process. It was also prone to human ”error” since someone had to actual run the command or set up a schedule for it – meaning it might be forgotten or missed setting up new VMs. It’s worth mentioning that SDelete is a few years old and that there are other tools available you can use, one of which is a fling from VMware called GuestReclaim but I couldn’t use it in this case since it doesn’t work under Windows Server 2012.

Bitlooker changes the game completely, you literally only have to tick a box on a backupjob to make use of it! Faster backup times and smaller backup files, are there any drawbacks? Well yes and no, if you’re a windows shop go nuts with it but if you’re running any other OS you simply won’t be able to use Bitlooker.

Bitlooker is a great new feature from Veeam, not only does it reduce storage space required to hold your backup files but it also reduces backup time significantly for your active full backups (to be clear it will also make a difference on your incremental backups). As I already mentioned the tests were done on a tiny lab environment but it can still act as an eye-opener in terms of
relative difference with or without bitlooker enabled. Your own milage may vary, but you will see improvements. I tested 1 VM just for fun but I bet you have a lot more VMs, do you think you will save time? I’m sure of it!

”So what about cost? How much do I need to fork out for this great new feature you speak of?” I hear you say. That’s almost the best part: Nothing! You don’t need to pay anything! As long as you have a valid license and support contract you can just upgrade, it’s included in version 9 of Backup & Replication and for all editions: Standard, Enterprise and Enterprise Plus. For all new jobs created it’s even enabled by default and it can easily be enabled on your existing jobs – just tick the box. Thank you Veeam!

I would recommend enabling this feature on all your backups if you haven’t done so already. Period.

So ending with answering my question in the subject: Yes! It really is.

Därför är backup ointressant!

Rubriken är kanske lite provokativ och till viss del missvisande. Mitt syfte med detta blogginlägg är inte att förringa eller förkasta behovet av en fungerande backup. Säkerhetskopiering av data har även fortsättningsvis i högsta grad en viktig roll i ett datacenter men när man talar om backup så är det inte backupen i sig som de facto är viktig utan det är återställning som är det intressanta! Det är vad som verkligen betyder nåt.

Det finns mängder av tillverkare som gör mer eller mindre bra backupprogram, det som skiljer är hur man återställer data. Den som jag vill lyfta fram i sammanhanget som en av de verkligt kompetenta backup/återställningsprogrammen är Veeam Backup & Replication. Produkten är inriktad uteslutande mot virtuella miljöer – det vill säga den är ämnad att backa upp Microsoft Hyper-v eller VMware vSphere/vCloud miljöer och inget annat.

Så varför är då backup ointressant? Jo, de allra flesta backupprogram kan göra en hyfsad backup av virtuella maskiner och allt ser ut att vara OK, loggar visar att backupen har genomförts enligt schema och resultatet var lyckat. Där Veeam Backup & Replication sticker ut är just förmågan att se till att när du behöver återställa så kan du faktiskt lita på att det som ser ut att vara OK i loggar faktiskt också kan användas när du behöver dem som mest.

Ur ett backuphänseende är steg ett att när backupen väl är genomförd som måste vi säkerställa att den faktiskt är intakt och möjlig att använda i framtiden vid behov. I Veeam Backup & Replication finns en funktion för att säkerställa att den backup vi precis gjort är användbar, funktionen heter SureBackup och har flera olika sätt att verifiera de virtuella maskinerna. Med SureBackup startas virtuella maskiner upp direkt ifrån de komprimerade backupfilerna, det vill säga man behöver inte återställa en virtuella maskin till ett datastore först – vi öppnar den virtuella maskinens vmdk-/vhd(x)-filer direkt ifrån en komprimerad/deduplicerad backupfil. Veeam använder något de kallar för vPower för att åstadkomma detta. Vad man mer kan nyttja vPower till kan du läsa om här.

(Bild saknas)

När man startat upp den virtuella maskinen från backupdisken så kan man utföra tester mot den för att verifiera att den fungerar, vi kan kontrollera att den virtuella maskinen fungerar med hjälp av VMware Tools inbyggda funktion heartbeat som skickar ”jag lever”-signaler till hosten, därefter kan man göra en ping-test för att säkerställa att den är nåbar via nätverket. Därefter kan man kontrollera att specifika tjänster är igång i den virtuella maskinen, exempelvis kontrollerar man att man får svar på port 25 om det är en mailserver man verifierar. Som ett sista steg kan man till och med verifiera varenda block som skrivits till backupdisken, en CRC check.

Dessa tester genomförs automatiskt via ett speciellt jobb om man önskar, ingen manuell inblandning behövs. Eftersom det är produktions VMs som testas så skapar man ett virtuellt lab som är avskiljt från produktionsmiljön för att ta bort risken att man påverkar produktionsmiljön med exempelvis dubbla IP-adresser eller FQDN. Så när dagen kommer då du behöver återställa en virtuell maskin så vet du att den fungerar. Och självklart förändras inte backupfilerna när dessa testar utförs, backupfilerna är intakta och oförändrade.

(Bild saknas)

Steg 2 är alltså då vi faktiskt behöver återställa en virtuell maskin. Här skiner också Veeam Backup & Replication starkare än solen, när krisen är ett faktum så handlar det om att återställa själva funktionen den virtuella maskinen tillhandahåller så fort som möjligt. En annan funktion vi har tillgänglig tack vare vPower är möjlighet till att starta virtuella maskiner direkt via funktionen Instant VM Recovery från backupfilen på backupdisken.

Vad är betydelse för detta? Jo, vi behöver inte först återställa vmdk-filen (som ju kan väldigt stor, kanske till och med flera TB stor) till den primära lagringsmiljön som kan ta väldigt lång tid. Med hjälp av Instant VM Recovery och vPower kan vi se till att användarna kommer åt funktionen inom loppet av några få minuter. På sikt vill man förmodligen flytta över den virtuella maskinen till den primära lagringsmiljön, det kan man göra exempelvis med hjälp av Storage vMotion och då krävs ingen ytterligare nertid för funktionen. Saknar men licenser eller möjlighet för Storage vMotion kan man med kortare nertid (tidsmässigt ungefär som en omstart av den virtuella maskinen) flytta funktionen med hjälp av Veeams funktion Quick Migration.

Naturligtvis går det även att återställa hela den virtuella maskinen direkt till den primära lagringsmiljön om man vill. Med hjälp av densamma backupjobb kan man inte bara återställa hela virtuella maskiner, man kan återställa enskilda filer inuti den virtuella maskinen, man kan till och med återställa enskilda objekt för applikationer inuti en virtuell maskin exempelvis Exchange eller Active Directory via speciella guider som hjälper till att förenkla processen – en funktionen som kallas Application Item Recovery.

Så för att summera, backup är extremt viktigt fortfarande men magin uppstår då man behöver använda den: Verifierat, enkelt, snabbt…. Varje gång.

Vill du veta mer om hur Veeam Backup & Replication fungerar? Kontakta oss!
Viridis IT är Guld partner med Veeam och har dessutom en av Sveriges få officiella Veeam Instruktörer.

Veeam lanserar återställningshjälp för Active Directory och SQL

Veeam har via produkten Backup & Replication redan idag 2 stycken wizard-drivna hjälpmedel för att väldigt enkelt kunna återställa objekt till Micorsoft Exchange eller Sharepoint. Man behöver inte sätta upp eller konfigurerar någon komplex återställningsmiljö utan man kan direkt från backupfilerna återställa enskilda objekt rakt in i produktionsmiljön om man vill, om man inte kan eller har möjlighet att återställa direkt till produktionsmiljön på grund av interna policies eller liknande i miljön kan man istället plocka ut mail och vidarebefordra dom i ett nytt mail alternativt exportera dom till en pst-fil. Denna möjlighet finns alltså redan idag för Veeam Backup & Replication 7.0.

I version 8, som lanseras inom kort, introducerar Veeam nu samma koncept som ovan fast för Active Directory och SQL objekt. Återställning av objekt från Microsoft Active Directory görs via en Explorer där man enkelt kan leta upp rätt objekt.

(Bild saknas)

Man har alltså möjlighet att omedelbart återställla enstaka Active Directory objekt, hela kataloger, OU, användarkonto och maskin lösenord. Om du någonsin oavsiktligt råkat ta bort ett servicekonto eller behöver ändra lösenord på alla servrar som använder det kontot så vet du hur omständigt det är. Veeam Explorer for Microsoft Active Directory gör det enkelt!

Om man istället vill återställa Microsoft SQL objekt ser det ut så här istället:

(Bild saknas)

Långsam FLR med Veeam Backup & Replication 7?

Veeam Backup & Replication kan förutom backup och återställning av hela virtuella maskiner även återställa enstaka filer eller File Level Restore, FLR, som man även kallar det. En kund till oss råkade ut för ett problem där man behövde återställa en del kataloger och filer på deras filserver. Ett perfekt tillfälle att nyttja funktionen File Level Restore. Efter en stund gick dock återställningen ner i hastighet markant, dessutom fortsatte hastigheten att sjunka succesivt. Då den avbröts var överföringshastigheten nere i 44KB/s.

I scenarier där man återställer kataloger med stora mängder filer kan detta vara ett problem, även om det var planlagt att lösa detta problem i version 7 av Veeam Backup & Replication så ställer det uppenbarligen fortfarande till problem i vissa miljöer.

Hur kommer man runt detta problem om man behöver återställa sina filer snabbt? Jo, börja med att mappa upp destinationen du ska återställa till från Veeam Backupservern. Mappa upp en enhetsbokstav till \\<Min stora filserver>\d$ (eller den enhetsbokstav som är önskvärd i sammanhanget) därefter går man i Veeam Backup Browsern och väljer ut den katalogen man vill återtälla, högerklickar på den och istället för att välja ”Restore” väljer man ”CopyTo” och pekar ut ovanstående enhetsbokstav istället. Återställningen ska då genomföras med bibehållen hastighet genom hela jobbet.

Veeam Backup & Replication v7 – Frågor & Svar

För ett tag sedan gjorde Veeam sin senaste inkarnation av sitt backupverktyg, Backup & Replication, tillgängligt för nedladdning/användning. Veeam Backup & Replication har många olika användningsområde för att säkerställa din virtuella miljö – oavsett om den är baserad på VMware vSphere eller Microsoft Hyper-v. Verktyget kan bland annat ta backup av dina virtuella maskiner till disk eller tape, replikera virtuella maskiner mellan olika hostar/siter, verifiera att backupen faktiskt lyckats genom att starta upp virtuella maskiner från backup.

(Bild saknas)

Det finns en hel del frågeställningar, av olika natur, som kan vara berättigade i sammanhanget. Här nedan går vi igenom några av dom.

Licenser

F: Hur licensieras produkten?

S: Per fysisk CPU socket på ”ursprungs-hosten” (där de virtuella maskinerna du vill skydda finns). Mål-hosten, dit du säkerhetskopierar/replikerar virtuella maskiner, behöver inte licenseras. Hostar som hanterar virtuella maskiner som inte säkerhetskopieras behöver heller inte licensieras, inte ens om de är med i samma kluster.

F: Är licensen kopplad till hur många kärnor CPU:n har?

S: Nej, priset är samma oavsett hur många kärnor CPU:n har. Licens priser baserad på CPU kärnor försvann med den nya licensmodellen som började gälla 1 juli 2013.

F: Är några av komponenterna licensierade separat? Exempelvis Enterprise Manager, backup servrar, backup proxy servrar, backup repositories, WAN acceleratorer, tape libraries.

S: Nej, de är inte licensierad separat. Du kan installera så många av de komponenterna som är relevanta för din miljö.

F: Hur håller man reda på licensierade sockets på olika hypervisors (vSphere eller Hyper-v), är det en gemensam pool?

S: Nej, varje hypervisor har sin egen socket beräkning i licensfilen

F: Är det olika priser per socket beroende på vilken hypervisor man använder?

S: Nej, det är samma pris oavsett hypervisor

F: Kan jag byta mina licensierade sockets från en hypervisor till en annan?

S: Ja, du kan göra det närsomhelst genom att kontakta din säljkontakt. Bytet är tillgängligt kostnadsfritt. Som en del i processen kommer du även att få en temporär licensnyckel vilket innebär att båda dina hypervisor miljöer är licensierade parallellt på samma backup server. Licensen är kostnadsfri, giltig i 3 månader och kan förlängas vid behov (dock endast för stora miljöer). Teknisk support inkluderas även kostnadsfritt under tiden den temporära licensen är giltig.

F: Kan jag installera flera v7 backupservrar på flera siter och använda samma licensfil?

S: Du kan installera hur många backupservrar du vill med samma licensfil så länge den faktiska socket användningen över alla backupservrar inte överstiger det licensierad antalet. För att säkerställa efterföljelse rekommenderar vi att ni använder Veeam Backup Enterprise Manager som tillhandahåller central licenshantering. Enterprise Manager rapporterar det faktiska antalet sockets som används över alla backup servrar och kan dessutom användas för att lägga till den nya v7 licensfilen till alla anslutna backup servrar.

F: Kan jag bland olika produkt editioner i samma miljö?

S: Nej, det måste vara samma license edition

F: När exakt räknas host sockets av mot poolen av licenser?

S: När första backup-, replikerings- eller kopieringsjobbet körs på en host

F: Jag har tagit bort någon host från min miljö, kan jag få tillbaka licensen till min licenspool?

S: Ja, öppna license management rutan i huvudfönstret, välj host och klick på Revoke

Uppgradering: Licenser

F: Jag är en befintlig kund som kör version 6.x. Behöver jag en ny licensfil för att installera v7?

S: Ja, du behöver tillgång till en ny licensfil för version 7.x. Din nuvarande licensfil kommer inte att fungera.

F: Är v7 en kostnadsfri uppgradering från äldre versioner?

S: Alla uppgraderingar från Veeam är kostnadsfria förutsatt att du har giltigt underhållsavtal. Alla nya licenser inkluderar 1 års underhållsavtal. Om du köpte Backup & Replication för mer än 1 år sedan men förlängde inte underhållsavtalet behöver hantera detta via din säljkontakt för att köpa till nytt underhållsavtal, inklusive tiden du saknat avtal.

F: Jag är en nuvarande kund med underhållsavtal, hur får jag tag i den nya licensfilen för v7?

S: Använd License Management Portal på nedladdningssida för produkten (under My Account) för att få den nya licensfilen, eller maila till licensing@veeam.com för hjälp. Om du väljer att maila så svarstiderna var lite längre i samband med att nya produkter har gjorts tillgängliga.

F: Vilken v7 produkt edition får jag när jag uppgraderar från version 6.x?

S: Samma produkt edition som du använder idag med v6 (Standard eller Enterprise). Ytterligare så kan alla Enterprise-edition kunder som hade aktivt underhållsavtal per den 1:a juli 2013 begära en kostnadsfri uppgradering till Enterprise Plus. Den kostnadsfria uppgraderingen måste begäras senast 1 november. Uppgradering av licensen till Enterprise Plus kommer att innebära ökade kostnader för underhållsavtal med början vid nästa förlängningstillfälle då dessa beräknas på licensens listpris.

F: Vad är skillnaden på funktioner mellan Standard, Enterprise och Enterprise Plus editionerna? Är det några nya skillnader jämfört med version 6?

S: Inga befintliga funktioner har tagits bort från någon av editionerna. De allra flesta nya funktionerna är tillgängliga redan i Standard edition. Några få nya funktioner är tillgängliga endast i Enterprise eller Enterprise Plus editionerna. Vänligen kontrollera Veeam Backup & Replication Edition Comparison dokumentet som finns på produkt sidan under Resources-fliken på Veeam hemsida.

Uppgradering: Teknisk

F: Behöver jag göra en ren installation eller kan jag uppgradera min befintliga Backup & Replication miljö till version 7?

S: Veeam supporterar in-place uppgraderingar från version 6.0, 6.1 eller 6.5 (oavsett patchnivå). Om du använder äldre versioner vänligen kontakta Veeams support för instruktioner och hjälp med en uppgradering.

F: Hur uppgraderar jag till version 7.0?

S: Uppgraderingsprocessen är väldigt enkel och rättfram. Se till att det inte finns några aktiva backup- eller återställningsjobb och kör sedan installationsprogrammet för version 7 på din backupserver. Då installationen är slutförd, starta Backup & Replication och följ instruktionerna i Upgrade Wizard så uppgraderas alla kvarvarande komponenter automatiskt. För en mer detaljerad steg-för-steg anvisning, läs igenom Upgrade sektionen i Release Notes dokumentet.

F: Kommer mina jobb och inställningar att bibehållas vid en uppgradering?

S: Ja, alla dina jobb och inställningar kommer att bevaras. Detta betyder också att några nya funktioner (parallell processing, nya kompressions nivåer) inte kommer att användas som standard, du måste manuellt aktivera dessa funktioner om så önskas. Detta för att säkerställa att produkten uppträder på samma sätt även efter en uppgradering.

F: Vilken Backup & Replication version kan jag uppgradera till version 7.0?

S: Du måste köra version 6.0, 6.1 eller 6.5 (oavsett patch nivå)

F: Stödjer version 7.0 av backup servern både 32-bitars och 64-bitars OS?

S: Version 7.0 backup server stödjer endast 64-bitars OS. Om din 6.x backupserver kör 32-bitars OS måste denna migreras till 64-bitars OS innan en uppgradering görs. Du kan använda verktyget för konfigurations backup (finns tillgängligt version 6.5) för att enkelt migrera dina 6.5 backup servrar till den nya hosten innan en uppgradering genomförs.

F: Supporterar version 7.0 backup proxies och backup repositories både 32- och 64-bits OS?

S: Ja, i betydelsen att du kan låta dina backup proxies och backup repositories intakta. Men Veeam rekommenderar att använda 64-bitars servrar för backup repositories då dessa supporterar större backupstorlekar.

F: Kan version 7.0 och tidigare versioner vara installerade på samma server?

S: Nej, men man kan däremot använda olika versioner parallellt på skilda server och ända behandla samma virtuella maskiner utan problem (så länge jobben inte överlappar). Det är så de flesta kunder väljer att göra Proof of Concept vid nya versioner innan man uppgraderar produktionsmiljön.

F: Kan Enterprise Manager 7.0 hämta data från Veeam Backup & Replication 6.x servrar?

S: Ja

F: Kan jag återställa backuper gjorda med en tidigare version än 7.0?

S: Ja, version 7.0 kan återställa backuper gjorda med alla version av Veeam Backup & Replication med start från version 1.0

Systemkrav

F: Vad är systemkraven och supporterade konfigurationer för de olika komponenterna och för skyddade virtuella maskinerna?

S: Detta finns i System Requirements sektionen i Release Notes dokumentet som finns tillgänglig på Veeams nedladdningssida och på Product sidan under Resources fliken. Utöver detta så finns plattformsspecifika FAQ:er för mer specifik information

F: Är Veeam Backup & Replication supporterat att köra i en virtuell maskin?

S: Ja

F: Är Veeam Backup & Replication tillgängligt som en linux-baserad virtuell appliance?

S: Nej, Veeam Backup & Replication måste installeras på Microsoft Windows.

F: Vilka fördelar finns att använda 64-bitars OS för Backup & Replication komponenter som supporterar både 32- och 64-bitars OS?

S: För backup repositories stödjer 64-bitar OS mycket större backupfiler. Det finns ingen fördel att köra backup proxies med 64-bitas OS i dagsläget, däremot kommer VMware vSphere 5.5 support kräva 64-bitars backup proxy servrar.