My top 5 features of Veeam Availability Suite 9.5

5. Direct restore to Azure
Restore backup from any Veeam backup product to Microsoft Azure: From Backup & Replication, Backup Free edition or Endpoint backup free.
P2V or V2V? Not a problem! This means VMs from any hypervisor or physical machines, even VMs running in any cloud where you can install Endpoint Backup Free or Windows/Linux agents from Veeam are eligible to restore. And it doesn’t matter if you’re running Windows or Linux.

4. Enhanced VMware vCloud Director support for service providers
Let your cloud tenants use native vCloud authentication to access the new self-service backup and restore portal in Enterprise manager. Let them use predefined backup jobs to protect their vApps and restore VMs, vApps or guest files.

3. Proxy affinity
With proxy affinity you can control what proxy servers are allowed to use specific repositories. It’s an easier way with less administration – no need to select individual proxy servers in each and every backup job (if needed) to keep backup traffic local to the site.

2. Cloud Connect for service providers
There are a few functions added to Cloud Connect providers that are not new per se but introduced to Cloud Connect in version 9.5. Such as:
Per-VM backup file chains support
Scale-out Backup repository support
Advanced ReFS integration support

1. Advanced ReFS Integration
Hands down my favorite new function is the ReFS integration. This is a fantastic technology from Microsoft and the integration Veeam made with it in Backup & Replication 9.5 is nothing short of a amazing. Fast clone and spaceless full backup, sounds good right? Who needs dedupe storage anyway? And no need to worry (?) about data integrity with the use of integrity streams that is storage-level corruption guard on steriods.

My top 5 features of VMware vSphere 6.5

5. VMware vCenter High Availability

Since many functions are relying on vCenter being present and available, making the vCenter Server itself highly available is crucial for large scale deployments. In the past there’s been a few solutions that tried to handle this but now it’s already built in when you fire up your server. If you’re using the vCenter Server Appliance you have the ability to configure it to run in a high availability fashion using ”vCenter High Availability”. Now, I need to emphasize, this is exclusively for the vCenter Server Appliance and not for the windows version of vCenter. You get an active node, a passive node and a witness node that makes the vCenter Server availabile by a click of a button. Simple.

4. vSphere Update Manager

Not really a new thing but since vCenter 6.5, vSphere Update Manager is now available for the vCenter Server Appliance as well – making a separate server unnecessary. Finally!

3. VMware PowerCLI

I’m a huge fan of automating and quite frankly PowerCli has to be on the list based on that fact alone, but there are some significant improvements to the different modules. A big leap forward in terms of automation.

2. Virtual Machine Encryption

For the security conscious people out there, this should be a huge deal. The ability to encrypt virtual machines from the outside means it’s independent of the OS inside and also that it’s storage agnostic.

1. Enhancements for Nested ESXi

I do a lot of demos and testing in lab environments I really appreciate the improvements made for nested environments. There has been a fling available for some time that basically reduced the traffic and load on the individual hosts through a MAC learning algorithm. It has now been integrated in the full release of vSphere 6.5. This results in significant performance improvement in nested ESXi environments with vSphere 6.5.

And a honorable mention goes to vSAN 6.5 with improvements such as iSCSI support for physical workloads, 2 node direct connect for the small deployments and of course PowerCLI cmdlets support for vSAN.

Windows 2016 ReFS as a Veeam backup repository?

Do we really need dedupe storage for our long term backups? Well, dedupe storage certainly has it’s merits in the toolbox when you design your backup environment. But we do need to be aware of some of the drawbacks with dedupe, for instance performance for random I/O and rehydration of data if doing synthetic full backups. However, there’s been a great disturbance in the Force as of recently.

Microsoft made a huge release earlier this year with the ”2016”-suite, I thought it’d be a good idea to go through how to set up a server to be used as a repository for Veeam Backup & replication 9.5 and show some of the results. More specifically, let’s use the amazing Resilient File System (ReFS) v3 found in Windows Server 2016.

Windows Server 2016 can be installed in two modes, with or without a GUI. Now, if no GUI is installed you can use powershell to do the configuration but for simplicity we’re going to use the GUI which is called ”Desktop experience” in the installer.

So boot your server from the dvd/iso and select Windows Server 2016 (Desktop Experience) of your flavor.

Desktop Experience

In the next step, select ”Custom: Install windows only (advanced)”

Install

Select the drive to install Windows on:

C drive

Now the installation will start copying files to the drive and commence the installation of Windows.

Start installation

Click on Tools and select Computer Management in the server manager window:

Computer management

Open up the Disk management tool, this is where you find the attached drives on the server. In my case I have one drive where I installed windows and two additional drives. I’ll make some benchmarks later so I’m going to format one drive with ReFS and the other one with NTFS for comparison, but first let’s get them online:

Disk online

Then initialize the disks:

Initialize disk

Next up, we create a new simple volume on one of the disks:

Simple kolumn

Select file system and give the volume a name:

ReFS volume

Next disk we format with NTFS instead:

100

The result looks like this:

110

So let’s test it out and see if there’s any noticeable difference when using these as target for our backups.

I’ve created a folder on each of the disks and made two Veeam Backup Repositories, I’ve created two jobs backing up the same VM running Windows Server 2016(with different targets) and set up synthetic full backup, this is where Windows ReFS should really shine if you believe the hype.

Backup jobs

When the backup has run a few iterations it was time for the Synthetic Full backup using the NTFS backup repository as target:

NTFS Usage

So with NTFS, a full backup, a few incremental backups and at the end a Synthetic full backup used roughly 12 GB of disk space. Good deduplication and compression and not a lot of changes in the VM of course. But what about the ReFS repository?

Usage ReFS

Same backup intervall with a Synthetic full backup at the end generated roughly 7 GB go disk usage, pretty significant reduction in usage if you ask me. Now disk usage is when of the key features on why to use ReFS with it’s ”spaceless full backup technology” but there’s another benefit the has the same groundbreaking impact: Time.

Time it takes to make the full backup. Let’s take a look at the time it took to create the synthetic full backup on the NTFS repo.

NTFS synthetic full4 minutes and 15 seconds is not the bad for my VM, but imagine it being dozens of VMs…How does the ReFS repo compare then?

ReFS synthetic full11 seconds! Must be a typo? NO, it’s really not. Quite impressive. Now you might rethink the dedupe storage approach, you have all the space savings (almost) of the dedupe storage but performance of a traditional disk with no need to rehydrate data.

If you want to make it highly resilient you can leverage another Microsoft technology called Storage Spaces Direct where you’d get fault tolerance and ”auto-healing” as well.

A fantastic job from Microsoft with ReFS/Storage Spaces Direct and Veeam with the integration of the technology into Backup & Replication!

Veeam, PowerShell and SAN snapshot

So a week or so ago I wrote a post about using PowerShell to add snapshots to a SAN found in Veeam Backup & Replication. It was a quick test to see if it worked, now I’ve slightly improved the script.

The Get-HP4* cmdlets is specifically for HPE StoreVirtual VSA/P4000/LeftHand line. If you have another supported SAN Storage system use the correct cmdlets:

NetAPP Storage Systems
HPE 3Par StoreServ Storage Systems
HPE StoreVirtual Storage Systems
EMC VNX Storage Systems

You can accomplish the same thing using the management tool for the SAN, taking recurring snapshots. But in the case of HPE StoreVirtual it’s a licensed feature and it can only occur every 30 minutes so if you need it more often or you’re lacking the license you can use the PowerShell script instead.

Add-PSSnapin VeeamPSSnapIn -ErrorAction SilentlyContinue

$source_storage = ‘Veeam-VSA-MGMTG’
$source_cluster = ‘veeam-vsa-cluster’
$source_vol_name = ‘datastore1’
$snapshot_name = ‘Oh_snap_’+(Get-Date -Format MMddhhmm)

#Create a new snapshot
try {
‘Trying:’
$getvolume = (Get-HP4Storage -Name $source_storage | Get-HP4cluster -Name $source_cluster | Get-HP4Volume -name $source_vol_name)
‘getvolume-Name: ‘ + $getvolume.Name
‘getvolume-InternalId: ‘ + $getvolume.InternalId
‘getvolume-IsThin: ‘ + $getvolume.IsThinProvision
‘getvolume-Size: ‘ + $getvolume.Size

$getvolume | Add-HP4Snapshot -name $snapshot_name
} catch {
‘Failed to find storage, cluster or datastore’
‘Unable to create snapshot’
break
}

#Remove the oldest snapshot if more than 4 are available
$getsnapshot = ($getvolume | Get-HP4Snapshot | Where-Object {$_.Name -like ‘Oh_snap_*’})
$snapshot_count = @($getsnapshot).Count

if ($snapshot_count -ge 4) {
$getsnapshot | Sort-Object creationtimeutc | Select-Object -First 1 | Remove-HP4Snapshot
}

Populate your Veeam lab with PowerShell

If you, like me, have the need to constantly rebuild a lab environment where the servers are installed already but it lacks any configuration you probably realized that PowerShell is you friend. I have a lab environment that I tear down and build up again really often using templates in my VMware environment. In this environment I have all the infrastructure components installed but not configured in Veeam Backup & Replication so whenever I want to show-and-tell I first need to configure stuff. It might take a while to do, so why not automate with PowerShell?

The script below adds a few managed servers, adds backup proxies, creates a Scale-Out Backup Repository with 2 extents, adds 2 WAN accelerators. On top of that it adds a Tape proxy, connects to a HP VSA and takes a snapshot.

Add-PSSnapin VeeamPSSnapIn -ErrorAction SilentlyContinue

$Infra_Administrator = "Domain1\Administrator"
$Infra_Password = 'Password1'
$Lab_Administrator = "Domain2\Administrator"
$Lab_Password = 'Password2'
$ESXi_root = "root"
$ESXi_Password = 'Password3'
$Oracle_User = "oracle"
$Oracle_Password = 'Password4'
$HPE_User = 'HpeUser'
$HPE_Password = 'Password5'
$VBRserver = Get-VBRServer -Name "VEEAM-VBR.domain1.local"

Add-VBRCredentials -Type Windows -User $Infra_Administrator -Password $Infra_Password -Description $Infra_Administrator
Add-VBRCredentials -Type Windows -User $Lab_Administrator -Password $Lab_Password -Description $Lab_Administrator
Add-VBRCredentials -Type Linux -User $Oracle_User -Password $Oracle_Password -SshPort 23 -ElevateToRoot -AddToSudoers -RootPassword $Oracle_Password -Description "oracle"

#Add servers as ”managed servers”
Add-VBRESXi –Name "VEEAM-ESX" -user root -password 'Password3'
Add-VBRWinServer -Name "VEEAM-HYPERV" -credentials $Infra_Administrator
Add-VBRWinServer -Name "VEEAM-Remote" -credentials $Infra_Administrator
Add-VBRHvHost -Name "VEEAM-HYPERV" -credentials $Infra_Administrator

#Remove/Add proxy with 1 concurrent task limit
Get-VBRViProxy -Name "VMware Backup Proxy" | Remove-VBRViProxy -Confirm
Add-VBRViProxy -Server $VBRserver -Description "VMware Backup Proxy" -MaxTasks 1

#Add Backup Repositories and Scale-Out Backup Repository
Add-VBRBackupRepository -Server $VBRserver -Name "Remote Repository" -Folder "X:\Backups" -Type WinLocal -MaxConcurrentJobs 4 -Credentials $Infra_Administrator
Add-VBRBackupRepository -Name "Local Backup Repository" -Server $VBRserver -Folder "E:\Backups" -Type WinLocal -MountServer $VBRserver -VPowerNFSFolder "C:\ProgramData\Veeam\Backup\NfsDatastore" -MaxConcurrentJobs 4 -Credentials $Infra_Administrator
Set-VBRConfigurationBackupJob -Repository "Remote Repository"
Add-VBRScaleOutBackupRepository -Name "Main Backup Repository" –PolicyType DataLocality –Extent “Default Backup Repository”, “Local Backup Repository”

#Add WAN accelerators
Add-VBRWANAccelerator -Server "VEEAM-Remote" -Description "Remote WAN Accelerator" -CachePath "X:\VeeamWAN" -CacheSize 10 -CacheSizeUnit GB
Get-VBRLocalhost | Add-VBRWANAccelerator -Description "Local WAN Accelerator" -CachePath "X:\VeeamWAN" -CacheSize 10 -CacheSizeUnit GB

#Add a Virtual Lab and Application group
$VLABhost = Get-VBRServer -Type ESXi
$VLABdatastore = Find-VBRViDatastore -Name "datastore1" -Server $VLABhost
Add-VSBVirtualLab -Name "VEEAM-ESX VLAB1" -Server $VLABhost -Datastore $VLABdatastore

Find-VBRViEntity -Name "VEEAM-DC01", "VEEAM-EX01" | Add-VSBViApplicationGroup -Name "Exchange"

#Add SAN and Tape and make a snapshot on the SAN
Add-HP4Storage -DnsOrIpAddress "10.20.30.40" -User $HPE_User -Password $HPE_Password -Description "HPE Storage"
Get-VBRServer -Name "VEEAM-Remote" | Add-VBRTapeServer
Get-HP4Volume -name "datastore1" | Add-HP4Snapshot -name "datastore1_SS_1"

Veeam and PowerShell: A perfect match!

I read a really good and useful blog post a while ago from Preben Berg from Veeam describing how to use PowerShell to restore a database from backup to a dev environment. This made me think on another scenario that would be fun to script that might come in handy someday.

What if you have a SAN that you would want do snapshots on once an hour and save some of those historical snapshots rotating the oldest one.

Now for the disclaimer part, this is merely meant to showcase how you might accomplish this. There are no safety features built in. Do not use it in production and use it at your own risk. However if you’d like to do some further testing of your own, you can download a virtual SAN from HP – free of charge up to 1 TB. Nice!

First things first. We need to create a PowerShell script.

Let’s define which volume to use:
$source_vol_name = "datastore1"

Then we add a naming convention to use for the snapshots with a timestamp at the end:
$snapshot_name = "Oh_snap_"+(Get-Date -Format MMddhhmm)

Let’s count how many snapshots exist on the volume:
$snapshot_count = @(Get-HP4Volume -name $source_vol_name | Get-HP4Snapshot).Count

Now let’s create a snapshot:
$snapshot_create_session = Get-HP4Volume -name $source_vol_name | Add-HP4Snapshot -name $snapshot_name -description "Automated snapshot"

I would like to save the 4 latest snapshots on the volume and delete the oldest:
if ($snapshot_count -ge 4 {
$snapshot_remove_session = Get-HP4Volume -name $source_vol_name | Get-HP4Snapshot | Sort-Object creationtimeutc | Select-Object -First 1 | Remove-HP4Snapshot
}

If I would leave out ”Get-HP4Volume -name $source_vol_name”  in the above statement then I would delete to oldest snapshot available on any of the volumes (not just datastore1) which is not our intent.

Let’s put it all together:

Add-PSSnapin VeeamPSSnapIn -ErrorAction SilentlyContinue

$source_vol_name = ”datastore1”
$snapshot_name = ”Oh_snap_”+(Get-Date -Format MMddhhmm)
$snapshot_count = @(Get-HP4Volume -name $source_vol_name | Get-HP4Snapshot).Count

$snapshot_create_session = Get-HP4Volume -name $source_vol_name | Add-HP4Snapshot -name $snapshot_name -description ”Automated snapshot”

if ($snapshot_count -ge 4 {
$snapshot_remove_session = Get-HP4Volume -name $source_vol_name | Get-HP4Snapshot | Sort-Object creationtimeutc | Select-Object -First 1 | Remove-HP4Snapshot
}

That’s all, just a few lines of code and we can accomplish cool things.

Then all we have to do is add the script as a scheduled task on the VBR server and run it once an hour or what ever intervall we’d like.

But let’s see how the infrastructure looks prior to running the script:

1. SAN datastores

 

Open Task Scheduler and create a new task:

2. Create scheduled task

 

Let’s configure it to run once an hour starting at 10 PM:

3. Run at 1 hour intervall

 

We add and action, starting the PowerShell script:

4. Add PowerShell script to run

 

Looks ok once it’s added:

5. Scheduled task has been added

 

First time the script ran a snapshot was created as expected:

6. First run of the script

 

(I changed the script to run every 5 minutes to speed up the process), now we have 4 snapshots:

7. 4 initial snaps

 

When the fifth snapshot has been taken the oldest snapshot is deleted (the snapshot created at 10:07 PM in the previous picture):

8. 4 snaps rolling

 

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.

Mina topp 3 favoriter i Veeam Backup & Replication v9

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.

Per-vm single write stream
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.
Per-vm multi write stream
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.

Enable Per-vm backup files
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.

Edit Scale-Out Repository
Varje Backup Repository man lägger till kan taggas med vilken typ av backupfiler den ska hantera: Fulla backupfiler, inkrementella filer eller båda.

Extent settings
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.

SOBR Policy
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:

  1. 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å.
  2. 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”.

2. Perform full backup

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.

3. Exclude deleted files
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.

3. Bitlooker zeroing ou
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%.

3. Exclude folder
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?

VMworld 2015 – dag 2

Sitter och funderar på gårdagen, många intryck med det som står ut mest är faktiskt en liten men revolutionerande tech preview – vMotion från eget till vCloud Air (VMwares molnlösning). Kan bara summanfattas som: wow, fantastiskt!

Men, det går inte att hålla sig kvar i gårdagen. Idag är en ny dag men fler nyheter att presentera. Bland annat presenterade Saanjay Poonen deras stora End User Computing (EUC) lansering för dagen. Deliver any app to any device, riktigt imponerande. IDC har i sin undersökning för 2015 om Virtual Client Computing Software market placerat VMware i ledareposition framför andra spelare som Citrix och Microsoft. Men det verkar som en både Microsoft och VMware har förstått att kunderna vill ha samarbete företagen emellan, Jim Alkove Corporate Vice President for Enterprise and Security på Microsoft stod på scen idag. VMwares scen. Smaka på det en stund. En bra och tydlig signal.

Windows 10 kan enkelt manageras via VMware Airwatch tillsammans med App Volumes. Både virtuellt och fysiskt.

Ett genomgående tema på dagens presentation är att en grundläggande plattform  är NSX, VMwares nätverksvirtualisering. Det är tack vara att detta hanteras via mjukvara som man kan få säkerhet och konfiguration att fungera. En grundpelare helt enkelt. I går annonserades den senaste versionen av NSX 6.2.

En kommentar som sades i en av kundfilmerna var riktigt passande angående konkurrens mellan företag: It’s no longer the big beating the small, it’s the fast beating the slow.

Pat Gelsinger höll hov i dagens keynote, han talade mycket om hur omvärlden förändras och hur  vi under de kommande 10 åren kommer påverkas. En mycket bra presentations som verkligen gav intryck.

VMworld 2015 – dag 1

Hektisk dag med mycket på agendan men massor av matnyttig information. Redan första sessionen visade sig vara väldigt intressant – Connecting the dots from vCenter Server to vCloud Air. Unified Hybrid Cloud är dagens nya slagord. Idag lanseras vCloud Air Hybrid Cloud Manager som en gratis produkt för managering och integrering av vCloud och vCenter Server, installationen görs i vCenter Web Client.

Årets tema för VMword är ”Ready for any”, det syftar bland annat på att alla applikationer oavsett typ, cloud-native eller legacy enterprise, så är VMwares plattform det bästa valet. One cloud, Any Device, Any application.

VMwares vision är att vi ska ha ett moln, inte i betydelsen ett enda faktisk moln utan ett eller flera moln som sömlöst fungerar mellan on-premise, off-premise (publika moln), managerat moln.

Termen molnlösning har historisk varit förknippat med datacenter och server, nu vill VMware ändra på begreppet och skifta fokus mot applikationer. Framtiden för applikationer är inte längre molnbaserade eller on-premise, framtiden är Hybrid applications enligt VMware. Känslig information i ditt eget datacenter och de skalbara delarna i molnet med alla fördela som finns där.

En av de funktioner som fångade mitt intresse och gjort VMware till den enterprise spelare som man är idag var vMotion, möjligheten att flytta en virtuell maskin från en host till en annan utan avbrott. Fortfarande magiskt att se det i praktiken mer än 10 år senare. Idag visade man en tech preview på vMotion mellan private cloud och vCloud Air! Nästan vansinnigt, flytta dina interna virtuella maskiner till ett publikt moln utan nertid!!

Några av de nyheter som presenterades idag:

  • EVO SDDC manager – förlängningen av EVO:Rail
  • vCloud Air Hybrid Cloud Manager
  • vSphere Integrated containers
  • Photon platform
  • vMotion cross-cloud (on-premise till vCloud Air) – tech preview