Black Box analysis. Published 2026-10-30. Based on Tim McCarthy’s TechTarget report, published May 26, 2022, checked against N2WS 4.1 release notes and product documentation.
Product N2WS 4.1 FSx for ONTAP SAP HANA 2026-10-30What actually shipped in version 4.1
N2WS Backup & Recovery 4.1 widened the set of AWS workloads that one N2WS policy could protect. The two headline additions were backup and orchestrated recovery for Amazon FSx for NetApp ONTAP, plus application-aware backup and recovery for SAP HANA running on an EC2 instance. These were N2WS control-plane capabilities; the release did not add an ONTAP feature or change FSx for ONTAP itself.
The same release added S3 Object Lock integration for immutable copies, PostgreSQL support in the RDS copy-to-S3 workflow, Glacier archiving for those copies, and recovery of database users. It also expanded VPC capture and cloning and added Azure cross-region disaster recovery for VMs and disks and protection policies for Azure SQL databases. The site’s backup and restore reference explains why a storage snapshot, a replicated copy, and an object-store copy answer different failure scenarios.
What changed from the previous product boundary
| Area | Before 4.1 | Version 4.1 change | Operational consequence |
|---|---|---|---|
| FSx file services | N2WS already protected FSx for Windows File Server and FSx for Lustre | FSx for ONTAP became a policy target with automated backup and restore of all or selected volumes | Admins could place the managed ONTAP file system in the same N2WS policy model as other AWS resources |
| SAP HANA | EC2 snapshot protection alone did not establish a HANA database recovery workflow | N2WS coordinated an EC2 snapshot with a native HANA database backup stored in an S3 repository | The database configuration, credentials, SSM path, S3 repository, and EC2 protection all became part of the recovery runbook |
| S3 copies | S3 repositories existed for copied backups | S3 Object Lock integration added an immutable-retention option | Retention mode and period had to be chosen before treating the repository as a ransomware-resistant copy |
| Network recovery | Individual cloud resources could be protected | VPC entities and associated services could be captured and cloned to another Region or account | A recovery plan could include network state instead of rebuilding it entirely by hand |
FSx for ONTAP: useful orchestration, specific scope
N2WS’s 4.1 notes describe automated backup and orchestrated restore for either all volumes or a single volume. That is the product change. It should not be read as a promise of application consistency inside every hosted workload, nor as a replacement for workload-native protection. Administrators still need to identify which SVMs and volumes hold an application, coordinate write consistency where required, and prove the recovery path.
The later N2WS user guide documents an important boundary: a policy can select part of a file system’s volumes, but the SVM root volume is not backed up. That makes configuration evidence important. Before a test, export the selected file system, SVM and volume inventory; after recovery, validate the data volumes, client protocol access, identity dependencies and application behavior rather than stopping at a successful N2WS job.
SAP HANA: prerequisites became part of backup success
For HANA, N2WS creates an EC2 instance snapshot and stores a native HANA database backup in an AWS storage repository. The documentation says the database backup is always full. The target EC2 instance must be running, AWS CLI and the SSM Agent must be installed and working, and the policy needs the HANA SYSTEMDB user, SID, instance number, S3 repository and its KMS key ARN.
N2WS documents that AWS permits only one HANA database backup in parallel, and N2WS therefore allows a HANA database in only one policy. This is a scheduling constraint, not a cosmetic setup detail: overlapping protection ownership can prevent the intended job from running. The account used for recovery also needs access to the S3 and KMS resources that hold the database copy.
Recovery and upgrade boundaries
- Test both layers of a HANA recovery. N2WS offers recovery to a newly recovered EC2 instance or recovery of the internal databases to the original instance. A successful instance restore does not by itself prove that SYSTEMDB and tenant data are usable.
- Validate network reachability before cross-Region HANA recovery. N2WS warns that communication failures on the required ports can break that workflow. Some installations also need
/etc/hostshandling for local database communication. - Inventory FSx selections before upgrade. Record the protected file systems and volumes, their policy membership, schedules, retention and restore destination. Confirm the same inventory after the N2WS upgrade before the next protection window.
- Do not infer current support from a 4.1 announcement. Administrators on a later N2WS release should use the release notes and user guide for that installed build. Later releases fixed HANA and immutable-repository defects, which is evidence that a restore test must accompany any upgrade.
Known issues: what is and is not documented
The 4.1 release notes list features but do not publish a 4.1-specific defect table, so this article does not invent one. Later N2WS 4.4.0 notes identify fixes for the CPM Agent failing to clear a HANA SYSTEMDB folder and for a repository incorrectly showing immutable backups as disabled when compliance lock was selected. Those later fixes do not prove that every 4.1 installation encountered either problem; they do justify verifying HANA cleanup and immutable-repository status during an upgrade or recovery test.
An administrator validation sequence
- Record the installed N2WS build and read the matching release notes; do not use this 2022 feature list as a current compatibility matrix.
- For FSx for ONTAP, map the application to its file system, SVM and selected data volumes, and record that the SVM root volume is outside the documented backup scope.
- For HANA, verify AWS CLI, SSM Agent, SYSTEMDB identifiers, S3 access, KMS permissions and the single-policy constraint.
- Run a representative restore to an isolated destination. Validate protocol access and application data for FSx, and database startup and tenant recovery for HANA.
- For immutable S3 copies, verify Object Lock configuration, retention behavior and access separation with evidence from the target repository, not only the N2WS dashboard.
Sources: TechTarget — “N2WS expands AWS backup service with OnTap and HANA targets” (Tim McCarthy, May 26, 2022); N2WS 4.1.x release notes; N2WS user guide — additional backup topics; N2WS user guide — recovery; N2WS 4.4.0 release notes. Internal: backup and restore.