Ransomware is the worst kind of disaster because the latest clean restore point is unknown. As complex as disaster recovery (DR) is, at the end of the day simply point to the latest restore point and recover as fast as physics will allow. Cyber recovery (CR) on the other hand is far more difficult for several reasons listed in the table below. The main reason being that the latest clean backup is unknown. Often times the critical path to a successful cyber recovery is finding a clean restore point. Unlike DR restore points cannot just be restored directly back into production. CR requires workloads to be scanned by the latest AV signatures to ensure malware isn't being injected back into the environment. Without a proper incident response plan, data protection teams will spend days if not weeks restoring workloads for forensics/secops teams to scan only to find the restore points still infected. With Veeam v12.1 YARA (Yet Another Recursive Acronym) rules combined with multiple inline detection capabilities organizations can proactively find the latest clean backup without doing a full restore. Whether it is Veeam inline scanning or XDR tools detecting indicators of compromise (IOCs) YARA rules are a quick way to confirm the latest clean restore point. For example, below illustrates Veeam finding IOCs in the last two restore points. Once security has determined an attack is taking place and activated the incident response plan, YARA is a quick way to find the most recent clean backup. In this scenario, secops knows what malicious attack took place. Whether it's an encryption pattern, shellcode that exploited a vulnerability, specific text file, etc a YARA rule can quickly scan restore points until it finds a clean backup free of any IOCs. rule File_Encryption_Ransomware { meta: description = "Searches for indicators of file encryption ransomware" author = "Brad Linch" strings: $ransom_note_extension = ".txt" $encryption_pattern = "BMhmeWMfXgoRKUd7" $shellcode = { 31 C0 31 DB B0 05 CD 80 31 C0 31 DB B0 27 CD 80 } condition: any of them } The reason this is so much more powerful than mounting a backup and running AV scans is because a properly created YARA rule takes minutes to scan compared to hours for an AV scan. Below each restore point scan took a little over one minute on a 270 GB VM. Powerful stuff! As mentioned earlier though, no incident response team is going to simply scan a backup with a YARA rule and restore back into production. They are still going to scan with the latest AV signatures to ensure malware isn't reinfecting the environment. This is why Veeam still offers the ability to automatically scan backups with AV before restoring to prod. The combination of the two allows organizations to orchestrate the cyber recovery process. Use YARA and Veeam inline scanning to find what looks to be the latest clean backup quickly, and then use AV to do a final scan before restoring backing to production. YARA rules are powerful because there are endless possibilities in what they can scan for, but they are also daunting for that same reason. Below are a few YARA examples for different scenarios to help get started. Feel free to skim past if you don't care. :) Search for Hash Value Patterns: This YARA rule will look for md5, sha1 and sha256 hash files on workloads as this can be a sign of malicious behavior. Taking any hash files found and searching in tools like Virus Total can inform you if the file is known to be malicious. rule HashSearch { meta: description = "Searches for specific hash values in files" author = "Brad Linch" strings: $md5_hash = { [0-9A-F]{32} } $sha1_hash = { [0-9A-F]{40} } $sha256_hash = { [0-9A-F]{64} } condition: any of them } Search for Zero Day Exploits: XDR tools and signature based scanning tools don't know what they don't know. Below is an example of a YARA rule to scan for zero day attacks by looking for shellcode deployed, executed bash scripts and specific key words that might be signs of an attack. rule ZeroDayDetection { meta: description = "Searches for indications of potential zero-day attacks" author = "Brad Linch" strings: $shellcode = { 31 C0 31 DB B0 05 CD 80 31 C0 31 DB B0 27 CD 80 } $cmdline_pattern = /(powershell|cmd|bash) ([A-Za-z0-9]+[-_\w]\b ?) $exploit_pattern = "exploit" $evasive_behavior = "sleep" condition: any of them } Search for Malicious Files: Below is an example of searching for specific malicious file. rule Detect_Malicious_Files { meta: description = "Searches for indicators of malicious files" author = "Brad Linch" strings: $rar_exe = "Rar!\x1a\x07\x00" $pe_executable = "MZ" $pe_exports = "USER32.dll" condition: any of them } Suspicious Network Connections: Lastly, is a YARA rule example searching for IPs in log files as potential suspicious network connections. rule Suspicious_Network_Connections { meta: description = "Searches for suspicious network connections in logs" author = "Brad Linch" strings: $ip_pattern = /[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]+/ $domain_pattern = /(\w+\.){2,}\w+/ condition: $ip_pattern or $domain_pattern } Conclusion: The elephant in the room in a lot of these discussions I have with organizations is do you really have a cyber recovery plan or do you have a disaster recovery plan. They are two completely different events to plan for. Cyber Recovery requires planning on how to find the latest clean backup as quickly as possible, how to restore to an alternate location if the primary DC is completely off limits, and identifying mission critical workloads you need to restore first as fast as possible.

One of the most common questions I'm asked from both partners and prospective clients is, "Why Veeam?" Immediately my mind goes everywhere from how R&D and Product Management operate to ensure quality and content meet the market needs to Veeam's specific capabilities that keep businesses running. I'll save you the soliloquy though and boil it down to 5 reasons I see companies choose Veeam: #1 - Total Cost of Ownership Veeam's ability to immediately plug-and-play in any datacenter on day-1 is a huge advantage to both IT and finance. Being software-only enables clients to leverage existing or repurposed hardware with Veeam. Whether it is a dedupe appliance like Data Domain, JBOD servers like Cisco, Dell, HPE or NAS/Object storage on-prem or in the cloud Veeam can put that gear to work. Not only will Veeam take advantage of those as backup targets, but also integrate with them in a way that provides immutable protection. With over 90 hardware integrations it is easy to design an economical solution. #2 - Fastest Recovery Options Ransomware is relentless and top of mind for every organization. It has always been important to properly design for recovery in case of disaster, but now designing for recovery is more critical than ever as ransomware is the worst and most common type of disaster. Gartner recently published a report on how recovering from ransomware requires a multi-layered recovery plan. Veeam is the only vendor in the backup industry that offers restore capabilities at no a-la-carte pricing from backups, replicas and snapshots. Backups - Because Veeam is software-only you can design a solution that backs up mission critical data to all-flash storage providing the fastest recovery from backup possible Replicas - the terminology replica is used a little to loosely in the backup industry, but when Veeam talks about replicas we are talking about true DR and fastest RTOs possible because our replicas are actual VMs that already spun up with the latest changes applied. Simply need to right-click and hit failover and the time to recover is the time it takes to boot up a machine Snapshots - Veeam integrates with dozens of primary storage vendors to provide the ability to recover from snapshots whether we orchestrated those snaps or not. I have seen several examples of us helping clients recover from ransomware attacks by performing Instant VM Recoveries off their secondary primary arrays which is much more performant than restoring from spinning disk backups You don't have to just take my word for it though. A study done by IDC found that Veeam offers 5x faster recovery than the industry average. #3 - Single Platform for On-prem, Cloud and SaaS Terminology like single pane of glass and single UI are thrown around liberally in IT. Veeam is dedicated to being the vendor organizations can turn to for any workload though. Whether it's SaaS offerings like M365 or SFDC, PaaS services like AWS RDS or Azure SQL, containers on any of the major distributions or databases like SQL, Oracle, HANA, DB2, etc, Veeam has your back. All with native APIs to enable organization to automate any task. #4 - Multi-cloud Mobility I see many organizations moving to cloud for their DR strategy. It is a great idea in theory, but several don't test or understand what recovery times would like if their on-prem datacenter were to be hit by a disaster or a ransomware attack. With Veeam though from the same console and license file users manage both cloud and on-prem workloads. The true beauty of this is the ability to restore and move data cross-platform. Whether it's VMware to AWS, AWS to Azure, GCP to VMware, etc. It does not matter. Any permutation you can think with VMware and the three major cloud providers Veeam can move and restore that data. I have seen clients who's primary DC was off-limits due to a ransomware attack as cyber-insurance companies and/or three letter agencies did their investigations. Luckily with Veeam, their ability to restore virtual or physical machines directly into AWS, Azure or GCP is what kept their business running. #5 - Proven at Scale Veeam's commitment to security to meet enterprise needs is a top priority. The proof is in the pudding with certifications like DoDIN APL, Common Criteria, FIPS 140-2 and many others highlighted here. Veeam's focus on security and ability to scale is what leads to success and numbers shown below. We wouldn't be in 81% of the Fortune 500, have over 1,400 federal accounts and have deployments in the tens of thousands of machines both on-prem and in the cloud if security and scalability weren't top of mind for R&D and PM. In addition to our commitment to the enterprise, is our support organization. With a satisfaction rate of 98% and 11 locations around the globe (3 in the North America) Veeam is committed to solving customer issues as quickly possible. We even have a support arm dedicated to ransomware cases nicknamed the Ransomware SWAT Team. Any case tagged with ransomware is routed to them and their average time to resolution is 16 hours. Conclusion The list can go on and on but luckily for you I've learned from earlier in my career folks don't want the monologue answer to, "Why Veeam?" These are the main reasons I see prospective clients become clients. To sum it up, Veeam offers the best balance between cost, performance, ease-of-use and security the industry can provide.

This will be one of the shorter posts but it is a sweet one! Password rotation with Veeam is something that is starting to come up more often. Rather than point folks to Veeam's PS and API guide, I thought it would be nicer to point folks to an actual script. Below is a script used recently for a customer to rotate their VBR admin password daily through CyberArk,. This script will get the Veeam admin password from CyberArk and then set the VBR credentials. Certainly doing this daily might be overkill, but you get the point. Could have this run every 90 or 180 days. Whatever meets your security standards. add-type @” using System.Net; using System.Security.Cryptography.X509Certificates; public class TrustAllCertsPolicy : ICertificatePolicy { public bool CheckValidationResult( ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) { return true; } } “@ [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy [System.Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 # CyberArk API Endpoint and Credentials $CyberArkURL = "enter CyberArk URL" #$CyberArkUsername = "YourCyberArkUsername" #$CyberArkPassword = "YourCyberArkPassword" # List of Veeam Server Information $VeeamServers = @("VBR1_ip", "VBR2_ip") $VeeamCredentialName = "service_account" try { # Authenticate with CyberArk (if necessary) # $CyberArkCredential = New-Object System.Management.Automation.PSCredential ($CyberArkUsername, ($CyberArkPassword | ConvertTo-SecureString -AsPlainText -Force)) # Make a GET request to CyberArk to retrieve the password $CertStorePath = "Cert:\LocalMachine\My" $Certificate = Get-ChildItem -Path $certStorePath | Where-Object {$_.Thumbprint -eq "thumbprint"} $result = Invoke-RestMethod -Method "Get" -Uri $CyberArkURL -Certificate $Certificate if ($result -ne $null) { # Extract the password from the response $VBRpass = $result.Content # Loop through the list of Veeam servers foreach ($VeeamServer in $VeeamServers) { # Connect to Veeam Backup Server Connect-VBRServer -Server $VeeamServer # Set the retrieved password for the Veeam credential Get-VBRCredentials -Name $VeeamCredentialName | Set-VBRCredentials -Password $VBRpass # Disconnect from the Veeam Backup Server when done Disconnect-VBRServer -Confirm:$false } } else { Write-Host "CyberArk did not return a valid password." } } catch { Write-Host "An error occurred: $_" }

The two most common business level objectives for any IT organization these days are ransomware protection and reducing cloud spend. Recently, I spoke to an organization that's reduced their cloud spend by nearly $2 million since switching to Veeam at the end of 2022. The goal of this post is to help other companies reap those same benefits. Many cloud native backup solutions and vendors in the backup industry take a snapshot instead of a backup when protecting cloud native workloads. Similar to on-prem workloads, a snapshot is naturally much more expensive to retain than a backup. For the big three cloud platforms (AWS, Azure, GCP) a snapshot is about $.05/GB per month, whereas storing data in object storage is roughly $.02/GB per month. Might just sound like pennies but it adds up quickly. For example, 100 TBs of snapshot data would cost the business $60,000 a year, whereas that data stored in object storage would be $24,000 a year. How Veeam helps: Veeam's Cloud Protection Groups protect cloud native (AWS, Azure and GCP) workloads directly to their cloud native object storage (S3, Blob and GCS) without any snapshot or additional compute to move the data. No additional compute is key to the overall total cost of ownership in a cloud protection solution as many other options in the industry will need proxies or media agents to move data to object storage. These compute costs can become costly over time. Protection Groups is a concept within Veeam for many years. They are a way to categorize and organize workloads, whether they be physical machines, databases or cloud machines. Protection Groups centrally manage endpoints for all workloads via an agent that also acts as a data mover eliminating any additional compute costs for backups. Quick How-To: Simply enter in the credentials to your AWS, Azure or GCP account/subscription/project and choose the region of the machines to protect. Select machines individually for the masochists out there or simply insert a tag to catch-all the workloads to protect. A role with the following permissions needs to be attached to each instance you want to protect in the case of AWS. Veeam automagically can create and assign those roles which makes life a lot easier for organizations with hundreds or thousands of workloads to protect. Below is a high-level architecture of how this looks. One of the core differentiators aside from cost savings, is the ability to restore any workload anywhere. Doesn't matter if it is an on-prem physical or virtual machine to AWS, Azure or GCP. An AWS EC2 back on-prem or to another cloud. Any permutation for cross workload restore is supported in just a few clicks. Veeam does the v2v conversion under the covers. Right-click on the machine you want to restore/move and start restoring back to original location or to a different one. In summary, there is no other backup solution on the market that can save companies thousands if not millions in yearly cloud spend, while also being easy to implement and manage. IT admins can be heroes to their management by proposing cost saving solutions especially in the current economic climate. Hope this helps!

When I was a kid my mother told me never talk about politics, religion or money. Luckily, she'll never read this. I'm pretty sure she thinks I sit in a basement and do something that involves backing up iPhones. I can promise we won't touch politics or religion though, but we are most certainly going to talk money, and more importantly, how to help reduce IT cloud spend. All three major cloud vendors (AWS, Azure, and GCP) offer native backup options. The main advantage being ease of deployment as it's just a checkbox to enable for the most part. As companies move workloads or create net new workloads in the cloud it's common the data protection team is left behind as cloud admins will manage the backups themselves. This quickly becomes unsustainable though both from a cost and management perspective. Sifting through monthly cloud bills to find backup costs is not as easy as one might think. To understand the total cost of ownership (TCO) associated with protecting cloud workloads, management needs to know what cloud vendors charge to protect the workload and storage the backups consumes on the backend. Finding that backend storage cost is not always so simple. To help give you a snippet below is the monthly cost to protect workloads using the native backup tools cloud vendors offer. This can quickly become very expensive. For example, protecting an 800 GB SAP machine in Azure would cost nearly $2,500 a year! Protecting a 1 TB SQL machine in GCP would cost about $1,000 a year. Now, AWS looks much more affordable at first glance but services like EC2 cannot be backed up to S3 with AWS Backup, so the storage costs become hefty. Not to mention the problem of snapshot sprawl as many of these snapshots are forgotten about and linger for months or even years longer than intended. Let's look at a TCO in a larger scale exercise to help paint a better picture. Let's assume: We have 130 cloud VMs that need protection Each workload is 1 TB Has 5% change rate 30 day retention Backups do not get dedupe and compression with native tools as stated on their sites Azure Backup TCO Example: As we can see below the total yearly cost for just 130 workloads quickly adds up with native Azure backup. For the nerds (like myself) who want to know how I came to these numbers, I added up the full backup of each workload plus the total for incremental backups for storage costs. In the Azure VM row that would be 250 TBs *.0224 = $67,200. Then I added the backup costs to protect 100 Azure VMs which is 100 instances * $20 *12 = $24,000 which is a total of $91,200. Remember Azure charges by the 500 GB increments, so the backup charges are $20 per month for a 1 TB machine. GCP Backup TCO Example: GCP is around the same cost at Azure. I won't bore folks with the basic math equations again. Think you get the gist. AWS Backup TCO Example: AWS is much cheaper in comparison as there is no backup costs. Protecting workloads in AWS is free, but the storage is nearly 2.5x the price! Veeam Backup TCO Example: The goal of this post isn't to scare folks from ever protecting workloads in the cloud. It is to show a cost effective solution while not sacrificing any simplicity or functionality. If anything also gaining functionality. The cost savings by using Veeam to protect cloud workloads can be huge for several key reasons: Storage costs are minimized with a reliable 2:1 dedupe/compression Costs associated with snapshots to backup workloads can be significantly reduced if not eliminated altogether if Veeam's native cloud agents are used It is the same reasonable backup cost to protect a cloud workload regardless what application it is running or how large the instance is There's more to life than money though. As alluded to earlier, there are also additional capabilities Veeam provides that native cloud backup does not. The major differentiators I see resonate are VPC backup, data mobility cross cloud platforms (restoring an AWS EC2 to an Azure VM and vice versa) and ease of management under a single UI. Below are additional capabilities for each cloud platform. It's never fun to talk about money, but in this economy it's important to find ways to save yourself and your company money. Protecting cloud workloads with Veeam is the best of both worlds - saving money without sacrificing functionality. Oh and please don't tell my mother about this post.

At VeeamON 2023 Veeam announced numerous features and enhancements coming in v12a! Many were related to security, such as inline malware detection, malware-aware DR and clean backup finder. Similar to you, I can't wait to get my hands on these features, but it will have to wait for another post. Currently, v12a is in Technical Preview and includes two other major announcements from VeeamOn - Object Storage and DB2 protection. Object storage is the source data for many critical workloads, and it's only becoming more common. For example, you can run VMware VMs on S3 storage and many organizations use S3 as mount points for their cloud workloads. As this shift happens, it is important to protect this data the same way you would protect source block data. In addition, Veeam's DB2 Plug-in will be the 5th native database plug-in for Veeam. The benefit of database plug-ins is that it empowers DBAs to leverage their native tools, while also providing visibility and governance for the backup administrators. Enough chit-chat though. Let's see these in action! Object Storage Protection: On day 1 all object storage platforms will be supported as source data to protect. In my example below, I will backup AWS S3 buckets. You can already see a backup has been performed and immutability is set on the destination. Don't worry! I'll show the basic setup. Just like to show the fun stuff first. And as you can see below even if I try to delete the backup files it fails because immutability is set. Great protection against an attacker that we have for all workloads already today. Getting started is simple. Add an AWS account with proper permissions. At a high-level the ability for PUTS, GETS and DELETES. Official documentation will come out closer to release date. Once an account is added it is time to create a backup job. I only have two S3 buckets in my account, but you can choose which buckets to protect. In addition, you do not have to protect the entire bucket. You could choose a subset. All the expected restore functionality is available day 1. Can restore a granular file, rollback to a specific point in time, or my favorite option, which is to restore an entire file share to a different location! In the below example, I restored my AWS S3 bucket to an Azure Blob container. Pretty cool if you ask me! DB2 Protection: This section is more for the geeks at heart, and I am right there with you. It had been close to 10 years since I last played around with DB2. The difficult part of this was installing DB2. After that, as you might expect, the Veeam piece "just worked." Take note below that I am connected to the sample database and the results my basic query returns. The installation and setup of the DB2 plug-in is similar to other Veeam database plug-ins. Simply point to the Veeam config tool and your backup server, repository and a few basic variables. Next, DB2 DBAs can run backups and restores using the same DB2 commands they're familiar with. As we can see, sample database is being protected, and the backup admin would have visibility into this from their console. What good is a backup without a restore though? Don't worry. That is a rhetorical question. A common task for any DBA is to clone a backup. Essentially restore yesterday's backup to do some analysis or corruption testing. As you can see below, the DB2 DBA can restore our sample database but as sample5. After connecting to sample5 we can see the same query returns the same results on sample5 as it did on sample earlier. Conclusion: Hope this post gets you excited for v12a! Veeam is constantly iterating and bringing the features customers ask for to market. This is just a small taste of what is to come. Once 12a moves from technical preview to an official beta release, we will get our hands dirty with all the security enhancements for the next post. Cheers until then.

Veeam's Data Protection Trends report with over 4,000 anonymous companies found that 85% of organizations have experienced some form of ransomware in the last year. Given that a ransomware attack has a far greater chance than a natural disaster, power outage or other DR type event, it's critical that IT organizations plan for quick recoveries as discussed in a previous post. A crucial component for successful quick recoveries though is identifying the last known good backup. Without this organizations can spend countless hours if not days attempting to restore data that is already corrupted. It was discovered in this same data protection report companies took between one and two weeks to recover their data on average. This is by far more time than recovering from other DR type of events due to the fact that much of the time is spent identifying and scanning for the last known clean backup to restore from. Veeam has a three tiered approach to helping companies identify the best point-in-time (PIT) to recover from: Identify suspicious behavior on the actual production VMs (VMware and Hyper-V) Identify anomalies in the underlying backup files Automatically scan backup files before restoring machines into production Identifying Suspicious Behavior on the VMs: Making sure there is a recoverable backup is just one step, but it is also important to monitor the entire environment for suspicious or unusual activity. Veeam goes beyond just looking at the backup data for anomalies. It looks at the hypervisor and network level as well. These higher-than-normal writes on disk or CPU utilization could be a sign that ransomware infected the machine. The goal of the alarm is to pinpoint the machine that is potentially infected before it can propagate to other systems. The key to this alarm is the historical view though. This is useful to help identify when ransomware potentially took place and which backups are a good place to start for recovery. Identifying Anomalies in Backups: Veeam's Suspicious Backup File Size Analyzer lives up to the name. This alarm identifies patterns in your backup data. It analyzes backups to look for large number of file and block changes to the data. If an anomaly is detected an alert is sent to the system administrators. This alarm can be easily integrated into the main Veeam console thanks to a brilliant script from Steve Herzig! If an anomaly is detected it will show in the job statistics. Simply take the script from github and place it in the post-script section of your backup jobs. Specify how many previous PITs you'd like it to analyze in the "Depth" field and what amount of growth would be considered suspicious in the "Growth" field. These first two steps give the business a good idea which PITs to recover from. Without these steps ransomware is the worst kind of disaster because countless hours or even days are spent manually identifying when to recover from. Automatically Scan Backups Before Restoring: Lastly, whether is it proactively or reactively scanning backups for malware, Veeam can scan backup files prior to restoring machines into production. If malware is found you can either abort the recovery or restore without attaching a network for deeper forensics. Organizations can use any scanning tool that has a CLI. For example, Trend Micro, Bitdefender, Windows Defender, etc. Simply edit the XML file here. Conclusion: Veeam is on a mission to help customers recover from ransomware. I have personally seen Veeam be the heroes many times for organizations. Veeam believes combining the above steps to identify a clean PIT with the fastest recovery options available in the marketplace is a great recipe to help IT organizations sleep well at night.

By now you've probably heard about many exciting features in Veeam v12. While security and direct-to-object storage enhancements have been the talk of the town, I want to spend time discussing my favorite v12 enhancement. Veeam is adding SQL to their database plug-in offerings! The power battle between DBAs and backup admins over who owns database protection is a story as old as SQL itself. Backup admins want control over backups because their job requires owning SLAs for all the workloads in the company. DBAs want control over backups because simply put, they're their databases. Neither side is wrong. If anything both sides are right. Which is why this internal struggle in organizations has gone on for decades. Veeam is well aware of this issue which is why there are database plug-ins for Oracle and SAP already. Now, there is one for SQL. Having a database plug-in enables DBAs to drive backups and restores of their databases from the native tools they're accustomed to. In the case of SQL, this would be right from SQL Server Management Studio (SSMS) as shown below. The plug-in integrates with SQL's VDI device to backup the entire contents of the database whether it's a full, differential or transaction log rather than VSS which requires a snapshot. This is a win-win for both the DBA and the backup admin because from the Veeam console you still have full visibility and governance capabilities. Configuration of the plug-in requires the Veeam server's DNS/IP and a Veeam repository which enables backup admins to monitor the database backups and still comply with any potential audits. Creating a backup in Veeam's SQL Plug-in should look nearly identical to anyone who has created a SQL native backup before. As you can see below, you select which databases you want to protect and whether you want a full, differential or T-log backup. Next, you select the retention for these backups, parallel streams and if you want compression enabled. Unlike pre-v12, retention is applied at the database rather than server level since the plug-in integrates with SQL VDI instead of VSS. One of my favorite features is the option to, "Save as a SQL Agent Job" as shown above. This will automatically create a SQL CLI script that is saved to the Server Agent jobs sections of SSMS based on the settings applied above. Simply apply a schedule to the job and you'll be cooking with bacon. What's the point of backing something up though if you don't plan to restore it? From the plug-in you can trigger a restore that will look almost identical to a SQL native restore. Select the database and restore point of your choosing. You can restore to the original location or a different one. For example, DBAs might want to restore a database from yesterday's backup to run a DBCC CHECKDB command which is easy to accomplish here. Lastly, choose the preferred recovery state for the database. If a DBA is still reading this, you might be wondering why would we even use the plug-in since this looks identical to SQL native backup and restore options? That is exactly the point though. The goal with the plug-in is to keep the process similar to what SQL DBAs do today, while also providing the backup admins visibility and monitoring capabilities to report up to management or auditors. Here is a video walkthrough!

The Epic software suite is the most critical application for healthcare providers today and is vital to patient care and continued operations. Epic makes software for midsize and large medical groups, hospitals, and integrated healthcare organizations - working with customers that include community hospitals, academic facilities, children's organizations, safety net providers, and multi-hospital systems. Their integrated software spans clinical, access, and revenue functions and extends into the home. Veeam protects everything within EPIC software suite including the hyperspace management VMs, web and service tiers VMs, web blob, analytics database (Clarity) and most importantly the InterSystems Caché/IRIS database. Within the EPIC Suite, InterSystems Caché/IRIS database, is the main access point for persistently stored medical records. Epic recommends the following best practices for the architecture and protection of this database: Epic’s Production ODB (Caché) Server should have no additional 3rd party software be installed (no agents) on the server itself to guarantee stability and reliability to the server. The underlying volumes of the EPIC ODB Server should be served by high performing storage presenting through RDM LUNs and not VMDKs. Epic recommends that backup of the production Caché/IRIS database leverage a secondary host when using RDM LUNs so that backup operations do not adversely affect production performance. A scripted a hardware-based LUN clone of the backing RDM LUNs to another host for backup is recommended to reduce the impact on backup operations on the production database. To meet these requirements a typical backup for an InterSystems Caché database follows the below workflow: Veeam meets these requirements to protect the EPIC Cache/IRIS database in a completely agentless, file-level backup approach. This creates a highly performant backup and restore because Veeam is able to stream multiple .DAT files in parallel which are the files that make up the database. For example, in the below screenshot we can see that Veeam protects a 9.1 TB EPIC database in one hour and 34 minutes. That is 5.8 TBs/hr. This is because a file level approach to protecting EPIC's database allows for as many parallel streams as desired to protect multiple .DAT files simultaneously. The secret sauce to Veeam's approach though are the restores. EPIC imposes strict guidelines on restore speeds that must be met in order to be in compliance. Multiple or all of the .DAT files desired can be restored in parallel. That same 5.8 TBs/hr for backup was also achieved for restore in this test because the same file engine technology is leveraged. The benefits of the Veeam solution to protecting EPIC is an agentless approach that can be highly performant. EPIC is typically the most critical data to a healthcare company's environment and Veeam matches that criticality with a unique approach to meet the strict backup and restore windows EPIC requires from their user-base.

As enterprises mature in their cloud journey more and more are pivoting to the idea of not putting all their eggs in one basket. 81% in fact according to a Gartner survey. In the customer meetings I attend this statistic seems to hold true because a multi-cloud approach enables firms to structure the most cost effective solutions depending on the SaaS/PaaS/IaaS applications that fits their needs best. A multi-cloud strategy though creates concerns around data protection, ability to migrate, and application uptime. Today, Veeam addresses some of these concerns, but we are about to set the market for true multi-cloud data management come v12! Veeam's next product release provides the ability to copy data from one cloud provider directly into another, while making it simple to recover and convert from any workload to any workload. All clicks away. No professional services or scripting required or needed. For those who need more than just my word, let's dig into how this will work come v12. Let's create a scenario: There are AWS EC2 instances that need protecting into S3 over EBS snapshots to keep costs minimal In addition, the business needs a second copy offsite to either GCP or Azure out of concerns for uptime and vendor lock-in Lastly, the solution needs to prove it can restore/convert the original AWS EC2 instance into a running Azure IaaS and GCE VM Below is a high level illustration of what we are about to accomplish. This scenario would work for any permutation of the three major cloud providers. First, let's start by protecting AWS EC2 instances. I'll spare you the details of showing each step to a policy, but you can find more information here if interested. This policy will backup our EC2 instances to an AWS S3 bucket. The main advantage of this solution over cloud native are the granular recovery options and cost. S3 is $.02 per GB list price whereas AWS Backup EBS snapshots cost $.05 per GB list price. Second, add the AWS S3 bucket to your main Veeam server as an external repository. This will import all your EC2 backups. Third, add an Azure storage account and Google Cloud Storage for our secondary offsite backup copies. Fourth, create backup copy jobs (offsite backups) of the EC2 backups to Azure and GCP. Fifth, right click on your backup copy job to see all the restore options available. As you can see, VMs in all three major cloud providers can be instantly recovered in VMware as well, but let's not lose focus. Let's restore this VM that was originally an EC2 instance to an Azure VM. Once you go through the steps of selecting VNet, resource group, instance type, etc, you will see the below high-level logs. Veeam performs the conversion process and then restores the EC2 instance as a running Azure VM. For the grand finale, we can confirm that the Azure VM is up and running. It is the same exact steps for GCP and for any permutation when going from one cloud to another cloud. Wow! In just five steps Veeam copied and recovered data from one cloud to another. All within a few clicks. Veeam continues to deliver capabilities based on customer needs, and this is yet another example of that. Leveraging multiple clouds affords companies the flexibility and savings necessary to maintain agile operations. Veeam takes another step forward in making multi-cloud data protection and management truly possible for enterprises.

If you use Veeam and aren't taking advantage of Veeam ONE's breadth of capabilities, you are missing out. Veeam ONE is part of Veeam Availability Suite (VAS), which is a combination of Veeam Backup & Replication (VBR) and Veeam ONE (VONE). I discover in most my end-user conversations that either owners of Veeam ONE vastly underutilize it, or they didn't spring for VAS and are in need of many VONE capabilities. Today, I want to focus on VONE's 10 best alarms to enable as part of a ransomware defense strategy. This will just be a fraction of what VONE can do as there are over 350 reports and 150 alarms. The possibilities are endless as VONE ingests data from vSphere, vCD, VBR, AWS, Azure and GCP and has API integration for those who want to showoff. 1. Possible Ransomware Activity Possible Ransomware Activity analyzes on a per-VM basis anomaly like behavior. For example, spikes in CPU or datastore usage rates, both of which can be signs of encryption. The key to this alarm is the historical view though. Understandably, the first thing a business wants to do in a ransomware attack is recover data, but from what day do you recover from? How can you be sure you haven't been backing up encrypted data for days or even weeks? The historical view enables users to pinpoint the day ransomware potentially took foothold in the environment. The above shows spike in CPU and the below shows spikes in datastore usage rates. 2. Attempted Backup Deletion There are two scenarios an attacker will attempt to delete backup data. The first is the hacker will gain access to the backup console and start deleting backups. The second is the hacker will try to access the backup target itself and remove files from there. We will cover both , but let's focus on the first. This alarm will notify users if a bad actor has gained access to the console and is trying to delete backups and which account they've compromised. Deleting backups is a custom alarm that can be enabled by creating the below rule as shown. 3. Suspicious Backup File Size VONE analyzes previous backup sizes and alerts the user if backup sizes look out of the ordinary. Larger backup files can mean there is a lot of natural changed data, but it can also mean encrypted files are being backed up. 4. Unusual Job Duration Along the same lines a job that runs an unusual amount of time can be a sign of protecting encrypted files as there would be much more changed blocks to backup. 5. Job Modification Audit Sticking with scenario one where a bad actor gains access to the backup server, they might start editing or deleting jobs. This report will inform you who's account is making changes and when they made them. Knowing exactly when the ransomware attack started can be powerful knowledge in a recovery scenario so cycles aren't wasted recovering invalid data. 6. Immutability Retention Modified Immutable backups are for the second scenario where the hacker attempts to gain access to the backup target itself. By leveraging Veeam's immutable repository this becomes nearly impossible as Veeam doesn't store the credentials to that server. Furthermore, SSH can be disabled on the box, so now the hacker would need both physical access and credentials from somewhere outside Veeam. 7. State of Immutability The best bet by a hacker at that point is to gain access to the backup server and reduce the amount of immutable copies going forward or turnoff immutability altogether. In both scenarios users would be alerted. 8. Disabled Jobs It might sound basic but setting alerts on disabled jobs can be a great way to notify the business something is afoot. It is not uncommon in a ransomware attack for a hacker who gained access to the backup server to disable backup jobs. The rule for the alarm can be set down to 1 minute, so you are notified nearly instantly. 9. Failed vCenter Logon Attempt Who isn't guilty of a fat finger? I sure am. Certainly this will create some false positives, but you can set the alarm to only notify if x amount of failed logon attempts have taken place. Albeit a hail marry, this could still potentially alert you of a bad actor in the network. 10. vSphere Modifications As was first mentioned, VONE is a powerful tool capable of many things. Ingesting vSphere data is one of those. Users can receive a report on modifications made within vCenter. This can be great for real-time monitoring, but also for trying to pinpoint which account was compromised and when. With Veeam ONE the possibilities are endless. This post was a peak behind the curtain into what VONE can do. There are hundreds of additional reports and alarms and many additional use-cases users have accomplished through API and/or PowerShell integration. For those who want to keep digging into the power Veeam ONE offers below are my 5 favorite blog posts from the Veeam community. The Power of Veeam ONE Pro Tips with VONE VONE integration with Slack VONE integration with ServiceNOW My favorite VONE alarms

If you still think Veeam only protects VMs you are stuck in 2015. Fortunately for you, I would be lucky to get you to the next paragraph if I dove into everything Veeam can protect, so I will narrow it down to just NAS. More specifically, Veeam's integration with Dell EMC Isilon. Veeam leverages Isilon's ChangeList API for their SnapshotIQ technology during the backup process to grab only the deltas (changed files and folders) between the current and previous snapshot. Veeam only keeps one snapshot per share on the Isilon. Once the next snapshot is taken the previous is deleted. Minimizing the amount of snaps needed on Isilon can be a massive space saver if the business is retaining 30-plus days worth of snapshots. The integration between Veeam and Isilon allow for both fast backups and potentially reduced consumed space on the Isilon itself. Increased performance is great and all but saving the business money is even better. In addition to faster backup speeds and less snapshots retained, Veeam provides the capability to instantly recover a share to the same or alternate server whether it is an Isilon or not. Rather than spend money on multiple Isilons for replicas, you can backup your Isilon to something more cost effective and instantly recover file shares in a disaster scenario. Now, while the main purpose of this post is to inform you of the business value Veeam brings to the table by integrating with Isilon, I also enjoy getting my hands dirty. The rest of this post is a runbook on how to setup/configure Veeam and Isilon together. NOTE: There are a couple references to Veeam's upcoming v12 release and the enhancements around NAS. Brownie points if you can call out what they are in the comment section. Isilon Setup In order for Veeam to leverage Isilon's Snapshot IQ technology, Veeam needs a role with the proper permissions as described here. Instead of making you read that document and manually enter in each privilege though, you can simply take note of the screenshot and Isilon CLI commands below if you prefer. isi auth user create veeamadmin --zone System --enabled True --set-password isi auth roles create --name VeeamStorageIntegration --zone System isi auth roles modify --zone System VeeamStorageIntegration --description "veeam backup role" isi auth roles modify --zone System VeeamStorageIntegration --add-priv ISI_PRIV_LOGIN_PAPI --add-priv ISI_PRIV_AUTH --add-priv ISI_PRIV_DEVICES --add-priv ISI_PRIV_NETWORK --add-priv ISI_PRIV_NFS --add-priv ISI_PRIV_SMB --add-priv ISI_PRIV_SNAPSHOT isi auth roles modify --zone System VeeamStorageIntegration --add-user veeamadmin isi auth roles view Practice --zone System This creates a custom "VeeamStorageIntegration" role with the user "veeamadmin" associated to it. This role/user needs to be created in the System zone. The BackupAdmin role that comes out of the box with Isilon does not have sufficient permissions. Lastly, apply the service account you use to any share that needs protecting. We will use this same service account when we add Isilon in the Veeam console. Veeam Setup From the Veeam server add the Isilon storage system as described here using the "veeamadmin" user we created above. You can use a root user but the user/role we created is more granular if you prefer. The documentation does a great job guiding you through this step-by-step, so no need for me to plagiarize. Next, add the Isilon under NAS Filer in the Inventory section using your backup service account that was added to the SMB shares. Check the "Use native changed file tracking" box to ensure you leverage the Isilon SnapshotIQ integration. Now, it's time to create a backup as described well here. During the backup Veeam creates a snapshot on Isilon as shown below. In my lab, the original backup was 14 folders and 312 files as I am just protecting a small share here for instructional purposes. The next incremental run compared the previous and current snapshot and only found 2 new folders and 7 new files making the backup very performant. BONUS: See the immutability line item? To prove I'm not full of it, you can also see the snap in Isilon under Data Protection > SnapshotIQ. With Veeam v12 coming out later in 2022, NAS backups can target an immutable repository. My lab is using an Object-Lock enabled AWS S3 bucket as the target. There is no way to delete those backups from the Veeam console until the natural expiration date is applied as shown below. In addition, if you login to AWS as a root user and call support they will tell you, "Too bad. We want your storage money." The Money Saver Like I mentioned in the beginning, faster backups are great but saving money is better. Many companies store weeks if not months worth of snapshots as well as replicate shares to another Isilon in a DR site. This can be costly if you rarely use your secondary Isilon, or it's main purpose is only for DR. Leveraging Veeam can both reduce the consumed space from snaps as well as replace the replica Isilon with a more cost effective solution. Instant File Share Recoveries enable companies to store backups in something cheaper and deeper, while also providing quick recovery to the same or alternate server. For example, you could instantly restore to a windows share and have immediate user read/write access. Starting in v12, instant recoveries of SMB shares in a read/write state will be available as well as NFS shares in a read-only state. In addition, companies will have the ability to migrate the share back to the original source or to a new server. Whether it's the fact that site A is never coming back or simply the business is shifting away from Isilon, you will have the ability to recover NAS data quickly and affordably. In summary, Veeam's integration with Isilon enables companies to protect their data fast, reduce the amount of snaps taking up consumed space and quickly recover data in a cost effective way.