Monthly Archives: January 2018

NSX Bytes: NSX 6.4 UI Enhancements and Upgrade Coordinator

NSX-v 6.4 was released a couple of weeks ago and as I talked about in my launch post, there are a lot of new features and enhancements that make this release significant. A big focus for this release was around enhancing NSX’s ease of use and serviceability. There have been a number of additions to the UI with additional dashboards and menu items. Also importantly, a first port of the NSX Web Client functionality over the to HTML5 Web Client.

What’s interesting about the approach that the NSX product team has taken is that they have decided to have each new feature in the HTML5 Web Client accessible from the old Flash based Web Client as well. They have also continued to improve on the layout and usability of the flash based vSphere Web Client so what you have now is a combination of Flash and HTML5 inside the old Web Client as well as a limited pure HTML5 NSX experience in the new Web Client.

UI Enhancements:

Among the enhancements to the UI is the improvement in the navigation menu where some commonly used menu items that where clicks away have been brought into the main tree. As you can see below there is a lot more happening in the 6.4 menu tree on the right vs the previous releases on the left.

The HTML5 menu is a little shorter with only a couple of items added however it shows you what it will look like when the porting is complete. Also shown in the picture below is the new System Scale Dashboard that provides visibility into the current usage of various NSX components and system capacity relative to configuration maximums with warning thresholds configurable.

Highlighting the Flash+HTML cross over in the Flash Web Client, the System Scale Dashboard is also present in the old Web Client and shown below.

In terms of other UI additions there is now an EAM status monitor in the Host Preparation Tab and a direct way from the Web Client to generate Support Bundle…which again, is available from both Web Clients.

NSX Upgrade Coordinator:

Probably one of the coolest features in NSX-v 6.4 is the Upgrade Coordinator.

When you upgrade using Upgrade Coordinator, you can select to perform a One Click Upgrade, where everything is upgraded during one upgrade session. Or you can select to Plan Your Upgrade, and customize which components are upgraded, and organize component objects into upgrade groups.

Working you way through the wizard you can select which components to upgrade.

For me have control of the NSX Edge upgrades is super important as this has historically been a monotonous task for Service Providers with lots of customer using vCloud Director Edge services. The Upgrade Coordinator streamlines this upgrade task and makes the process a lot more efficient.

Having the ability to group and order the upgrade process for Edges (and Service VMs) is also an excellent enhancement. Once the wizard has been completed you are shown a progress dashboard which you can click into to view the current state of upgrading components.

Once completed, you should have all components upgraded and you can go through the post upgrade tasks and once completed you can always get an overview of the NSX environment by clicking on the main dashboard.

Conclusion:

There is a lot to like about where the NSX team is taking the user interface and it’s good to see an initial move over to the HTML5 Web Client while also having that same functionality still accessible via the Flash Web Client. To have a loot at what is currently supported and what is not in the HTML5 vs Flash Client head to this page and check out the support tables.

I’m looking forward to future updates that will look to push more functionality directly into the HTML5 Web Client.

References:

https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.4/rn/nsx-vsphere-client-65-functionality-support.html

https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.4/com.vmware.nsx.upgrade.doc/GUID-A539869B-9858-48B3-90ED-2336698EE386.html

Veeam Powered Network: Azure and Remote Site Configuration

This week we announced the offical GA of Veeam Recovery to Microsoft Azure featuring Veeam Powered Network (Veeam PN). This new product also features Director Restore to Microsoft Azure in combination with Veeam PN to create a solution that allows you to recover VMs into Azure and then have those VMs accessible on the original network by extending the on-premises network to the Azure networks. From there remote users can also connect into the Azure based Veeam PN Gateway and access services in all connected sites.

I’m going to step through the deployment of Veeam PN from the Azure Marketplace and then extend two remote sites into the Azure Virtual Network created during the initial configuration from the Azure Marketplace. Below is a logical drawing of the extended recovery network.

Components

  • Azure Subscription
  • Veeam PN Azure Marketplace Hub Appliance x 1
  • Veeam PN Site Gateway x 2
  • OpenVPN Client

The OVA is 1.5GB and when deployed the Virtual Machine has the base specifications of 1x vCPU, 1GB of vRAM and a 16GB of storage, which if thin provisioned consumes a tick over 5GB initially.

Networking Requirements

  • Veeam PN Hub Appliance – Incoming Ports TCP/UDP 1194, 6180 and TCP 443
    • Azure Virtual Network Address Space 172.16.0.0/16
  • Veeam PN Site Gateway – Outgoing access to at least TCP/UDP 1194
    • Columbus Address Space 10.0.30.0/24
    • Home Office Address Space 192.168.1.0/24
  • OpenVPN Client – Outgoing access to at least TCP/UDP 6180
Veeam PN Azure Marketplace Deployment:

Once logged into the Azure portal, head to the Azure Marketplace and search for Veeam. You should see Veeam PN for Microsoft Azure.

Click on that that and then click on the Create button at the bottom of the Marketplace description.

From here you are presented with a six step process that configures the Veeam PN Azure VM and allows you to configure networking, initial security and site-to-site and point-to-site settings.

For my deployment location I have chosen Southeast Asia which is in Singapore. The username and password you select here will be used to access the Veeam PN web console and the VM via SSH.

Step 2 includes choose the VM size which I have set from Standard A1 to a Basic A1. The biggest difference from Standard to Basic is the inclusion of a Load Balancer service. One thing to note here is that when considering sizing for any VPN technology CPU and RAM is critical as that becomes the limiting factors in being able to process the encrypted connectivity. We will shortly have an offical sizing guide for Veeam PN but for the purpose of connecting up two sites with some external users the Basic A1 instance will do.

In the image above i’ve also configured the 172.16.0.0/16 Virtual Network. The default that Azure gives you is 10.0.0.0/16 which overlaps with subnets in the Columbus lab which is why I chose another private network range.

The last step shown above is configuring the subnet where the Veeam PN VM will be deployed into. This network can also be used by Direct Restore to Azure to place recovered VMs into.

This next step has you choosing the encryption key size for you VPN connections. We have put in a couple of options and depending on your requirements you can select relatively weak keys to very strong keys. As the note says next to the 2048 key recommendation, this does impact the deployment time as the time to generate higher key sizes. This means that you will need to wait at least 10-15 minutes after deployment to access the Web Console to complete configuration. Setting up the VPN information is straight forward. In my example I have changed the port for the Point-to-Site connections to 6180 as I know this is a commonly opened port in our corporate network. The final steps show you a summary and final confirmation to purchase the Marketplace item. There is no cost involved with Veeam PN its self, but be aware that you will be charged for all Azure resource consumption. Once the job is submitted the deployment creates the Veeam PN VM and injects all the settings specified during this process. Taking a look at the Azure Resources created during the process you can see a number of different components listed.

Ill be putting together another post to dive into a few of those resources to show what is happening under the hood in terms of networking when other sites are added.

Finalising Veeam PN and Azure Configuration:

Once the Veeam PN appliance has been deployed successfully you need to complete a couple more steps to hook the Veeam PN service into Azure to allow the automatic injection of routes. To access the Veeam PN web console you enter in the DNS Name created during the initial setup. To view this after deployment is complete and also see the allocated Public IP click on the publicIP group in the Azure Portal.

If the Azure Marketplace deployment has been successful you we be greeted with an Azure Setup Wizard after logging into the Veeam PN web console.

NOTE: If you don’t get the Azure wizard and get the Out of Box Veeam PN setup prompt you haven’t waited long enough for the encryption keys to generate.

As explained this setup creates an Azure user to have access to the Virtual Network Routing Table. After hitting next you need to authenticate the Veeam PN appliance with Azure by clicking on the link provided and entering in the code to authenticate.

Once completed you can further confirm the setup was successful by clicking on Settings and then look at the Services tab. You should see all three options toggled to On.

Clicking on the Azure Tab will show details of the Azure network and deployment settings.

Veeam PN Site Gateway Deployment and Configuration:

I’ve covered in detail during the RC period of Veeam PN how to setup and deploy site gateways to connect back into the Hub. The Hub doesn’t have to live in Azure and there are use cases for Veeam PN to be used standalone, but lets continue with this setup. I went and configured the two sites as shown below. You can now see their subnet addresses in the web console…another added feature in the GA release.

I’ve also configured the Standalone Client that will enable me to connect from my MBP into the Hub and then get access to the networking resources. One new GA feature that has been added here is the ability to enable all traffic to flow through the Hub server as the default gateway…meaning all traffic will pass through Hub.

At each site a Veeam PN Site Gateway appliance gets deployed and is configured with the generated configuration files done in the steps above. Once connected the Overview page will show all sites connected via the Site-to-Site VPN. As of now, Azure, Columbus and my Home Lab are all part of the one extended network.

Backing Up Veeam PN Config and Version Updates:

For the GA version, we have introduced a couple new UI features based on feedback and usability. The first thing to do once you have finished the initial configuration is to head to the System Tab under Settings and Backup the config. This will download a configuration file that can be imported into a clean Veeam PN appliance if anything happened to the production instance.

There is also a new Updates tab which will Check for Updates and, if available Update to a newer build while retaining the current configuration.

Conclusion:

Once everything is connected and in place we can now restore a VM from anywhere and make it available to the extended networks configured in this example. There are a few more things to cover in regards to making the recovered application available from it’s origin network however I will cover that off in future posts.

Below is a summary what I have shown in this post:

  • Deploy Veeam PN from Azure Marketplace
  • Finalise Azure setup from Veeam PN Web Console
  • Setup Site Configurations
  • Deploy Veeam PN OVA to each site and import site configuration
  • Backup Veeam PN Hub configuration

Those five steps took me less than 30 minutes which also took into consideration the OVA deployments as well…that to me is extremely streamlined, efficient process to achieve what in the past, could have taken hours and certainly would have involved a more complex set of commands and configuration steps. The simplicity of the solution is what makes the solution very attractive…it just works!

Again, Veeam PN is free and is deployable from the Azure Marketplace or downloadable in OVA format directly from the veeam.com site.

Cloud Connect and VAC Portal Maintenance Modes

Lately i’ve been digging deeper into the Veeam Availability Console and have been wrapping my head around it’s extended feature set. With that I thought it would be good to start a series of short blog posts pointing out examples of how certain parts are configured and what is happening under the covers. To kick things off I am going to talk about Maintenance Modes in VAC and also how it translates back to Cloud Connect Maintenance mode and also start off by covering that new Update 3 feature.

Maintenance Mode for Cloud Connect in Backup & Replication 9.5 Update 3

In Backup & Replication 9.5 Update 3 we introduced a Maintenance Mode feature for Cloud Connect. In a nutshell this makes the Service Provider cloud resources unavailable for tenants to perform backup or backup copy job operations. This is true for jobs running on Backup & Replication 9.5 Update 3, Agent for Windows 2.1 and Agent for Linux 2.0.

To enable Maintenance Mode from the VBR console Right Click on the Cloud Connect top level tree item and click on Maintenance Mode

Read the message and click Yes

Once completed you should see the following status in the Cloud Connect menu tree

You can also set and check this state in PowerShell

Once triggered, any running jobs are gracefully stopped. Within that the current task is allowed to complete but all subsequent jobs will fail. In the case of an agent the whole job is allowed to complete. Any new backup or backup copy job that tries to start after Maintenance Mode has been initialed will fail with an error which is shown below.

Tying this into the Veeam Availability Console you can also trigger Maintenance Mode from the VAC UI. To enable maintenance mode for Veeam Cloud Connect, log in to Veeam Availability Console as a Portal Administrator and at the top right corner click Configuration and under Portal Configuration click Cloud Connect Server and click Enable Maintenance Mode.

Click Yes to confirm the operation.

The message isn’t 100% correct based on what I talked about earlier. The current job task will be completed and not dropped as suggested here.

You can disable Maintenance Mode by clicking on the menu option if it’s enabled.

Maintenance Mode for Veeam Availability Portal UI

For those times when you may need to perform configuration changes or OS updates to the system hosting the VAC Portal you have the ability to put the portal its self into maintenance mode. When enabled, all users will not be able to login to the portal remotely and you will see a message on the welcome page as shown below.

To toggle this setting go to the top right of the VAC console and click Configuration and then under Server Settings click on Settings and go to the Maintenance Mode Tab. Set the toggle to on or off to enable or disable and click save.

Once in Maintenance Mode you can only log back into the portal from the local console of the server hosting the VAC UI role. Note that while under Maintenance Mode you can only modify the SQL Server Configuration or toggle Maintenance Mode off.

Conclusion:

I’ve gone through the Maintenance Mode options for both Veeam Availability Console and Cloud Connect and how each one is enabled and what their purpose is. For the moment, in Backup & Replication 9.5 Update 3 the Maintenance Mode is limited to Backup and Backup copy job operations. There are a other operations that are not currently impacted by this mode such as vCloud Director backups or Cloud Connect Replication operations however this will be looked at in upcoming releases.

To read more about Maintenance Mode head to the Veeam Help Documentation page here.

References:

https://helpcenter.veeam.com/docs/backup/cloud/cc_maintenance_mode.html?ver=95

https://helpcenter.veeam.com/docs/vac/enterprise_admin/enable_disable_vac_maintenance_mode.html?ver=20

Released: vCloud Director 9.0.0.2 – Important Networking Fixes!

Last week VMware put out a new point release for vCloud Director 9.0 (Build 7553273) for Service Providers. While there is nothing new in this release there are a significant number of resolved issues as listed in the release notes. One thing to mention is that even though this was released during a similar timeframe to NSX-v 6.4 there is no offical compatibility just yet.

Reading through the list of resolved issues there where some pretty impactful errors that seem to be related mostly to NSX operations and networking in general.

  • Deleting a Provider VDC can corrupt VXLAN network pools that are in use After you delete a Provider VDC, its associated VXLAN network pool becomes unusable by organization VDCs backed by other Provider VDCs.
  • The Redeploy an Edge Gateway from vCloud Director task succeeds instantly but the Edge does not actually redeploy in NSX When you attempt to redeploy an Edge Gateway from vCloud Director, the API initiates a task in vCloud Director and in vCenter Server but does not send a redeploy request to the NSX server. As a consequence, the Edge Gateway does not redeploy.
  • Registration of an NSX Server fails when you supply the credentials of an SSO user vCloud Director SSO users are not authorized to access an NSX endpoint required for registration, so registration fails.
  • Changes on Edge Gateway Services are not synchronized between vCloud Director and NSX When you modify one of the Edge Gateway Services, for example by creating a Static Route, the change is saved on the vCloud Director side but cannot be saved on the NSX server.
  • Creating or updating a firewall rule for an Advanced Gateway Portal with enabling the Show only user-defined rules toggle causes the action of the default firewall rule to change. When you create a new firewall rule or update an existing rule for an Advanced Gateway Portal, if you enable the Show only user-defined rules toggle, the action of the default firewall rule changes incorrectly to match the last modified rule.
  • Deleting an external network that uses a distributed virtual port group with a Private VLAN does not work When you try to delete an external network that is liked to a private VLAN associated with a distributed virtual port group (dvPortgroup), the deletion fails with an InternalError: Only single VLAN or trunk VLAN is supported error message.
  • You cannot add a DNAT rule configuring an original or a translated port or port range through the tenant portal When you attempt to add a DNAT rule from the Edge Gateway screen in the tenant portal, you cannot enter either a port or a port range in the Original Port and the Translated Port text boxes.
  • Creating a SNAT or a DNAT network rule by using a public IP address that is not associated to a particular network interface fails When you try to create a SNAT or a DNAT network rule for either an internal or an external interface in vCloud Director, if the public IP address is not added to a particular network interface, you receive a the following error message:
  • Configuring a static route fails if you set the gateway of an external network as a next hop IP address When you configure a static route for an organization network, if you enter the address of an existing default gateway in the Next Hop IP text box, saving the static route configuration fails with the following error message:

Good to seem them fixing issues quickly but it also tells me that a lot of people participating in the beta for 9.0 didn’t test deep enough against real word scenarios…a lot of what is listed above isn’t what you would consider corner cases. These issues should have bene picked up before going to GA. Possibly also shows that a lot of VCPP Service Providers haven’t upgraded to 9.0 just yet. In any case the vCloud product development team has been hard at work resolving the bugs and Service Providers should be confident deploying or upgrading to 9.0 now.

#LongLivevCD

If you are a vCAN SP and have the right entitlements follow this link to download vCloud Director 9.0.0.2:

References:

https://docs.vmware.com/en/VMware-vCloud-Director-for-Service-Providers/9.0.0.2/rn/rel_notes_vcloud_director_9-0-0-2.html

 

 

NSX-v 6.4.0 Released! What’s in it for Service Providers

This week VMware released NSX-v 6.4.0 (Build 7564187) and with it comes a new UI Plug-in for vSphere Client (HTML5) which includes some new dashboards including a new Update Lifecycle Manager built right into the Web Client. Reading through the release notes, for me the biggest improvements seem to be around NSX Edges and Edge services. These are central to Service Providers who offer NSX services with vCloud Director or otherwise via their service offerings. There are also as usual, a number of Resolved Issues which can be skimmed through in the release notes page.

What’s New:

As mentioned above there is a lot to get through and there are a lot of new enhancements and features packed into this release. I’ve gone through and picked the major ones as they might pertain to Service Providers running NSX on their platforms. I’ve basically followed the sections in the Release Notes but summarised for those that don’t want to troll through the page. Ad the end of each section i’ve commented on the benefits of the improvements.

Security Services

  • Identity Firewall now supports user sessions on remote desktop and application servers (RDSH) sharing a single IP address, new “fast-path” architecture improves processing speed of IDFW rules. Active Directory integration now allows selective synchronization for faster AD updates.
  • Distributed Firewall adds layer-7 application-based context for flow control and micro-segmentation planning.
  • Distributed Firewall rules can now be created as stateless rules at a per DFW section level.
  • Distributed Firewall supports VM IP realization in the hypervisor. This allows users to verify if a particular VM IP is part of a securitygroup/cluster/resourcepool/host.

These security features listed above will make a lot of people happy and improves end user experience and the DFW supporting within the VM is a small but important feature.

NSX User Interface

  • Support for vSphere Client (HTML5): Introduces VMware NSX UI Plug-in for vSphere Client (HTML5).
  • HTML5 Compatibility with vSphere Web Client (Flash): NSX functionality developed in HTML5 (for example, Dashboard) remains compatible with both vSphere Client and vSphere Web Client, offering seamless experience for users who are unable to transition immediately to vSphere Client.
  • Improved Navigation Menu: Reduced number of clicks to access key functionality, such as Grouping Objects, Tags, Exclusion List and System Configuration.

It’s great to see NSX jump over to the HTML5 Web Client and even though it’s a small first step its a great preview of what’s to come in future releases. The fact that it goes both ways, meaning older flash clients still have the features is important as well.

Operations and Troubleshooting

  • Upgrade Coordinator provides a single portal to simplify the planning and execution of an NSX upgrade. Upgrade Coordinator provides a complete system view of all NSX components with current and target versions, upgrade progress meters, one-click or custom upgrade plans and pre- and post-checks.
  • A new improved HTML5 dashboard is available along with many new components. Dashboard is now your default homepage. You can also customize existing system-defined widgets, and can create your own custom widgets through API.
  • New System Scale dashboard collects information about the current system scale and displays the configuration maximums for the supported scale parameters. Warnings and alerts can also be configured when limits are approached or exceeded.
  • A Central CLI for logical switch, logical router and edge distributed firewall reduces troubleshooting time with centralized access to distributed network functions.
  • New Support Bundle tab is available to help you collect the support bundle through UI on a single click. You can now collect the support bundle data for NSX components like NSX Manager, hosts, edges, and controllers.
  • New Packet Capture tab is available to capture packets through UI.
  • Multi-syslog support for up to 5 syslog servers.
  • API improvements including JSON support. NSX now offers the choice or JSON or XML for data formats. XML remains the default for backwards compatibility.

There is a lot going on here but for me it continues to solidify the vision that Martin Casado had around Nicira in it being efficient in software to get a deep view of what’s happened and what’s happening in your network. The System Scale dashboard (shown below) also is a great way to get an understanding of how loaded an NSX environment is…one of my favourite news features.

NSX Edge Enhancements

  • Enhancement to Edge load balancer health check. Three new health check monitors have been added: DNS, LDAP, and SQL.
  • You can now filter routes for redistribution based on LE/GE in prefix length in the destination IP.
  • Support for BGP and static routing over GRE tunnels.
  • NAT64 provides IPv6 to IPv4 translation.
  • Faster failover of edge routing services.
  • Routing events now generate system events in NSX Manager.
  • Improvements to L3 VPN performance and resiliency.

I’ve highlighted this in red because the improvements above continue to build on a very strong foundation that is the NSX Edge Gateway that still continues vShield DNA. Though I’ve been away from the day to day of a service provider for almost a year and a half I recognise that these new features create a more enterprise class of edge device. The little thing added will make network engineers happy.

Conclusion:

Overall this looks like a strong release for NSX-v and good to see that there is still a ton of development going into the platform. Service providers have the most to gain from this release which is a good thing! The only thing that I do hope is that as a 6.x.0 release that it’s stable and without any major bugs…the history of these first major release builds hasn’t been great but hopefully that’s a thing of the past with 6.4.0.

EDIT: Just to clarify after a couple of comments, it seems that for the moment vCD 9.0 and 8.20 is not compatible with NSX-v 6.4.0 just yet. More news when it comes to hand.

Resources:

https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.4/rn/releasenotes_nsx_vsphere_640.html

A Deeper Look at Insider Protection in 9.5 Update 3

With the release of Backup & Replication 9.5 Update 3 we introduced the concept of a Recycle Bin for customers sending offsite cloud backups to VCSPs using Veeam Cloud Connect. This deleted backup protection…or Insider Protection allows the VCSP to enable the deleted backups protection option for specific tenants and looks to add another level of data security for cloud based backups in the case of a malicious user gaining access to the Backup & Replication Console or in the case of accidental deletion by an administrator.

As shown above, this is set by checking a box (Also via PowerShell) in the properties of the tenant account. Once checked the SP will choose the retention period by setting the Keep deleted Backup files for <N> days option. With this option enabled, when a backup or a specific restore point in the backup chain is deleted or aged out from the cloud repository. The actual backup files are not deleted immediately, instead, they are moved to a _RecycleBin folder on the repositories.

Once moved, backup files in the recycle bin do not consume tenant quota however they obviously consume general storage. With that in mind it should be considered by the SP to charge for that used storage. I will release a post shortly detailing some tips on how best to size and charge for the recycle bin storage per client.

At the tenant end those backup files that are moved into the recycle bin are not registered and will not show up in the job information window. They can’t access or do anything with the files in the recycle bin. For the moment if a tenant wants to restore data they must contact the SP to obtain the necessary backup files. Once the retention period has expired all files that fall out of that period are deleted.

Basic Mechanics:

When the option is checked for a tenant a new folder is created under the _RecycleBin\<tenant> folder of the repository. In the case of a Scale Out Backup Repository there is a recycle bin folder created per extent which ensured that any split tenant VM files are processed locally and not between extents.

Once files in the repository start to age out the tenant folder will start to populate with backup files. If there is an event that triggers a change of retention or a VM removed from a job or the deletion of a whole job, any remaining VBK or VIB files in the tenant repository are moved into the recycle bin.

The files remain in the _RecycleBin folder until the retention period has passed or if the service provider moves them out of the folder for recovery purposes.

Working Example:

I have a Cloud Connect Backup account that I am using to back up five VMs that reside on premises, using a standard Backup Job with Forward Incrementals and a Synthetic Full done once a week. I have configured this job to keep two restore points.

I then have configured a secondary destination for the job via a Backup Copy Job to the Cloud Repository and I have set a GFS to happen weekly so I have a full archive offsite. If I hadn’t enabled GFS retention (for those running Update 3) a warning would appear as shown below.

Tip: If the tenant plans to create off-site copies of backed-up data with a backup copy job, it should enable GFS retention settings in the job properties. This way, Veeam Backup & Replication will be able to protect backups created by the job against an attack when a hacker reduces the job’s retention policy and creates a few incremental backups to remove backed-up data from the backup chain.

The Cloud Connect Tenant account has a deleted backup protection setting of 2 days configured as shown in the first image of this post.

Below is the local jobs folder structure:

Looking at the Cloud Connect repository (split over two SOBR extents) you can see that the main repository holds the VM backup files as per the job configuration. Notice the GFS _W files there as well.

Taking a look at the _RecycleBin folder for the tenant after a few days the aged out incremental will start to appear in the folder. Notice that there are no full backup files in the recycle bin at this stage.

Tip: The retention period will look at all backup jobs completed in a 24 hours period and have any expiring or deleted backup files moved into the recycle bin directory. This means that if you are copying up VMs that have a local backup interval of every 4 hours you will have six lots of backup files ageing out daily.

In this example I’m simulating an malicious attack or accidental deletion the VM (TPM03-RMQ-01/VM-120) from the backup. For the sake of this example we are deleting the VM from the Backup & Replication Console under Backups and Cloud. If the Included Archived copies option was chosen then the GFS weekly full backup file is also moved into the recycle bin.

Once the deletion process has been completed the _RecycleBin folder for the tenant will now be populated with the deleted full, plus three incremental files. If the Included Archived copies option was chosen then the GFS weekly full backup file is also moved into the recycle bin.

These will stay in the recycle bin until the retention period is met. From here these files can be transported back to the tenant to be recovered (see here for full process) from within the on-premises Backup & Replication console.

Conclusion:

As shown above, deleted backup protection or Insider Protection is an excellent enhancement to Cloud Connect Backup. It goes some way to having an air gapped backup in the cloud and protects against malicious attacks and rogue or clumsy administrators. There is a lot happening behind the scenes to make it work, however the concept is simple and this features extends the 3-2-1 rule by protecting that offsite copy as part of the Cloud Connect solution. VCSP’s should be looking to offer this as a value add to their clients and Veeam customers should be looking to take advantage of Cloud Connect Backup and Replication for their offsite backup and replication needs.

References:

https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_bin.html?ver=95

https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_bin_restore.html?ver=95

9.5 Update 3 Officially Compatible with VMware Cloud on AWS

At VMworld 2017 Veeam was announced as one of only two foundation Data Protection partners for VMware Cloud on AWS. This functionality was dependant on the release of Veeam Backup & Replication 9.5 Update 3 that contained the enhancements for it to interoperate with VMware Cloud on AWS locked down vCenter.

This week 9.5 Update has been listed on the VMware Compatibility Guide (VCG) for Data Protection.

In terms of what you now get in Update 3, there is little noticeable difference in the process to configure and run backup or replication jobs from within Veeam Backup & Replication. The VMware Cloud on AWS resources are treated as just another cluster so most actions and features of the core platform work as if the cloud based cluster was local or otherwise.

There were a few limitations that VMware have placed on the solution which means that our NFS based features such as Instant VM Recovery, Virtual Labs or Surebackups won’t work at this stage. HotAdd mode is the only supported backup transport mode (which isn’t a bad thing as it’s my preferred transport mode) which talks to a new VDDK library that is part of the VMC platform.

With that the following features work out of the box:

  • Backup with In Guest Processing
  • Restores to original or new locations
  • Backup Copy Jobs
  • Replication
  • Cloud Connect Backup
  • Windows File Level Recovery
  • Veeam Explorers

I’m really excited where VMware takes VMware Cloud on AWS and I see a lot of opportunities for the platform to be used as an availability resource. Over the next couple of months I’m hoping to be able to dive a little more into how Veeam can offer both backup and replication solutions for VMware Cloud on AWS.

Resources:

https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsanps&details=1&partner=594&releases=282&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc

2018

Looking back over the past couple of years I haven’t written a forward looking blog post about the year ahead since 2015 and as I sit here working through my notes on the first workday for 2018 I though that for the good of myself, I should have a think about what I want to achieve out of this year. A lot of people I know and people’s who’s blogs I follow the industry are very big on setting personal goals for the year, but that’s something that I don’t traditionally like doing. It’s not that I don’t have a plan or that I like to randomly see where the year takes me…historically I like things to kinda roll on.

If I think back over the past couple of years…or more specifically since I started working for Veeam I have achieved and ticked off a lot of personal goals. If I think about last year and the opportunities I had. Top of the list was that I delivered a VMworld Breakout Session and be part of a main stage demo in front of two and half thousand people at VeeamON which certainly ticked the boxes in terms of public speaking events.

Beyond that I learnt a lot about working in a Marketing Organization and the behind the scene people engine(s) that keeps a successful software company like Veeam rolling. I learnt how products are positioned, how collateral and content is developed and also how to interact with different areas of the business as products are developed and marketed. Being the Technical end of a Marketing Organization is an interesting place to be and there is a balance that I learnt needed to be had to bridge the gap between the technical and the non-technical.

Travel was something that I didn’t mind doing and as I pointed out in one of my last blog posts from 2017. I adjusted to the travel well, and without question I am looking forward to my travels in 2018. The one thing that did catch me out was the impact that it had on content creation and tinker time. That was a lesson learnt and I am extremely motivated to ensure I work in and around the travel to ensure I pick up my game compared to last year.

I’ve talked a lot in the past about work/life balance and the challenges of working from home and that is something that I am always aware of. Last year the balance was pretty much spot on, so this year I’m hoping that it remains the same…because if that balance isn’t kept everything else could be considered a waste of time!

In terms of what I want to try and achieve this year:

  • Continual Personal and Career Development (don’t rest on the past, continue to push and strive to better myself in every way)
  • Excel at my job and strive to always improve (this helps me, my workmates, customers and the company)
  • Get at least two quality blog posts out a week (not for the sake of it but to create great content)
  • Deep Dive into at least one Technology per month (This is paramount for my job and career)
  • Read at least one book a month (I’ve never been a big reader but need to push myself here)
  • More Home Automation (think this is on everyone’s list but something that I want to do as a hobby)

I’m sure there is more and I am also sure I can be more specific but for the purpose of this exercise I’ll leave it at that list.

As I start to settle into the new year I will be thinking about how I can continue to move forward both professionally…together with my my team as we shift from Marketing to Product Strategy bringing with it new challenges and opportunities to learn new skills and contribute to Veeam’s success…as well as personally as strive to be content about where I am in life with family central to that.

Here is to 2018!

#GoodbyeLament