Category Archives: Backup

VeeamON 2018 Recap

VeeamON has come an gone for another year and it is an exciting time to be in the (hyper) availability industry. There has been a significant shift in the way that backup and recovery is thought about in the IT Industry and Veeam is without question leading the way in this space. We have been the driving force of change for an industry that was once seen as mundane yet necessary. This year we did not announce any new products or features but more importantly laid the ground work for what is to come with our new vision and strategy. To be the leading provider of intelligent data management solution for a world where data is now highly distributed, is growing at exponential rates and where hyper-availability is desired.

What does that exactly mean?

Well for me it is an evolution of our messaging that what presented in August of 2016 where the Veeam Availability platform was first launched. The platform it’s self has evolved over the past eighteen months with the release of Veeam Availability Orchestrator, Veeam Availability Console, Backup for Office 365, both the Windows and Linux agents and more recently the pending releases of our Nutanix AHV backup and support for AIX and Solaris. Put that together with the acquisition of N2WS for AWS availability and you can see that we are serious about fulfilling the promise of the vision laid out during the event.

2018 Highlights:

Apart from delivering three sessions, my highlights revolve around my discussions with customers and partners and getting face to face feedback on how we are doing. This is critical to our function in the Product Strategy team but for me personally it allows me to interact with some of the best innovators in the service provider landscape. On that note, another highlight was the inaugural Veeam Innovation Awards of which I was a voting panel member along with Michael Cade and Jason Buffington. It was great to see four VCSPs win recognition and awesome to have Probax (a local Perth company) included as part of the initial group of winners.

From the Show Floor:

I have copied in a number of media interviews and daily wraps below that go into more detail about the event, it’s announcements and the messaging that we are putting forward as a leader in the space. Enjoy the discussions below and I am already looking forward to VeeamON 2019…I have a feeling it’s going to be massive!

 

Veeam Cloud Announcements:

Veeam expands multi-cloud solutions at VeeamON 2018

Cloud Connect Subtenants, Veeam Availability Console and Agents!

Cloud Connect Subtenants have gone under the radar for the most but can play an important role in how Service Provider customers consume Cloud Connect services. In a previous post, I described how subtenants work in the context of Cloud Connect Backup.

Subtenants can be configured by either the VCSP or by the tenant consuming a Cloud Connect Backup service. Subtenants are used to carve up and assign a subset of the parent tenant storage quota. This allows individual agents to authenticate against the Cloud Connect service with a unique login allowing backups to Cloud Repositories that can be managed and monitored from the Backup & Replication console.

In this post I’m going to dive into how subtenants are created by the Veeam Availability Console and how they are then used by agents that are managed by VAC. For those that may not know what VAC does, head to this post for a primer.

Automatic Creation of Subtenant Users:

Veeam Availability Console automatically creates subtenant users if a backup policy that is configured to use a cloud repository as a backup target is chosen. When such a backup policy is assigned to an agent, VAC creates a subtenant account on the Cloud Connect Server for each backup agent.

Looking below you can see a list of the Backup Agents under the Discovery Menu.

Looking at the Backup Policy you can see that the Backup Target is a Cloud Repository, which results in the corresponding subtenant account being created.

The backup agents use these subtenant accounts to connect and send data to a Cloud Connect endpoint that are backed by a cloud repository. The name of each subtenant account is created according to the following naming convention:

companyname_computername

At the Cloud Provider end from within the Backup & Replication console under the Cloud Connect Menu and under tenants, clicking on Manage Subtenants will show you the corresponding list of subtenant accounts.

The view above is the same to that seen at the tenant end. A tenant can modify the quota details from the Veeam Backup & Replication console. This will result in a Custom Policy status as shown below. The original policy can be reapplied from VAC to bring it back into line.

The folder structure on the Cloud Repository maps what’s seen above. As you can also see, if you have Backup Protection enable you will also have _RecycleBin objects there.

NOTE: When a new policy is applied to an agent the old subtenant account and data is retained on the Cloud Connect repository. The new policy gets applied and a subtenant account with an _n gets created. Service Providers will need to purge old data manually.

Finally if we look at the endpoint where the agent is installed and managed by VAC you will see the subtenant account configured.

Conclusion:

So there is a deeper look at how subtenants are used as part of the Veeam Availability Console and how they are created, managed and used by the Agent for Windows.

References:

https://helpcenter.veeam.com/docs/vac/provider_admin/create_subtenant_user.html?ver=20

Upgrading Windows Agents with Veeam Availability Console

One of the Veeam Availability Console’s key features is it’s ability to deploy and manage Veeam Agent for Windows. This is done through the VAC Web Console and is achieved through the connectivity of the providers Cloud Connect Gateway to the tenant’s Veeam Backup & Replication instance. Weather this is managed by a service provider or by the tenant, VAC also has the ability to remotely upgrade Windows Agents.

The way that this works is by the Veeam Availability Console periodically connecting to the Veeam Update Server and checks whether a new version of the agent software is available. If a new version is available, VAC displays a warning next to the agents saying that it is outdated as shown below.

Updating the backup agents from the Veeam Update Server is performed via the master agent that sits on-premises. This agent is deployed during the initial Service Provider configuration form the Veeam Backup & Replication server. The master agent downloads the backup agent setup file from the Veeam Update Server and then uploads this setup file to systems selected via the update scope and initiates the update.

To initiate the upgrade, select the agents from the Backup Agents Tab under Clients -> Discovery. Once selected click on the Backup Agent dropdown and click upgrade.

Note: Once you click Upgrade the process will be kicked off…there is no further confirmation. There is also a Patch option which allows you to apply patches to the agents in between major build releases.

Once initiated, all agents will be shown as updating as shown below.

Taking a look at the Resource Monitor of one of the endpoints being updated, you can see that the machine is receiving the update from the local server that has the master agent and that the agent is talking back to the VAC server via Cloud Connect Port 6180.

And you can see the Windows Installer running the agent update msi.

Back to the VAC console, and after a while you will see the update deployment status complete

And the endpoint now has the updated agent version running.

Which is reflected in the VAC Console.

Conclusion:

That’s the very straight forward process of having the Veeam Availability Console upgrade Veeam Windows Agents under it’s management. Again, this can be done by the service provider or it’s a task that can be executed by the tenant through their own console login given the correct permissions. There are a few other options for those that deployed the agents with the help of a 3rd party tool and also for those doing it offline…for a run down of that process, head to the help pages linked below.

References:

https://helpcenter.veeam.com/docs/vac/provider_admin/update_backup_agents.html?ver=20

VeeamOn 2018: Recognizing Innovation and what it means to be Innovative

True innovation is solving a real problem…and though for the most, it’s startups and tech giants that are seen to be the innovators, their customers and partners also have the ability to innovate. Innovation drives competitive advantages and allows companies to differentiate themselves compared to others. In my previous roles I was lucky to be involved with teams of talented people that did great things with great technologies. Like others around the world we where innovating with leading vendor technologies to create new service offerings that add value and compliment the underlying technology.

Innovation requires these teams of people to be experimental at heart and try to build or enhance upon already existing technologies. The Service Provider industry has always found a way to innovate ontop of vendor platforms and successful vendors are those that offer the right tools and guidance for providers to creative innovative solutions ontop of their platforms. The are problem solvers!

Orchestrations, automation, provisioning and billing are driving factors in how service providers can differentiate themselves and gain that competitive advantage in the marketplace. Without innovating ontop of these platforms, service offerings become generic, don’t stand out and are generally operationally expensive to manage and maintain.

Introducing the Veeam Innovation Awards for 2018:

When visiting and talking to different partners across the world it’s amazing to see some of the innovation that’s been built ontop of Veeam technologies and we at Veeam want to reward our customers and partners who have done great things with our technologies.

At VeeamON 2018, we’ll be celebrating some of these innovative solutions, so please let us know how you’ve built upon the Veeam Availability Platform. Nominations can be made from March 29 to April 30, with the winners being recognized during the VeeamON main stage keynote. Self nominations or those from partners, providers, or Veeam field-team members are encouraged — click here to nominate for a Veeam Innovation Award.

I can think of a number of VCSPs that have done great things with building upon Cloud Connect, Backup & Replication IaaS backups and working with Veeam’s API’s and PowerShell to solve customer problems and offer value added services. These guys have brought something new to the industry and we want to reward that.

Having previously come from a successfully innovate company within their own space, being innovative is now something I try to preach to all customers and partners I visit. It is an absolute requirement if you want to win business and stand out in the backup and availability industry…innovation is key and we want to hear about it from you!

References:

Nominations for the VeeamON 2018 Innovation Awards are now open

Setting up vSAN iSCSI and using it as a Veeam Repository

Probably one of the least talked about features of vSAN is it’s ability to serve out iSCSI volumes. The feature was released with vSAN 6.5 and was primarily focused on physical workloads and is easily configurable via the vSphere Web Client. iSCSI targets on vSAN are managed the same as any other vSAN objects using Storage Policy Based Management (SPBM). Deduplication, compression, mirroring, and erasure coding can be utilized with the iSCSI target service as well as CHAP and Mutual CHAP authentication.

Of late, i’ve been asked by service providers about using Object Storage platforms as Veeam Backup & Replication repositories. There are a lot of options out there but someone asked specifically about using vSAN. In theory you could just use a VMDK on a vSAN datastore but I thought it would be interesting to look at using iSCSI to mount a volume and use it as a repository.

Initial iSCSI Configuration for vSAN:

First thing we need to do is enable the iSCSI Target service from the vSphere Web Console. Under the Cluster Configuration tab and in the iSCSI Target menu you need to enabled the iSCSI service. Select the default iSCSI Network kernel interface and then modify the iSCSI port and add security if desired. Take note of the info message around using the Storage Policy for the home object.

From there we setup a new iSCIS Target. From here you will be given the IQN and we will give the target an alias. This window also lets us create the first LUN to the iSCSI Target. The LUN id can be specified along with the alias and finally the size. Just like creating a new VMDK on a vSAN datastore we are given the storage consumption of the object depending on the Storage Policy chosen.

Once completed under the iSCSI Target pane we see the details of the Target and LUN just created. Take note of the I/O Owner Host as that is what we will be using later on as the iSCSI Target from the Veeam repository server.

Configuring Host access and setting iSCSI Access Permissions:

On the creation of a LUN there is a default policy that allows all initiator sources to connect to it. To create specific permissions for host access and to also create access groups you need to first enable the iSCSI initiator at the hosts. For that, I’ve got a Windows VM (note only physicals are officially supported) that’s got Veeam Backup & Replication installed on it. To connect to the iSCSI network we have to add an additional vNIC that’s hooked into a PortGroup that’s configured with the vSAN iSCSI VLAN.

Below we can see the VMKernel configuration and IP address of the I/O Owner hosts.

I’ve created a new PortGroup for the new vNIC to be attached to and added it to the VM.

From there we need to start the Microsoft iSCSI Initiator service which will give us the Initiator name we need to configure host access in the vSphere Web Client. Note that we should also install and enable MPIO for iSCSI if not installed as a Windows Feature.

Under the iSCSI Initiator Groups menu in the Cluster Configuration tab you can add the initiator to a new group. This can contain one or many hosts as you would expect in any iSCSI initiator group configuration.

Once that’s been done we have to allow that new group access to the target where the LUN is contained. Under the iSCSI Target menu and under Target Details in the lower pane click on the + icon and add the group as an allowed initiator.

From here we can go back to the Windows VM and connect to the iSCSI Target. We are using the IP Address of the Host was was highlighted above in the initial configuration.

Once done we should have a connected disk that’s visible in the Devices configuration of the isCSI Initiator.

Configuring new iSCSI Volume as Veeam Repository:

From here the process to setup a Veeam Repository based on the vSAN iSCSI LUN is straight forward. Firstly we need to bring online the volume and create a partition. As you can see below, the disk is of Bus Type iSCSI and Name is VMware Virtual SAN.

As for the partition configuration, I’ve set it up as shown before. ReFS being used as the file system.

From here we can head into the Backup & Replication console and create a new Repository with the new volume selected.

Performance and Limitations:

Once configured I was interested in seeing how a vSAN iSCSI connected object performed against a vSAN disk. The results below show that there is a significant performance hit in going one way or the other. This seems logical as in addition to iSCSI overheads a native VMDK on vSAN is hooked into the ESXi kernel directly and should get line speed rates when it comes to data transfer.

Below are the configuration maximums with vSAN iSCSI as listed below:

  • Maximum 1024 LUNs per vSAN cluster
  • Maximum 128 targets per vSAN cluster
  • Maximum 256 LUNS per target
  • Maximum LUN size of 62TB
  • Maximum 128 iSCSI sessions per host.
  • Maximum 4096 iSCSI IO queue depth per host
  • Maximum 128 outstanding writes per LUN .
  • Maximum 256 outstanding IOs per LUN.
  • Maximum 64 client initiators per LUN

So the max size of an iSCSI LUN matches the max size of a VMDK. Therefore when considering iSCSI as a possible option for Veeam backups, Scale Out Backup Repositories should be used to enable the adding at extents once that limit is reached.

There are also limitation on offical support for virtual machines and other platforms:

  • Currently not supported for implementation for Microsoft clusters.
  • Currently not supported for use as a target for other vSphere hosts.
  • Currently not supported for use with third party hypervisors.
  • Currently not supported for use with virtual machines

So if this becomes a consideration, physical servers will need to be used in order to gain support.

Conclusion:

So after all is said an done, we have a Veeam Repository than is now sitting on vSAN via iSCSI. The question remains weather this is a good application of vSAN or weather it’s worth looking at as an option, however the option is now there. Again, you may be able to look at the native VMDK option, but I like the flexibility of iSCSI for physical repositories at the moment.

Probably the biggest consideration for using vSAN iSCSI as a Veeam repository is the design of the vSAN Cluster. vSAN has not traditionally been considered for storage only purposes, however you could put together some low compute nodes with large disk groups that would present decent storage for repository purposes.

In using vSAN you have the benefit of knowing your data is redundant across multiple nodes as per the vSAN Storage Policies. This is the benefit of using object storage like vSAN as a Veeam Repository.

References:

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-13ADF2FC-9664-448B-A9F3-31059E8FC80E.html 

https://kb.vmware.com/kb/2148216

 

Veeam Availability Console now available from Azure Marketplace

Last week the Veeam Availability Console Azure Marketplace appliance went live. This allows Veeam Cloud and Service Providers to easily deploy VAC into any Azure region. In it’s previous incarnation the Managed Backup Portal was only available as an Azure marketplace appliance and not available to install by a VCSP. Now that VAC 2.0 is out, VCSPs who don’t have the ability to host Cloud Connect or VAC on their infrastructure can deploy it in Azure and have the service up and running within fifteen minutes.

There are some limitations that come along with deploying VAC into Azure and it won’t be for everyone. The biggest caveat is that you can only have one Cloud Connect Server per VAC instance and as part of the deployment, Cloud Connect services is installed on the same Virtual Machine. You can’t offer Replication services from the Azure instance, and if offering Cloud Connect backup you need to understand it’s own scalability and performance bottlenecks. That said, as a remote management, monitoring, reporting, billing and self service platform there is a lot to like about having VAC in Azure.

Marketplace Deployment Steps:

You can start the deployment by searching for Veeam Availability Console in the Azure Marketplace or you can go direct to the product page here.

Click on Create to start the configuration steps.

The Basics includes VM name, hard disks type, username and password as well as selecting the subscription, the ability to use a new or existing resource group and finally the Azure location you want to deploy into.

In Step 2 you need to choose the Size of the Azure instance. The template provides the recommended configurations. The sizes are relative to the amount of agents and/or Backup & Replication instances you are going to be managing from this instance. You can find sizing guides here for larger environments.

I ended up going with an A2 standard for my instance which removes the load balancing functionality from the configuration and offers a little less IOPS. Step 3 contains some optional extra’s to ensure a higher level of availability for the VM instance and lets you configure the networking. Once that’s done you can review your configuration settings and start the deployment. It took just over 8 minutes for the deployment to succeed.

If you click on the Virtual Machine object in the Azure Portal you will see an overview of the VM and it’s configuration.

Addition Azure Configuration:

If you notice in the image above, a DNS name is listed in the overview. This was something that I had to set manually after the deployment. You set this by going into the Networking of the resource pool and click on IP Configuration. Here, you can enter in a DNS name relative to the Azure zone you are in. You can then use this to connect to the VAC Console, Cloud Connect Service and to RDP to the VM and helps in the event of having a dynamic, rather than a static Azure IP.

Speaking of networking and ports, below is a list of the default port rules created during the deployment. Note that WinRM is open as well.

Finalizing Deployment:

After deploying the Azure Marketplace appliance you can RDP into the VM and complete the setup that includes configuring Cloud Connect and VAC it’s self. A few things have been done for us as part of the deployment, however the first thing you need to do is get a license. This is a BYO license situation, so once you have deployed the Marketplace appliance you will need to source a VAC license from the Veeam Licensing Portal and apply.

Head to the VAC Web Portal and Install the License.

Once done the last step is to configure Cloud Connect from the Backup & Replication Console. Again, you will need a valid Cloud Connect license as you are greeted with the Free Edition when you connect to the console for the first time. As per normal with Cloud Connect, you need to configure the SSL Certificate first and then configure a new Cloud Gateway. Configure the Networking as shown below using the DNS name that was created in the steps above.

Once this is completed you can go into the VAC Console and work through the normal Configuration steps. The only thing you don’t need to do is add the Cloud Connect Server to the VAC instance as this has already been done during the initial deployment process.

It’s worth noting that the versions of Backup & Replication (9.5.0.1536) and Availability Console (2.0.1.1343) are up to date and include the latest Hot-Fixes for VAC. The intent is to have the templates as up to date as possible, however once deployed you can upgrade as per usual.

Conclusion:

So there you have it…within fifteen minutes you can have a fully working Veeam Availability Console instance running in Azure and ready to be used to offer all the goodness that VAC offers our Cloud and Service Provider partners. For an overview as to what VAC offers, click here and have a read of my GA post on What’s in It for Service Providers.

Links:

https://azuremarketplace.microsoft.com/en-us/marketplace/apps/veeam.veeam-availability-console?tab=Overview

 

Office 365 Backups and the Opportunity that Exists for Service Providers

In recent weeks i’ve become reacquainted with an old friend…There was a time where eighty to ninety percent of my day job was working in and around Exchange Server. If I had started this blog in 2005 it would have been dominated with posts around the Hosting of Exchange Server and probably be named Exchange is Life!. I take pride in my Hosted Exchange Org and User creation scripts that I created before Hosting Control Panels where even a thing.

Over the last five or six years my interest in Exchange diminished due to moving roles and also due to some lingering ill feelings about the way in which Microsoft treated their initial Hosting partners as they started what would become, Office 365 back in the late 2000’s. That said I have remained aware of the Exchange landscape and while there is still a lot of on-premises Exchange instances and still a number of decent Hosted Exchange providers out there, there is no stopping Office 365’s growth.

I even jumped on the bandwagon by moving my personal SliemaLabs domain over to an Office 365 Exchange subscription late last year. That domain initially lived on an Exchange Server I ran from home, and then on a Hosted Exchange platform I built and now it’s completed it’s own journey to Office 365.

Having spent a bit of time recently looking at the 1.5 version of our Backup for Microsoft Office 365 product…more specifically the new self service feature that came in Backup & Replication 9.5 Update 3. I’ve had a renewed sense of purpose around the Exchange ecosystem…and that purpose is to ensure that all service providers understand the opportunity that exists around creating offerings for the backing up and availability of Office365 services.

This post follows a post that was released on the Veeam.com blog by Paul Mattes (VP of Global Cloud Group at Veeam) talking about the success of our Backup for Microsoft Office 365 product.

In 2017, more than 25,000 organizations installed our Office 365 backup solution, representing 2.3 million Microsoft Office mailboxes. We saw a staggering 327% quarter-over-quarter growth in Q4 of last year.

And the reasons why all Office 365 users should consider an external backup solution for their data hosted in Microsoft’s SaaS cloud platform.

It’s important to remember that SaaS platform providers, like Microsoft Office 365, take on the responsibility of application uptime and the underlying infrastructure. But it is the customer’s responsibility to manage and protect their vital business data.

This is public cloud in a nutshell…Ultimately the customer has the responsibility to ensure all data is backed up correctly. I won’t go into the technical aspects as to why Office 365 requires additional backups solutions. There a plenty of good online resources, a Gartner report is available here Microsoft’s has an offical page on High Availability and Business Continuity guide. Doing research into the nature of SaaS you understand the need for third party backup solutions.

The Office 365 Opportunity:

From a service provider point of view there is an opportunity to tap into the 85 million user Exchange Online market and offer availability services for organisations using Office 365. This is a multi-billion dollar market that exists today and services based around backup and management of that data are central to tapping into that opportunity. Just breaking down the ANZ market alone, there are approximately 4.25 million Office 365 users of which if only 5% was captured would represent a combined 3.5 to 5 million dollar market.

For those VCSPs who have already deployed Cloud Connect and offering Backup services, the ground work has been laid with regards to having the infrastructure in place to extend that service to offer Veeam Backup for Office 365 aaS.

The billable components of this service are licenses and then storage costs. Managed Service Providers can also build in management fees that offer an end to end solution for their clients. Where it should be seen to be extremely attractive for VCPSs is in the potential for the storage revenue to be significant early and then continue to grow as tenant’s backup and retain more and more mailboxes in addition to new tenants coming on board.

We have given our VCSPs the tools to be able to build a strong service around Office 365 backups with the 1.5 release of Backup for Office 365 focused on scalability and automation. Add to that the self service feature that came in Update 3 for Backup & Replication and there is no excuse to not start thinking about offering this as a service.

Looking beyond Exchange Online, version 2 of Backup for Office 365 will include the ability to backup SharePoint and OneDrive as well…have a think about what that represents in terms of revenue opportunities just on the potential for storage consumption alone.

Again, I want to emphasis that this market is huge and what’s on offer in terms of potential revenue can’t be ignored. I’m excited about the next 12-18 months in being able to see our VCSPs grab this opportunity…don’t let it slip!

References:

https://technet.microsoft.com/en-us/library/exchange-online-high-availability-and-business-continuity.aspx

The Limitations of Microsoft Office 365 Backup

 

 

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

Quick Look: Veeam Agent for Linux 2.0 – Now With Cloud Connect

Just over a year ago Veeam Agent for Linux version 1.0 was released and for me still represents an important milestone for Veeam. During various presentations over the last twelve months I have talked about the fact that Linux backups haven’t really changed for twenty or so years and that the tried and trusted method for backing up Linux systems was solid…yet antiquated. For me, the GitLab backup disaster in Feburary highlighted this fact and the Veeam Agent for Linux takes Linux backups out of the legacy and into the now.

Yesterday, Veeam Agent for Linux 2.0 (Build 2.0.0.400) was released and with it came a number of new features and enhancements improving on the v1.1 build released in May. Most important for me is the ability to now backup straight to a Cloud Connect Repository.

Integration with Veeam Cloud Connect provides the following options:

  • Back up directly to a cloud repository: Veeam Agent for Linux provides a fully integrated, fast and secure way to ship backup files directly to a Cloud Connect repository hosted by one of the many Veeam-powered service providers.
  • Granular recovery from a cloud repository: Volume and file-level recovery can be performed directly from a backup stored within the cloud repository, without having to pull the entire backup on-premises first.
  • Bare-metal recovery from a cloud repository: The updated Veeam Recovery Media allows you to connect to your service provider, select the required restore point from the cloud repository and restore your entire computer to the same or different hardware.
Configuration Overview:

To install, you need to download the relevant Linux Packages from here. For my example below, I’m installing on an Ubuntu machine but we do support a number of popular Linux Distros as explained here.

Once installed you want to apply a Server License to allow backing up to Cloud Connect Repositories.

Before configuring a new job through the Agent for Linux Menu you can add Cloud Providers via the agent CLI. There are a number of cli menu options as shown below.

From here, you can use the cli to configure a new Backup Job but i’ve shown the process though the Agent UI. If you preconfigure the Service Provider with the cli once you select Veeam Cloud Connect Repository you don’t need to enter in the details again.

Once done and the job has run you will see that we have the backup going direct to the Cloud Connect Repository!

From the cli you can also get a quick overview of the job status.

Wrap Up:

I’ve been waiting for this feature for a long time and with the amount of Linux server instances (both physical and virtual) that exist today across on-premises, partner hosts IaaS platforms, or hyper-scale clouds, I hope that Veeam Cloud & Service Providers really hone in on the opportunity that exists with this new feature.

For more on What’s New in 2.0 of Veeam Agent for Linux you click here.

References:

https://www.veeam.com/veeam_agent_linux_2_0_whats_new_wn.pdf

Veeam Backup & Replication 9.5 Update 3 – Top New Features

Earlier today we at Veeam released Update 3 for Veeam Backup & Replication 9.5 (Build 9.5.0.1536) and with it comes a couple of very anticipated new features. Back in May at VeeamOn we announced a number of new features that where scheduled to be released as part of the next version of Backup & Replication (v10), however things have worked out such that we have brought some of those features forward into Update 3 for v9.5. It’s a credit to the Product Managers, QA and R&D that we have been able to deliver these ground breaking features into a Update release.

Together with Update 3 we have also released:

Focusing back on Backup & Replication…Update 3 is a fairly significant update and contains a number of enhancements and fixes with a lot of those enhancements aimed at improving the scalability of our flagship Backup & Replication platform. The biggest and most anticipated feature is the built in Agent Management meaning Backup & Replication can now manage virtual, physical and cloud-based workloads from a single console. Further to that we have added offical support for VMware Cloud on AWS and vCloud Director 9.0.

Below are the major features included in Update 3.

  • Built-in agent management
  • Insider protection for Veeam Cloud Connect
  • Data location tagging
  • IBM Spectrum Virtualize Integration
  • Universal Storage Integration API

Other notable enhancements and feature updates include supportability for 4TB virtual disks when using Direct Restore to Azure and support for SQL Server 2017 with that also now a possible database target for the platform. There is extended support for the latest Windows 10, Server and Hyper-V releases. In terms of storage apart from the addition of IBM support and the Universal Storage Integration API we added enhancements to Cisco HyperFlex, Data Domain and HPE 3PAR StoreServ as well as support for Direct NFS to be more efficient with HCI platforms like Nutanix.

For the agents you can now do backup mapping for seeding and restore from backup copies. For VMware there is a significant fix for a condition which reset CBT data for all disks belonging to a VM rather than just the resized disk and there is support again for non encrypted NDB transport.

There is also a lot of new features and enhancements for VCPS and i’ll put together a couple of seperate posts over the next few days outlining those feature…though I did touch on a few of them in the Update 3 RTM post here.

A quick note also for VCSPs that you can upgrade from the RTM to the GA build without issue.

For a full list check out the release notes below and download the update here.

References:

https://www.veeam.com/kb2353

 

« Older Entries