Category Archives: Service Providers

Veeam Availability Console v3 Important Patch Release

Today, a new patch was released for Veeam Availability Console v3 which brings the build to 3.0.0.2725. Contained in this patch is a number of fixes that covers reporting and licensing, server fixes, agent fixes and there are also a number of other resolved issues including some RESTful API fixes as well as for those using the ConnectWise Plugin. The patch is advised to be deployed to all VCSPs running Veeam Availability Console v3 in production.

To apply the patch, head to the VeeamKB here and follow the instructions. You need to have at least VAC v3 Build 3.0.0.2647 prior to installing as shown below.

From there, make sure you have a backup of the database, close down the Web UI and execute both MSI packages as administrator on the server.

The first one updates the VAC server. The second one updates the WebUI. Once completed the patches are applied and VAC v3 is up to date running on version number Server Version 3.0.0.2725.

References:

https://www.veeam.com/kb2960

Orchestration of NSX by Terraform for Cloud Connect Replication with vCloud Director

That is probably the longest title i’ve ever had on this blog, however I wanted to highlight everything that is contained in this solution. Everything above works together to get the job done. The job in this case, is to configure an NSX Edge automatically using the vCloud Director Terraform provider to allow network connectivity for VMs that have been replicated into a vCloud Director tenant organization with Cloud Connect Replication.

With the release of Update 4 for Veeam Backup & Replication we enhanced Cloud Connect Replication to finally replicate into a Service Providers vCloud Director platform. In doing this we enabled tenants to take advantage of the advanced networking features of the NSX Edge Services Gateway. The only caveat to this was that unlike the existing Hardware Plan mechanism, where tenants where able to configure basic networking on the Network Extension Appliance (NEA), the configuration of the NSX Edge had to be done directly through the vCloud Director Tenant UI.

The Scenario:

When VMs are replicated into a vCD organisation with Cloud Connect Replication the expectation in a full failover is that if a disaster happened on-premises, workloads would be powered on in the service provider cloud and work exactly as if they where still on-premises. Access to services needs to be configured through the edge gateway. The edge gateway is then connected to the replica VMs via the vOrg Network in vCD.

In this example, we have a LAMP based web server that is publishing a WordPress site over HTTP and HTTPs.

The VM is being replicated to a Veeam Cloud Service Provider vCloud Director backed Cloud Connect Replication service.

During a disaster event at the on-premises end, we want to enact a failover of the replica living at in the vCloud Director Virtual Datacenter.

The VM replica will be fired up and the NSX Edge (the Network Extension Appliance pictured is used for partial failovers) associated to the vDC will allow the HTTP and HTTPS to be accessed from the outside world. The internal IP and Subnet of the VM is as it was on-premises. Cloud Connect Replication handles the mapping of the networks as part of the replication job.

Even during the early development days of this feature I was thinking about how this process could be automated somehow. With our previous Cloud Connect Replication networking, we would use the NEA as the edge device and allow basic configuration through the Failover Plan from the Backup & Replication console. That functionality still exists in Update 4, but only for non vCD backed replication.

The obvious way would be to tap into the vCloud Director APIs and configure the Edge directly. Taking that further, we could wrap that up in PowerShell and invoke the APIs from PowerShell, which would allow a simpler way to pass through variables and deal with payloads. However with the power that exists with the Terraform vCloud Director provider, it became a no brainer to leverage this to get the job done.

Configuring NSX Edge with Terraform:

In my previous post around Infrastructure as Code vs APIs I went through a specific example where I configured an NSX Edge using Terraform. I’m not going to go over that again, but what I have done is published that Terraform plan with all the code to GitHub.

The GitHub Project can be found here.

The end result after running the Terraform Plan is:

  • Allowed HTTP, HTTPS, SSH and ICMP access to a VM in a vDC
    • Defined as a variable as the External IP
    • Defined as a variable as the Internal IP
    • Defined as a variable as the vOrg Subnet
  • Configure DNAT rules to allow HTTP, HTTPS and SSH
  • Configure SNAT rule to allow outbound from the vOrg subnet

The variables that align with the VM and vORG network are defined in the terraform.tfvars file and need to be modified to match the on-premises network configuration. The variables are defined in the variables.tf file.

To add additional VMs and/or vOrg networks you will need to define additional variables in both files and add additional entires under the firewall_rules.tf and nat_fules.tf. I will look at ways to make this more elegant using Terraform arrays/lists and programatic constructs in future.

Creating PowerShell for Execution:

The Terraform plan can obviously be run standalone and the NSX Edge configuration can be actioned at any time, but the idea here is to take advantage of the script functionality that exists with Veeam backup and replication jobs and have the Terraform plan run upon completion of the Cloud Connect Replication job every time it is run.

To achieve this we need to create a PowerShell script:

GitHub – configure_vCD_VCCR_NSX_Edge.ps1

The PowerShell script initializes Terraform and downloads the Provider, ensures there is an upgrade in the future and then executes the Terraform plan. Remembering that that variables will change within the Terraform Plan its self, meaning these scripts remain unchanged.

Adding Post Script to Cloud Connect Replication Job:

The final step is to configure the PowerShell script to execute once the Cloud Connect Replication job has been run. This is done via a post script settings that can be found in Job Settings -> Advanced -> Scripts. Drop down to selected ps1 files and choose the location of the script.

That’s all that is required to have the PowerShell script executed once the replication job completes.

End Result:

Once the replication component of the job is complete, the post job script will be executed by the job.

This triggers the PowerShell, which runs the Terraform plan. It will check the existing state of the NSX Edge configuration and work out what configuration needs to be added. From the vCD Tenant UI, you should see the recent tasks list modifications to the NSX Edge Gateway by the user configured to access the vCD APIs via the Provider.

Taking a look at the NSX Edge Firewall and NAT configuration you should see that it has been configured as specified in the Terraform plan.

Which will match the current state of the Terraform plan

Conclusion:

At the end of the day, what we have done is achieved the orchestration of Veeam Cloud Connect Replication together with vCloud Director and NSX… facilitated by Terraform. This is something that Service Providers offering Cloud Connect Replication can provide to their clients as a way for them to define, control and manage the configuration of the NSX edge networking for their replicated infrastructure so that there is access to key services during a DR event.

While there might seem like a lot happening, this is a great example of leveraging Infrastructure as Code to automated as otherwise manual task. Once the Terraform is understood and the variables applied, the configuration of the NSX Edge will be consistent and in a desired state with the config checked and applied on every run of the replication job. The configuration will not fall out of line with what is required during a full failover and will ensure that services are available if a disaster occurs.

References:

https://github.com/anthonyspiteri/automation/tree/master/vccr_vcd_configure_nsx_edge

Update 4 for Service Providers – Cloud Mobility and External Repository for N2WS

When Veeam Backup & Replication 9.5 Update 4 went Generally Available a couple of weeks ago I posted a What’s in it for Service Providers blog. In that post I briefly outlined all the new features and enhancements in Update 4 as it related to our Veeam Cloud and Service Providers. As mentioned each new major feature deserves it’s own seperate post. I’ve covered off three feature so far, and today i’m going to talk about two features that are more aligned to Managed Service Providers, but still could have a place in the pure IaaS world.

As a reminder here are the top new features and enhancements in Update 4 for VCSPs.

Cloud Mobility:

The Cloud Mobility feature is actually the new umbrella name for our Restore to functionality. Prior to Update 4 we had the ability to Restore to Microsoft Azure only. With the release of Update 4 we have added the ability to Restore to Microsoft Azure Stack and Amazon EC2. It’s important to point out what Cloud Mobility isn’t…that is a disaster recovery feature set. in that you can’t rely on this feature in the same way that Cloud Connect Replication allows you to power on VM replicas on demand for DR.

Though you could configure restore tasks to run on demand via PowerShell commands and have systems in a ready state after recovery it is difficult to attach an RPTO to the recovery process and therefore Cloud Mobility should be used for migrations and testing. In essence this is why it is called Cloud Mobility…to give users and Service Providers the flexibility to shift workloads from one platform to another with ease.

Restore to EC2:

The ability to restore direct to EC2 is something that is demanded these days and the addition of this feature to Update 4 was one of the most highly anticipated. In enabling the restoration of workloads into EC2 we have enabled our customers and partners to have the option to backup workloads from the following:

These backups, once stored in the Veeam Backup File format, ensures absolute portability of those workloads. In terms of restoring to EC2, the process is straight forward and can be done via the Backup & Replication console or via PowerShell.

Again, the focus of this feature is to enable migrations and testing. However when put together with the External Repository, we also complete a loopback by way of having a way to restore EC2 instances that where initially backed up with N2WS Backup & Recovery and archived to an Amazon S3 Bucket.

It should also be noted that to perform a recovery, only the most recent restore point can be used.

External Repository:

The External Repository allows you to add an Amazon S3 bucket that contain backups created by N2WS Backup & Recovery for AWS environments. Backup & Recovery for AWS will create backups of Elastic Block Stores disk volumes of EC2 instances. As part of the 2.4 release these backups where able to be placed directly to Amazon S3 object storage repositories. This is what is added to the Veeam Backup & Replication console as an External Repositories.

Backup & Recovery for AWS uses the Veeam Backup API to preserve the backup structure in the native Veeam format which are housed in the Amazon S3 Bucket as oVBKs. The External Repository cannot be used as a target for backup or backup copy jobs. Once the External Repository is configured, N2WS VMs can be manipulated through the Backup & Replication Console as per usual. This allows all the restore capabilities including Restore to EC2 and also more importantly the ability to perform Backup Copy Jobs against the backed up data to enable even longer term retention outside of Amazon S3.

Wrap Up:

The addition of Restore to EC2, Azure Stack and the External Repository can be used by manager service providers and service providers to offer true Cloud Mobility to their customers. Also, while a lot of organization are moving to the Public Cloud…this is not a fait accompli and they do sometimes want to get workloads out of those platforms and back on-premises or to Service Provider Clouds.. It shouldn’t be a Hotel California situation and with these new Update 4 features Veeam customers have more choice than other.

References:

https://helpcenter.veeam.com/docs/backup/vsphere/restore_amazon.html?ver=95u4

https://helpcenter.veeam.com/docs/backup/vsphere/external_repository.html?ver=95u4

Automatic restore of multiple machines from Veeam to AWS

 

Update 4 for Service Providers – Tenant Connectivity with Cloud Connect Gateway Pools

When Veeam Backup & Replication 9.5 Update 4 went Generally Available a couple of weeks ago I posted a What’s in it for Service Providers blog. In that post I briefly outlined all the new features and enhancements in Update 4 as it related to our Veeam Cloud and Service Providers. As mentioned each new major feature deserves it’s own seperate post. I’ve covered off Tape as a Service and RBAC Self Service, and today i’m focusing on a much requested feature…Cloud Connect Gateway Pools

As a reminder here are the top new features and enhancements in Update 4 for VCSPs.

Gateway Pools for Cloud Connect

Cloud Connect has become the central mechanism for connectivity and communication between multiple Veeam services. When first launched with Cloud Connect Backup in v8 of Backup & Replication, the Cloud Connect Gateways where used for all secure communications between tenant backup server instances and the Veeam Cloud and Service Provider (VCSP) Cloud Connect backup infrastructure. This expanded to support Cloud Connect Replication in v9 and from there we have added multiple products that rely on communications brokered by Cloud Connect Gateways.

As of today Cloud Connect Gateways facilitate:

  • Cloud Connect Backup
  • Cloud Connect Replication
  • Full and Partial Failovers for Cloud Connect Replication
  • Remote Console Access
  • Veeam Availability Console Tenant and Agent Management
  • Veeam Backup for Microsoft Office 365 Self Service

With regards to acting as the broker for Cloud Connect Backup or Replication, prior to Update 4 the only way in which a VCSP could design and deploy the Gateways was in an all or nothing approach when it came to configuring the IP address and DNS for the service endpoint. When considering VCSPs that also provide connectivity such as MPLS for their customers it meant that to leverage direct connections that might be private the options where to either use the public address or setup a whole new Cloud Connect environment for the customer.

Now with Update 4 and Gateway Pools a VCSP can configure one or many Gateway Pools and allocate one or more Cloud Connect Gateways to those pools. From there, tenants can be assigned to Gateway Pools.

Cloud Gateways in a Gateway Pool operate no differently to regular Cloud Gateways. As with previous Cloud Gateways, If the primary gateway is unavailable, the logic built into Veeam Backup & Replication will failover to another Cloud Gateway in the same pool.

If tenants are not assigned a Cloud Gateway Pool they can use only gateways that are not a part of any cloud gateway pool. That situation is warned in the UI when configuring the gateways.

Wrap Up:

The introduction of Cloud Connect Gateway Pools un Update 4 was undertaken due to direct feedback from our VCSPs who wanted more flexibility in the way in which the Cloud Gateways where deployed and configured for customers. Not only can they be used to seperate tenants connecting from public and private networks, but they can also be used for Quality of Service by assigning a Gateway Pool to specific tenants. They can also be used to control access into a VCSPs Cloud Connect infrastructure if located in different geographic locations.

For a great overview and design considerations of Cloud Connect Gateway Pools and Gateways themselves, check out Luca’s Cloud Connect Book here.

References:

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

Update 4 for Service Providers – Self Service Backup through RBAC for vSphere

When Veeam Backup & Replication 9.5 Update 4 went Generally Available a couple of weeks ago I posted a What’s in it for Service Providers blog. In that post I briefly outlined all the new features and enhancements in Update 4 as it related to our Veeam Cloud and Service Providers. As mentioned each new major feature deserves it’s own seperate post. I started last week with a look at Tape as a Service and today i’m looking at another underrated feature…vSphere RBAC Self Service Portal.

As a reminder here are the top new features and enhancements in Update 4 for VCSPs.

vSphere RBAC Self Service Portal:

When Veeam Backup & Replication 9.5 was released one of the top new features was the vCloud Director Self Service Portal. This was aimed at our Veeam Cloud & Service Providers that leverage vCloud Director as their Cloud Management Platform to offer self service capabilities. The portal was part of Veeam Enterprise Manager and uses vCloud Director Organizations and leverages vCloud Director authentication.

For Update 4, we have used this feature as a base to release the vSphere RBAC Self Service Portal. This has been primarily marketed as a non service provider feature that enterprises can use to drive self service backup internally.

My fellow Product Strategy Technologist, Melissa Wright (@vmiss) has released a great overview of the vSphere RBAC Self Service Portal here. She goes through the setup and configuration and takes a look at how to configure users and permissions and shows the power of the feature as it pertains to enterprise customers.

RBAC for vSphere IaaS:

The great thing about this new portal is that it can be used either in conjunction with the vCloud Director Self Service Portal or standalone in the case that a service provider is not running vCloud Director. That is where this portal will come into play…while there are a number of VCSPs that do run vCloud Director the large majority of service providers or managed service providers do not. If they are running IaaS off native vSphere, the portal can be used to offer self service backup and recovery to their tenants.

The self service permissions can be retrofitted to existing vCenter permissions or can be started fresh by using vSphere Tags. Personally, I believe the vSphere Tags is the best way to configure the multi-tenancy aspect of the configuration. In the setup, tags are matched to users which will dictate what tenants will be able to see and select when they log in.

Tenant Functions:

Tenants get access to the self service web portal which the VCSP makes available externally. Depending on the user roles and permissions that have been configured, they can select virtual machines to manage backup jobs, as well as restore VMs, files and application items within the bounds of their permissions. Tenants can also a manage retention, schedule and notification settings as well as guest OS processing options.

To simplify job management for the tenants, advanced job parameters (like backup mode and repository settings) are automatically populated from the job templates if desired.

Wrap Up:

Once again, the vSphere RBAC Self Service Portal is one of the sleeper hits of Update 4 for Veeam Backup & Replication 9.5 and should be considered by all VCSPs to offer a level of self service capability to their tenants. The way in which this has been implemented on the back of Enterprise Manager with a one to many portal means this is the best self service portal for IaaS and/or vCloud Director…also we do not need specialised appliances per tenant which is a massive up side on how Veeam differentiates itself in this space.

References:

https://vmiss.net/2019/02/14/veeam-enterprise-manager-self-service-vsphere/amp/

https://helpcenter.veeam.com/docs/backup/em/em_working_with_vsphere_portal.html?ver=95u4

Update 4 for Service Providers – Tape as a Service

When Veeam Backup & Replication 9.5 Update 4 went Generally Available a couple of weeks ago I posted a What’s in it for Service Providers blog. In that post I briefly outlined all the new features and enhancements in Update 4 that pertain to our Veeam Cloud and Service Providers. As mentioned each new major feature deserves it’s own seperate post and today I’m kicking off the series with what I feel was probably the least talked about new feature in Update 4…Tape as a Service for Cloud Connect Backup.

As a reminder here are the top new features and enhancements in Update 4 for VCSPs.

Tape as a Service for Cloud Connect Backup:

When we introduced Cloud Connect Backup in version 8 of Backup & Replication we offered the ability for VCSPs to offer a secure, remote offsite repository for their tenants. When thinking about air-gapped backups…though protected at the VCSP end, ultimate control for what was backed up to the Cloud Repository is in the hands of the tenant. From the tenant’s server they could manipulate the backups stored via policy or a malicious user could gain access to the server and delete the offsite copies.

In Update 3 of Backup & Replication 9.5 we added Insider Protection to Cloud Connect Backup, which allowed the VCSP to put a policy on the tenant’s Cloud Repository that would protect backups from a malicious attack. 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.

In Update 4 we have taken that a step further to add true air-gapped backup options that VCSPs can create services around for longer term retention with the Tenant to Tape feature. This allows a VCSP to offer additional level of data protection for their tenants. The tenant sends a copy of the backup data to their cloud repository, and the VCSP then configures backup to tape to send another copy to the tape media. If there is a situation that requires recovery if data in the cloud repository becomes unavailable, the VCSP can initiate a restore from tape.

VCSPs can also offer a tape out services to help their tenants achieve compliance and internal policies without maintaining their own tape infrastructure. Tapes can be stored by the service providers, or shipped back to tenant as shown in the diagram below.

To take advantage of this new Update 4 feature VCSPs will need to configure Tape Infrastructure on the Cloud Connect server. What’s great about Veeam is that we have the option to use traditional tape infrastructure or take advantage of Virtual Tape Libraries (VTLs) which can then be backed by Object Storage such as Amazon S3. I am not going to walk through that process in this post, there are a number of blogs and White Papers available that guide you on the setup of an Amazon Storage Gateway to use as a VTL.

Once the Tape Infrastructure is in place, as a VCSP with a Cloud Connect license when you upgrade to Update 4, under Tape Infrastructure you will see a new option called Tenant to Tape.

A tenant backup to tape job is a variant of a backup to tape job targeted at a GFS Media Pool which is available for Veeam customers with regular licensing. What’s interesting about this feature is that there are a number of options that allow flexibility on how the jobs are created which also leads to a change of use case for the feature depending on which option is chosen.

Choosing Backup Jobs will allow VCSPs to add any jobs that may be registered on the Cloud Connect server…though in reality there shouldn’t be any configured due to licensing constraints. The other two options provide the different use cases.

Backup Repositories:

This allows the VCSP to backup to tape one or more cloud repositories that can contain one or multiple tenants. The can allow the VCSP to backup the Cloud Connect repository in whole to an offsite location for longer term retention.

The ability to archive tenant Cloud Connect Backups to tape can help VCSPs protect their own infrastructure against disasters that may result in loss of tenant data. It can be used as another level of revenue generating service. As an example, there could be two service offerings for Cloud Connect Backup… one with a basic SLA which only has one copy of the backup data stored… and another with an advanced SLA that has data saved in two locations…the Cloud Connect Repository and the tape media. 

Tenants:

This option offers a lot more granularity and gives the VCSP the ability to offer an additional level of protection on a per tenant level. In fact you can also drill down to the Tenant repository level and select individual repositories if tenants have more than one configured.

Again, this can be done per tenant, or there can be one master job for all tenants.

It’s important to understand that all tasks within the tenant backup to tape feature are performed by the VCSP. Unless the VCSP has created a portal that has information about the jobs, the tenant is generally unaware of the tape infrastructure and the tenant can’t view or manage backup to tape jobs configured or perform operations with backups created by these jobs. There is scope for VCSPs to integrate such jobs and actions into their automation portals for self service.

Restores:

VCSPs can restore tenant data from tape for one tenant or more tenants at the same time. The restore can go to the original location or to a new location or be exported to backup files on local disk

Wrap Up:

Tenant to Tape or Tape as a Service for Cloud Connect Backup was a feature that didn’t get much airplay in the lead-up to the Update 4 launch, however it give VCSPs more options to protect tenant data and truly offer an air-gapped solution to better protect that data.

References:

https://www.veeam.com/wp-using-aws-vtl-gateway-deployment-guide.html

https://aws.amazon.com/about-aws/whats-new/2016/08/backup-and-archive-to-aws-storage-gateway-vtl-with-veeam-backup-and-replication-v9/

Backup & Replication 9.5 Update 4 – What’s In It For Service Providers

For ten plus years Veeam has continued to develop new innovative features and enhancements supporting our Cloud and Service Provider partners. As I posted earlier this week, there is a proven track record built upon a strong foundation of Veeam technology that backs up our strong leadership position in the Service Provider space. This accelerated in v7 with vCloud Director support…continued with Cloud Connect Backup in v8, Cloud Connect Replication in the v9 release and even more through the Backup and Replication 9.5 releases and Updates.

In my initial v9.5 Update 4 Top New Features post I covered off new core features and enhancements that are included in Update 4. Specifically there are a number of new features that VCSPs can take advantage of…

Over the next few weeks I am going to deep dive into each of the features listed above as they all deserve their own dedicated blog posts. With a release as huge as this, there is no shortage of content that can be created off the back up Update 4!

Beyond the core enhancements, there are also a significant number of general enhancements that are referenced in the What’s New Document. I’ve gone through that document and pulled out the ones that relate specifically to Cloud and Service Provider operations for those running IaaS and B/R/DRaaS offerings.

  • Maximum supported individual disk size and backup file size have been increased 10 times. With the default 1MB block size, the new theoretical VBK format maximums are 120TB for each disk in backup. Tested maximum is 100TB for both individual disks and backup files.
  • Optimized backup job initialization and finalization steps, resulting in up to 50% times faster backups of small VMs
  • Added experimental support for block cloning on deduplicated files for Windows Server 2019 ReFS
  • vPower NFS write cache performance has been improved, significantly improving I/O performance of instantly recovered VMs and making a better use of SSD drives often dedicated by customers to write cache.
  • vPower NFS scalability has been improved to more efficiently leverage expanded I/O capacity of scale-out backup repository for increased number of VMs that can be running concurrently
  • Support for Paravirtual SCSI controllers with more than 16 disks attached
  • Added JSON support
  • Added RESTful API coverage for viewing and managing agent-based jobs and their backups
  • Added the ability to export the selected restore point of a particular object in the backup job as a standalone full backup file (VBK)
  • Added ability to instantly publish a point-in-time state of any backed-up database to the selected SQL Server for dev/test purposes by running the database directly from the backup file
  • Added the ability to export a point-in-time state of any backed up database to a native SQL Server backup (.BAK file) to simplify the process of providing the database backup to SQL developers, BaaS clients or Microsoft Support
  • Added the ability to schedule Active Full backups on a particular day of the month, as opposed to just weekdays
  • Instant recovery of agent backups to a Hyper-V VM now support Windows 10 Hyper-V as the target hypervisor. This is particularly useful for managed service providers by enabling them to create low-cost all-in-one BCDR appliances to deploy at their clients’ premises.

What I pulled out above is just a small subset of all the general enhancements in Update 4. For Cloud Connect, there is a Post in the Veeam Forums here that goes through specific new features and enhancements in greater detail as well as fixes and known issues.

Stay tuned for future posts on the core new features and enhancements in Update 4 for Veeam Cloud and Service Providers.

References:

https://www.veeam.com/kb2878

http://www.veeam.com/veeam_backup_9_5_whats_new_wn.pdf

http://www.veeam.com/veeam_backup_9_5_u4_release_notes_rn.pdf

Veeam for Service Providers…Ten Plus Years of Innovation!

I remember the day I first came across Veeam. It was mid 2010 and I was working for Anittel at the time. We had a large virtualisation platform that hosted a number of high profile sites including a well known e-commerce site. There had been a serious data breach on one of those site and we were required by the Australian Federal Police to restore the website logs from a couple weeks back when the breach had first taken place.

We were using a well known product at the time to backup our vSphere platform and from the outside everything seemed ok. All backup reports where green and we thought the backups where verified. To cut a long and painful story short, when we came to restore the website logs we found that the backups had not worked as expected and we couldn’t retrieve data off a secondary partition due to a huge unknown bug in the software.

That was the end for that backup application (and interestingly enough they went out of business a few years later) and that afternoon we downloaded Veeam Backup & Replication v4 and went to work pushing that out into production. We (and I have) never looked back from there. Veeam did in fact Just Work! At that stage there were enough features in the software to cover all of the requirements for a VMware based hosting platform, and over the years as v5 and v6 were released more and more features and enhancements were released that made Veeam even better service providers.

By the time I left Anittel and headed to Zettagrid, Veeam had introduced more innovative features like Instant VM Recovery, vCloud Director Support, Cloud Connect Backup, the Scale Out Backup Repository just to name a few. In fact Veeam impressed me so much with their Service Provider features that I joined the company where I now focus my time on working with Service Providers as part of the Veeam Product Strategy Team focusing on our cloud and service providers products and features.

While I could bang on about all the features that Veeam has released over the years to enable us to become a significant player in the Cloud and Service Provider space, a picture tells a thousand words…and an interactive timeline showing just how innovative and focused Veeam has been on enabling our Cloud and Service Provider partners to succeed is priceless!

No other vendor has this track record of producing specific Cloud and Service Provider features and enhancements over the years and as you can see over the last three to five years we have moved with the industry to continue innovating in the cloud space by accelerating feature development and bringing great technology to the market.

If you are a Cloud and Service Provider and not using Veeam…what are you waiting for?

https://anthonyspiteri.net/veeam-vcsp-reverse-roadmap/

Hybrid World… Why IBM buying RedHat makes sense!

As Red October came to a close…at a time when US Tech stocks were taking their biggest battering in a long time the news came out over the weekend that IBM had acquired RedHat for 34 billion dollars! This seems to have taken the tech world by surprise…the all-cash deal represents a massive 63% premium on the previous close of RedHat’s stock price…all in all it seems ludicrous.

Most people that I’ve talked to about it and from reading comments on social media and blog sites suggests that the deal is horrible for the industry…but I’ve felt this is more a reaction to IBM than anything. IBM has a reputation as swallowing up companies whole and spitting them out the other side of the merger process a shell of what they once were. There has also been a lot of empathy for the employees of RedHat, especially from ex-IBM employees who have experience inside the Big Blue machine.

I’m no expert on M&A and I don’t pretend to understand the mechanics behind the deal and what is involved…but when I look at what RedHat has in its stable, I can see why IBM have made such an aggressive play for them. On the surface it seems like IBM are in trouble with their stock price and market capitalization falling nearly 20% this year and more than 30% in the last five years…they had to make a big move!

IBM’s previous 2013 acquisition of SoftLayer (for a measly 2 billion USD) helped them remain competitive in the Infrastructure as a Service space and if you believe the stories, have done very well out of integrating the SoftLayer platform into what was BlueMix, and is now IBM Cloud. This 2013 Forbes article on the acquisition sheds some light as to why this RedHat acquisition makes sense and is true to form for IBM.

IBM sees the shift of big companies moving to the cloud as a 20-year trend…

That was five years ago…and since then a lot has happened in the Cloud world. Hybrid cloud is now the accepted route to market with a mix of on-premises, IaaS and PaaS hosted and hyper-scale public cloud services being the norm. There is no one cloud to rule them all! And even though AWS and Azure continue to dominate and be front of mind there is still a lot of choice out there when it comes to how companies want to consume their cloud services.

Looking at RedHat’s stable and taking away the obvious Linux distro’s that are both enterprise and open sources the real sweet spot of the deal lies in RedHat’s products that contribute to hybrid cloud.

I’ve heard a lot more noise of late about RedHat OpenStack becoming the platform of choice as companies look to transform away from more traditional VMware/Hyper-V based platforms. RedHat OpenShift is also being considered as an enterprise ready platform for containerization of workloads. Some sectors of the industry (Government and Universities) have already decided on their move to platforms that are backed by RedHat…the one thing I would comment here is that there was an upside to that that might now be clouded by IBM being in the mix.

Rounding out the stable, RedHat have a Cloud Suite which encompasses most of the products listed above. CloudForms for Infrastructure as Code, with Ansible for orchestration…together with RedHat Virtualization together with OpenStack and OpenShift..it’s a decent preposition!

Put all that together with the current services of IBM Cloud and you start to have a compelling portfolio covering almost all desired aspects of hybrid and multi cloud service offerings. If the acquisition of SoftLayer was the start of a 20 year trend then IBM are trying to keep themselves positioned ahead of the curve and very much in step with the next evolution of that trend. That isn’t to say that they are not playing catchup with the likes of VMware, Microsoft, Amazon, Google and alike, but I truly believe that if they don’t butcher this deal they will come out a lot stronger and more importantly offer valid completion in the market…that can only be a good thing!

As for what it means for RedHat itself, their employees and culture…that I don’t know.

References:

https://www.redhat.com/en/about/press-releases/ibm-acquire-red-hat-completely-changing-cloud-landscape-and-becoming-world%E2%80%99s-1-hybrid-cloud-provider

IBM sees the shift of big companies moving to the cloud as a 20-year trend

Quick Fix – Backup for Office 365 Self Service Recovery Fails with Incompatible Version

A couple of weeks ago we released version 2.0 of Veeam Backup for Office 365 which added support for SharePoint and OneDrive. Earlier this year I wrote about the awesome self service capabilities that are included for Veeam Cloud and Service Providers in the VBO platform, and also the huge opportunity that exists in the provider space to offer backup service for Exchange. Add to that SharePoint and OneDrive and that opportunity only gets bigger.

I’m putting together a couple of posts around the self service of SharePoint and OneDrive in the 2.0 release, but in the meantime this is a very quick fix post for those that might be getting the below error when trying to connect to service provider endpoints running VBO services for Exchange Online.

Incompatible Veeam Backup for Office 365 server version, received 9.6.3.567, expected 9.6.0.1308

To resolve this issue, then tenant needs to download the VBO 2.0 download package and install the new version of the Veeam Explorer for Microsoft Exchange that’s included in the release.

This will update the existing Explorer version from that distributed with Veeam Backup & Replication 9.5. The awesome thing about getting the upgrade as part of the VBO 2.0 package is that for the 1.5 release where self service was first introduced, tenants had to wait for Update 3 for Backup & Replication to consume the service.

Once this has been updated you can once again connect to the Cloud Connect infrastructure of the Service Provider that allows the self service recoverability function to take place.

« Older Entries