Databases are at the heart of many business‑critical applications and services. They underpin essential functions such as order processing, billing, inventory management, customer portals, analytics, and much more. When a database becomes unavailable, the consequences are immediate: users lose access to vital information, business operations are disrupted, and reputational damage can quickly ensue.

To ensure business continuity, organizations set strict recovery point objectives (RPO) and recovery time objectives (RTO) for their most critical databases. Having a backup alone isn’t enough; you must be able to restore swiftly to a recent point in time. Achieving these demanding recovery targets for self-managed databases on Amazon Web Services (AWS) becomes increasingly difficult as the environment expands in scale.

By using Amazon FSx for NetApp ONTAP as the backbone of your data infrastructure, you can optimize platforms such as SQL Server, Oracle DB, MongoDB, SAP HANA, and others. For many demanding workloads with strict SLAs, FSx for ONTAP is often the only service that enables these databases to run reliably and at scale on the AWS Cloud. In this post, I am going to explain how this is achieved.

Here’s what we’ll cover:

• Navigating database resilience challenges: Meeting strict objectives at scale on AWS
• How FSx for ONTAP optimizes resilience for self-managed databases
• What this means for your team: Benefits in practice
• Summary and next steps

Navigating database resilience challenges: Meeting strict objectives at scale on AWS

Protecting a single database is one thing, but the task changes dramatically when you’re responsible for a large-scale environment. A typical mission-critical deployment can involve hundreds of databases, several hundred terabytes or more of data, and multiple environments dedicated to development, testing, pre-production, and other purposes.

Within such a landscape, you must meet a range of requirements simultaneously: High availability to ensure that business-critical workloads withstand both component failures and disruptions to Availability Zones (AZs), strict backup recovery objectives, robust disaster recovery (DR) architecture to maintain business connectivity during major incidents, and diligent cost control given the significant expenses associated with database licences, compute resources, and storage capacity.

Traditional designs that rely solely on database-level replication and periodic backups to block storage or object storage often struggle to address all these demands at scale. As a result, backup windows can expand, restore processes might take longer, and disaster recovery deployments can become increasingly complex and costly to maintain.

How FSx for ONTAP optimizes resilience for self-managed databases

Let’s take a closer look at the standard architecture of self-managed databases on AWS and then discuss how FSx for ONTAP can optimize it. For this example, we will focus on a SQL Server.

Initial architecture: AOAG SQL Server running on Amazon EC2 and Amazon EBS

I recently worked with a financial customer managing hundreds of databases and over 500 TB of data across multiple environments, including development, test, pre-production, and others. This deployment required high availability across AZs, RPO of 10 minutes and RTO of 1 hour, and an effective DR site to protect against large-scale events and maintain business continuity. The following diagram illustrates the SQL Server architecture the customer chose, with Amazon Elastic Block Store (Amazon EBS)—a common solution for running a SQL Server on AWS:

In this design:

• Two Amazon Elastic Compute Cloud (Amazon EC2) instances running SQL Server are deployed in different AZs within an AWS Region.
• Each instance uses multiple Amazon EBS volumes for database files, log files, and other data.
• SQL Server replication, such as AOAG, keeps the databases synchronized between the instances.
• Amazon EBS snapshots are used for volume-level backups, with snapshot data stored in Amazon Simple Storage Service (Amazon S3).

This architecture delivers high availability by distributing SQL Server instances across two separate AZs, while ensuring data durability and recoverability through SQL-level replication and Amazon EBS snapshots stored in Amazon S3. It provides flexible scaling, clear separation of compute and storage, and protection against outages within the Region.

However, it has several implications:

• Licensing. AOAG often requires SQL Server Enterprise licensing, which can significantly increase costs when you have many cores and multiple replicas.
• Backup and restore times. As data volumes grow, the time required to create and restore from volume-level snapshots and copies increases. Meeting the 1-hour RTO across hundreds of databases becomes difficult.
• Storage and cost. Multiple Amazon EBS volumes, frequent snapshots, and long retention periods increase storage consumption.
• DR site. Building a DR site using this design typically involves additional infrastructure, extra replicas, more storage, and complex orchestration to meet the RPO and RTO targets.

At this stage, companies are seeking an alternative architecture to overcome these challenges and optimize resilience. In many cases, as was the case with this customer, the solution lies in the choice of storage service.

Optimized architecture: SQL Server FCI running on Amazon EC2 and FSx for ONTAP

Now let’s look at an architecture for a SQL Server failover cluster instance (FCI) using FSx for ONTAP as the underlying storage, which the abovementioned customer eventually moved to:

With this approach, backup and recovery workflows change. Instead of relying only on host-based backups, you use storage-level snapshots as the primary mechanism for protecting data. Creating a snapshot is a fast operation and restore workflows can be built around reverting or cloning from those snapshots.

Because FSx for ONTAP provides high availability across AZs, it can be used as a shared block storage for both Amazon EC2 instances. With this capability, the customer can move away from an AOAG architecture to FCI, while achieving the same or even better availability. For this architecture, a Standard SQL licence can be used, substantially reducing licensing costs.

Additionally, because this architecture requires only a single copy of data, it reduces storage capacity and costs and eliminates cross-AZ charges. And without the need for SQL-level replication, Amazon EC2 instance resources are freed up.

FSx for ONTAP backup operations are based on NetApp incremental Snapshot™ technology. Stored locally on the file system, These Snapshots are created rapidly, require minimal storage due to their space-efficient design, and enable quick recovery from logical failures. Their efficient use of space also keeps backup costs low and ensures performance remains unaffected during creation.

Thanks to an integrated free tool called NetApp SnapCenter® that synchronizes these Snapshot copies with the SQL Server, they become database-aware and require no log forwarding as part of the restoration process.

Adding disaster recovery to the mix

Now let’s add another layer of protection. To further safeguard against physical failures, the design extends to a secondary FSx for ONTAP file system, which can be air-gapped and deployed in another Region. Using NetApp SnapMirror®, data is replicated asynchronously and efficiently, ensuring the latest backups are always available for DR without the overhead of full data copies.

The following diagram shows the SQL Server DR architecture with FSx for ONTAP:

In this setup, the primary FSx for ONTAP file system replicates data incrementally and asynchronously to a secondary FSx for ONTAP file system in a separate Region, providing protection against site-wide or physical failures.

A disaster recovery SQL Server instance can swiftly attach to replicated volumes or space-efficient thin clones, enabling rapid failover and recovery. DR tests and failovers rely on these storage-level copies, eliminating the need for time-consuming full data restores.

This approach aligns easily with demanding recovery objectives, such as a 10-minute RPO and 1-hour RTO, because both replication and restoration are handled efficiently at the storage layer.

Outcomes of the revised architecture

Compared to the initial architecture, FSx for ONTAP streamlines resilience with high availability across AZs. Backup happens in seconds and restore in minutes, and an effective disaster recovery site is provided.

For the customer, this meant:

• Meeting its RPO and RTO requirements.
• Achieving high availability across AZs using a storage‑centric design.
• Reducing backup operations to seconds and restore operations to minutes by using application-aware, lightweight snapshots.
• Building an efficient DR site backed by storage replication.
• Transitioning to a SQL Server Failover Cluster Instance (FCI) design that provided an approximately 40% reduction in licensing and maintenance costs, along with additional savings on compute and storage.

What this means for your team: Benefits in practice

This strategy delivers significant benefits for teams managing their own databases on AWS.

Database administrators enjoy quicker and more reliable backup and restore processes, even when working with hundreds of databases. Regular testing of recovery and disaster recovery procedures becomes more straightforward, because snapshot-based clones allow for the rapid creation of temporary environments.

Storage administrators benefit from a solution built for efficient snapshots, thin clones, and replication—naturally supporting database protection. They can set storage policies once and apply them consistently across multiple databases and environments.

Cloud architects can implement an architecture that meets stringent RPO and RTO objectives, while optimizing licensing, compute, and storage expenses. Additionally, this approach makes it easier to scale as more databases, environments, and Regions are introduced.

In short, FSx for ONTAP empowers each team to focus on strategic improvements rather than routine maintenance, enhancing both productivity and resilience.

Summary and next steps

Protecting self‑managed databases on AWS at scale is challenging. You need high availability, fast recovery capabilities, and a robust DR strategy, while keeping an eye on cost and operational complexity.

By adopting FSx for ONTAP as the storage layer and optimizing the architecture, companies can meet strict SLA requirements, achieve high availability across AZs, build efficient DR sites, while gaining substantial savings on licensing costs and additional cost savings on compute and storage.

If you’re running self-managed databases on the AWS Cloud today, this architecture is worth evaluating. Start by assessing your current RPO and RTO targets, backup times, and disaster recovery design, and consider how FSx for ONTAP can help you protect your databases more efficiently.

To deepen your understanding and explore practical guidance:

• Watch the explainer demo video, showing 3.1 TB of SQL data backed up in just 9 seconds and restored in 8 minutes.
• Read about how FSx for ONTAP optimizes database performance and reduces costs by up to 50% and how to protect your SQL Server workloads using NetApp SnapCenter in our blogs.
• Check out the how-to guides and documentation to help you get started.

Is the IBM SVC still supported on AIX?

we planned the single mailbox recovery configuration back a while ago but eventually didn't do it since we heard it is going to EOF. is there anyone currently using it?

we are currently using Rubrik to back up the Exchange database, when there is a need to recovery emails, we mount the database, use Ontrack powercontrol to access the database for recovering emails or making pst files.

we believe the single mailbox recovery will do the same and worry about the snapshots on exchange database may take too much space or even impact the performance of user access.

Please share your experience if any. 

thank you,

Many customers face challenges related to database discovery, resiliency, data archival, long-term retention, and infrastructure operational challenges. Your databases could be residing anywhere across hybrid cloud, on-premises, hyperscalers which could be hosted on Cloud Volumes ONTAP (CVO), first party service on AWS FSx for ONTAP or service provider-hosted environment, SQL Server could be installed as a standalone or setup with an availability group, protecting data across various setups could get very complex.

In the event of natural calamities, or the growing threat of ransomware, tapes remain the preferred method for backing up and restoring databases. Until a few years back, restoration from tapes was merely requested for a restoration drill to test whether tape restore is working fine. With an increasing number of ransomware attacks, organizations found that restoring from tape takes over a month, and only 20-40% of the data is typically recovered.  RTO and RPO are still a concern for many businesses.

Another hurdle is lean operating management of the backup admin, where the chances of human error can lead to an incorrect restoration of data that increases the restore time. Operational challenges are mainly managing the product lifecycle of backup. Apart from managing the business infrastructure of critical applications, managing upgrades and coordinating upgrades gets complex, operation team must go through multiple levels of approval and qualifications.

All these challenges can be overcome in NetApp BlueXP Backup and recovery for Microsoft SQL Server which is now generally available. It is a single control pane to protect Microsoft SQL Server databases. The current release supports SQL Server databases mounted on storage with FC/iscsi-connected LUNs on NetApp storage. Databases running on VMware virtual disk over VMFS  or NFS data store are also supported.

Onboarding SQL Server host

After the BlueXP organisation is created and connector is deployed, the first step is to grant the user "Backup & recovery super admin" role access in the "Identity & access management".

 Next, go to Protection-> Backup and recovery service. Click Microsoft SQL Server-> Discover and Manage. Fill in the host & credential details to add SQL Server host and click Discover. NetApp backup and recovery service will automatically discover all the instances and database resources running on that SQL Server host.

Protecting SQL Server databases:

Protecting SQL Server database is based on policy created in NetApp Backup and recovery. User must define the frequency, schedule and configure destinations to store backups. Single policy can be used to backup multiple databases. Having minimum number of policies helps in reducing the backup policy management.

Protecting database start with creating policy. Below is the flow of creating policy.

1. Enable protection at the instance level or the database level. Select an instance, and select the type of backup architecture.
   
2. Select the frequency & retention of backup in policy
   
3.  Configure destination volume path, frequency and retention period on the secondary storage
   
4. Configure object storage destination, frequency and retention period
   
   

5. Users can check additional options in the protection policy such as receiving any notification or enabling ransomware scan on object store.

Create policy and attach it to the database or instance resource. Backup job will run as per the schedule

Database cloning:

 In case of application testing or reporting, you need a copy of the database, go to clone and select the database to create new clone. With few clicks database clone can be created. The complete orchestration to create clone on ONTAP, mount filesystem to the SQL Server host, and attaching the database to SQL Server host is done from NetApp Backup and Recovery service.

Below figures shows the workflow of creating clone. User need to provide the details of source database and target destination. Then select the snapshot, recovery scope whether database must be restored with full backup or transactional logs must be restored.

.                                                                                                     

Database restore:

Under Databases inventory, database restoration can be performed by clicking on ellipsis  for specific database and select Restore option.

You could restore database from just a full backup or perform point-in-time-recovery. Select the snapshot and select the source location of snapshot. If the snapshot is deleted from local or secondary storage as per the retention period, restore from object storage. Provide the destination path to restore.

Figure below shows restore option from object storage.

NetApp Backup and recovery service will restore the database securely on same SQL server host or on alternate SQL Server host.

Migrating SnapCenter plug-in for MS SQL Server to NetApp backup and recovery service:

If you are an existing NetApp SnapCenter user, then you should take advantage of the NetApp Backup and recovery. The service has import SnapCenter functionality to migrate most of the SnapCenter protected SQL Server resources to NetApp backup and recovery. All the historical snapshots and configuration metadata will be migrated to NetApp Backup and recovery. Users don’t have to reconfigure policies. There is a validation process that checks the feasibility of migration before switching over to NetApp Backup and recovery.

Conclusion:

Finally, reports are a simplified way to look at the overall protection status such as how many databases are protected, how many were successfully backed up and failed. Similar reports are available for restore and clone jobs.

With all these benefits, you can further modernize infrastructure. Get into the BlueXP management UI, don’t worry about the setup process, as it’s a managed infrastructure.  You don’t have to worry about installing a separate server to host SnapCenter or any backup infrastructure. Login into NetApp BlueXP,  evaluate NetApp Backup and recovery for MSSQL Server by signing up for 30-days trial.

To understand more about the NetApp Backup and recovery, refer documentation here. 

Where can I find the download for SnapCenter for SQL

I try to setup a postresql backup resource including one postgresql db. 
In modify resource group, application sessings i try to add custom configuration settings as follows:
ARCHIVE_LOG_ENABLE=Y

ARCHIVE_LOG_RETENTION=15

ARCHIVE_LOG_DIR=/p99/databasename/archive

ARCHIVE_LOG_RECURSIVE_SEARCH=N

and for the parameter

ARCHIVE_LOG_EXT
i did not succeed to declare the correct value.

All WAL logs ends with a ".wal"
how do i address that in tis configuration?
Even leave the vale blanc is not allowed and not setting ARCHIVE_LOG_EXT did not work.

We are excited to announce the launch of BlueXP Backup and Recovery version 4.0.4! This release introduces a range of enhancements and new features—many of which have been inspired by feedback from our customers—to improve performance and expand functionality.

What’s New in BlueXP Backup and Recovery v4.0.4

High Performance Indexing for AWS, Azure, and GCP (Green Field Customers)

• In February 2025, we debuted our updated indexing feature (Indexed Catalog v2), which significantly improved data indexing performance in on-premise environments.
• In current release, we’ve extended Indexed Catalog v2 support to all major hyperscalers (AWS, Azure and GCP)
• Note:
  • New Customers: This feature is enabled by default.
  • Existing Customers: A full re-index of your environment is required to adopt Catalog v2.

Use existing Azure Private Link Endpoints/Service Endpoints

• Typically, Backup and Recovery establishes a private endpoint with the cloud provider to handle various protection tasks.
• This release introduces an optional setting that lets customers enable/disable CBS from automatically creating a private endpoint. Organizations looking for higher control can utilizing this option.
• Note: If you opt out of CBS creating a private endpoint, managing network connectivity becomes your responsibility. Without proper connectivity, operations may fail.

Support for SnapMirror to Cloud Resync – ONTAP S3

• Our previous release introduced the SnapMirror to Cloud Resync (SM-C Resync) feature, designed to streamline data protection during volume migrations in NetApp environments.
• This update adds support for SM-C Resync on ONTAP S3 as well as other S3-compatible providers such as Wasabi and MinIO.

Bring your own bucket for StorageGRID

• When you create backup files in object storage for a working environment, by default, the backup and recovery service creates the container (bucket or storage account) for the backup files in the object storage account that you have configured.
• Customers can override this and specify their own container for Amazon S3, Azure Blob Storage and Google Cloud Storage. Now, with this release, StorageGRID customers can also bring their own object storage container.

For additional details and guidance on the new features, please refer to the documentation or contact our support team.

Setting up Snapcenter to manage snapmirror after the backup.  I check the box for snapmirror and there is a relationship for all drives: Data, Logs, and DLM which seems to be the replacement for snapinfo. Regardless it seems to replicate the snapshots to the cluster protecting them, but it constantly give warnings below.

Are these erroneous warnings?  has anyone else had this issue? 

Hi,

We are having an issue where when we try and configure the SnapCenter vSphere plugin with the SnapCenter Server details we are presented with the following error:

Unable to login to the SnapCenter Server xxx.xxx.xxx.xxx

I have checked the aegis log file and can see the following entries

2019-03-15T15:02:05.0000564Z ERROR VSC com.netapp.aegis.sms.client.SnapManagerHostServiceRestImpl Unable to connect to SnapCenter Server : XXX.XXX.XXX.XXX : Object reference not set to an instance of an object.
2019-03-15T15:02:05.0000564Z ERROR VSC com.netapp.aegis.sms.manager.SmTokenManager Error when obtaining token: null and unable to login to the SnapCenter Server XXX.XXX.XXX.XXX : com.netapp.aegis.sms.util.SnapManagerLoginException: Unable to login to the SnapCenter Server XXX.XXX.XXX.XXX

Any help would be much appreciated.

We are pleased to announce the launch of SnapCenter 6.1, which introduces a range of advanced features designed to enhance our data protection capabilities in the areas of backup and disaster recovery. These enhancements will facilitate the broader adoption of our enterprise and cloud storage solutions.

What’s New in SnapCenter 6.1 - Key Features and Enhancements

NetApp All SAN Array (ASA r2) Support
Customers who have implemented SAP, Oracle, Microsoft, and other contemporary database applications on virtualized VMFS architectures backed by ASA r2 storage can now safeguard their data locally through Consistent Group (CG) snapshots, as well as remotely utilizing SnapMirror. This advancement will benefit all SAN customers in their adoption of ASA r2 storage solutions.

AWS ELB Support
Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets in one or more Availability Zones (AZs). The integration of AWS Elastic Load Balancing (ELB) significantly enhances the high availability of SnapCenter environments, providing advantages to FSxN customers utilizing SnapCenter.

Ability to Choose iGroup during Clone of Oracle and SQL Databases
Before version 6.1, customers struggled to map clones of Oracle or SQL hosts to VMs across multiple ESXi hosts, making vMotion impossible. With version 6.1, customers can now select or create an iGroup within SnapCenter for including all hosts or multiple initiators. This enhancement allows seamless vMotion while maintaining clone functionality, benefiting numerous customers.

Improved Efficiency of Bulk Job Updates
The optimization of job update calls has resulted in a reduction of overall network calls by approximately 75%. This improvement alleviates the load on Internet Information Services (IIS), thereby enhancing scalability, concurrency, and overall system responsiveness. Large-scale SnapCenter clients are poised to benefit significantly from this enhancement.

Support for Tamper-Proof Snapshots (TPS) on ONTAP Secondary
Enterprise database customers can now lock snapshots on a non-SnapLock volume, including both primary and secondary storage, using different locking periods to enhance protection against ransomware attacks. This feature was previously limited to the primary storage volume, but with the release of version 6.1, support now extends to ONTAP secondary backups. Customers can now fully take advantage of TPS across both primary and secondary storage solutions.

Ability to Assign a Snapshot Label for Primary Snapshots
Customers can now assign SnapMirror labels to primary snapshots for remote replication, allowing them to offload snapshot replication responsibility from SnapCenter to ONTAP secondary systems. This can be done without enabling the SnapMirror or SnapVault option in the policy. This enhancement supports using SVM-DR capabilities with SnapCenter.

SnapCenter supports a variety of applications and protocols.

Summary
NetApp SnapCenter 6.1 brings a suite of advanced features to enhance data protection and ease customer adoption barriers. Key among these updates is the support for NetApp ASA A-Series for application-consistent local and remote snapshots. Customers using VMware VMFS datastores for SAP, Oracle, Microsoft, and other contemporary database applications on virtualized VMFS architectures backed by ASA A-Series storage can now safeguard their data locally.

Learn more here.

Does anyone know if it is possible to install the Windows and SQL Server plugins of SnapCenter version 6.1 on a Windows Server 2012 R2?

Hi All,

I have a snapcenter 6.1, and mount a  lun of the netapp iscsi service, and install postgresql 15.11-1 on it,

I create a postgresql backup , a failed message:

"SCC-00164: Application quiesce for the plug-in [PostgreSQL] failed with exit code [1] and with error : Operation [QUIESCE] failed with Exception [java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: com/sun/jna/LastErrorException] SCC-00161: Application unquiesce for the plug-in [PostgreSQL] failed with exit code [1] and error : Operation [UNQUIESCE] failed with Exception [java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: com/sun/jna/LastErrorException]."

I have installed java se development 11.0.26.

Anybody know how to resolv it ?

Hi!

I am thinking of installing the snapcenter plugin for vSpherere in an environment where the main datacenter storage is served via FC and the DR site would have iSCSI connectivity.
The question is if in this scenario, Snapcenter would be able to mount snapshots on the DR site being the protocol different from the production site.

Thanks

We have an SQL script which deletes a backup from a resource group, deletes clones from that backup, takes a new backup, and takes a new clone from the new backup. This happens each morning. 

Since we updated to Snapcenter 5.0 due to a bug the Where-Object BackupName -Match "^A.*" functionality doesn't work. I am listing below the part of the script which fails to define the variables:

$oldBack=Get-SmBackup -AppObjectId M4SQLXXXXRO3\M4SQLXXXXRO3\XXX_PROD | Where-Object BackupName -Match "^A.*" | Select-Object -first 1
$oldClone=Get-SmClone -BackupId $oldBack.BackupId

NetApp suggests to use Select-String. However, with that I cannot understand how I can define the object. Any ideas how to define an object in Snapcenter 5.0. We understand that this is fixed in 6.0 but it's hard for us to plan an update to that version as all plug-in hosts need to be rebooted to update powershell and .net versions. 

I am pasting below some more of the script for reference:

### DELETING PREVIOUS CLONE DB ###

$oldBack=Get-SmBackup -AppObjectId M4SQLXXXXRO3\M4SQLXXXXRO3\XXX_PROD | Where-Object BackupName -Match "^A.*" | Select-Object -first 1
$oldClone=Get-SmClone -BackupId $oldBack.BackupId

Remove-SmClone -CloneName $oldClone.CloneName -PluginCode SMSQL -Confirm:$false

Start-Sleep -Seconds 240

Remove-SmBackup -BackupIds $oldBack.BackupId -Confirm:$false

Start-Sleep -Seconds 240

### CREATING NEW BACKUP ###

New-SmBackup -ResourceGroupName XXX_XXXX_Automation -Policy Test

start-sleep -Seconds 300

## CREATING THE CLONE ###

$newBack=Get-SmBackup -AppObjectId M4SQLXXXXRO3\M4SQLXXXXRO3\XXX_PROD | Where-Object BackupName -Match "^A.*" | Select-Object -Last 1

New-SmClone -backupname $newBack.BackupName -Resources @{"Host"="XXXXXXXXXX";"Type"="SQL Database";"Names"="M4SQLXXXXRO3\M4SQLXXXXRO3\XXX_PROD"} -CloneToInstance XXXXXXXXX\XXXXXXXXX -AutoAssignMountPoint -CloneName XXX_PROD_SNAP -AppPluginCode SMSQL

Where can you find the housekeeping tasks in SnapCenter version 5 & 6 (on Windows). Several KB articles refers to Windows Tasks Scheduler, but that seems to a long time ago.

You can also create a schedule using powershell and the syntax presented in the KB article but there is no apparent way to verify that the schedule is actually there, or if you have multiple entries of the same housekeeping task.

Example of a housekeeping task: SnapCenter_RemoveSecondaryBackup

I have a very dynamic MSSQL environment and I don't want to miss a new DB instance in the GUI. What would be the best way to do a scheduled refresh of resources?

I have 50 SnapCenter agents deployed and am planning an upgrade from version 5 to 6. Version 6 is not compatible with three critical servers that are our last Server 2008R2 boxes [yes we are working on migrating them :)]. For those boxes only, I would at least like to upgrade to 5.0P1. Is there an easy way to do that without upgrading the entire environment to 5.0P1 and then upgrading to 6.0? I'd rather just push the patch out to the three servers rather than upgrade everything. Any suggestions on the most efficient way to do this?

Can someone provide the version numbers for Snapcenter 4.0 P1, P2, P3?
I have Version 4.0.0.748 installed and do not now if this is 4.0P1 or 4.0P2

Has anyone else encountered this? I just resized a LUN for the first time after upgrading SnapCenter to 5.0 and have found some oddball behavior. When I click in the text box to enter a number, it automatically increments the size by a random amount (and moves the slider forward automatically as well). I can get close to what I was going to do but it's an oddball result, like 51.67GB instead of 50GB as I intended. Basically, you are unable to type anything in the text box anymore. You have to accept the random increments (or drag the slider). I've tried it on several LUNs on several servers and they all do the same thing. Has anyone encountered/reported this? If not I'll open a case and try to get a bug submitted.

In an iSCSI datastore based VMware environment, we are working with VM tags for backup in SnapCenter. There are datastores in an CG and some without the need for SM-BC. The backup only works if all VMs are either on volumes in CG or on the volumes without. Is the there a limitation in SnapCenter Plug-in for VMware with LUNs in CGs and some without? Do I have to maintain dedicated tags for VMs in CG? All VMs and datastores are mounted to the same VMware cluster. In SnapCenter we have one Resource Groups with the VM tag as selector.

I have snapcenter plug-in for VMware and the underlying protocol is FC for the storage connectivity. 

I want to retain more snapcenter snapshots at the secondary storage and hence planning to use “mirror-vault” policy for SM relation and update snapvault after back up option in plugin. 

To restore a VM from vault backup what is the connectivity requirement from secondary storage to snapcenter plugin/vcenter/host. Do I need any fc connectivity as primary is based on FC protocol ?

SnapCenter Plug-in for VMware vSphere detects FlexGroup instead of Flex Vol volumes, see screenshot:

As soon as I add more than one ch_fx_vmdatastore_gen_00* volume in the Resource Group I get this warning and can not continue. I have double checked in ONTAP and these are really FlexVol volumes and not FlexGroup volumes. Also I have some older Resource Groups which still have all the ch_fx_vmdatastore_gen_00* volumes in them and are running fine. Next to that we have other environments with completely the same setup and no problems like this at all.

The only strange thing I found so far is that this envrionment with the problem does have different Permissions when I look in Administration / Access Roles / Roles and go to Edit a role. I have tried to unregister and register the SnapCenter Plug-in for VMware vSphere, but that did not make the permission structure completely the same. Anyway, it does not seem to be a problem as the old jobs can run from start to end without any problems.

Anybody with a solution for this, other than creating a Resource Group job for every single vmdatastore?

(https://docs.netapp.com/us-en/sc-plugin-vmware-vsphere-45/scpivs44_create_resource_groups_for_vms_and_datastores.html)

I'm using Snapcenter 4.7 and 5.0 and the REST API. I'm looking to build a front end Web app to show clone details (and other things). Where can I find a schema reference for the JSON/XML returned by the APIs?

I'm using Snapcenter 4.7 production instance and looking to test upgrade to 5.0. The problem is I need the workloads/config of prod (clones etc.) to do a real test so I have attempted taking a backup of 4.6 and restoreing to a new server with the same name but in a different domain. I cannot restore to the same domain as this would impact produciton. 

After manipulating some of the XML files and folder name sof the backup I managed ot do the restore but now I cannot logon. I'm assuming this is because all the roles on the prod instance are targted at ADDS users/groups in the prod domain and my restore is to a member server in my test domain.

Q: is there anyway to reset the access?

Hello,

I am testing the snapshot copy locking feature. We're on OnTAP 9.12.1P11 and SnapCenter 5. Here is my understanding of limits I've discovered during testing thus far. Can someone verify whether my analysis is correct and/or provide insights into these issues? I'm starting to think this might only be a viable solution for the VMware plug-in.

• CIFS - you cannot restore an entire volume to an earlier snapshot unless it's the most recent locked snapshot copy. Of course you can restore individual files still via the hidden snapshot directory.
• SnapCenter Plug-In for SQL - any snapshot (locked or not) can be restored from, but the restore method is always  single-file restore and can't be a full volume restore, unless it's the most recent locked snapshot. Best practice is to have very large databases on their own volume so the entire volume can be quickly restored, but this wouldn't be doable on anything but the latest locked snapshot. Restoring from any other snapshot would result in a lengthy outage.
• SnapCenter Plug-In for Windows - similar to SQL, I believe this would never be a full volume restore unless it's the most recent locked snapshot. If the volume contained significant amounts of data and we needed to restore from an older snapshot, this could cause a very large outage.
• SnapCenter Plug-In for VMware - I believe functionality is 100% the same with locked snapshots. Restoring a full VM creates a clone behind the scenes that is mounted, with the existing VM powered off and the backed up copy powered on and migrated, followed by unmounting the backup. You could mount a whole datastore snapshot if needed, detach the old datastore and attach the new, turning the snapshot into a separate cloned volume. Same process.

Hello everyone,

I made some edits to the resources in the "Resource Groups" section of SnapCenter and added another email address under "Email send to:" using a semicolon as a separator. After confirming the changes, I attempted to make further edits, but was unable to do so as I encountered a persistent "Initializing..." message.

I attempted to resolve the issue by restarting SnapCenter, but unfortunately it did not solve the problem.