Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Cloud Application DR Solutions for Data Orchestration for Dell

Introduction​

Beyond backup and archive, a Golden Copy synced object storage copy of application data can serve as the source for recovering an application in the cloud during a site-level disaster. This page covers reference architectures for using Golden Copy's AWS S3 and Azure Blob targets to recover applications in AWS or Azure, by rehydrating the synced object copy into a cloud-native file service that an application server can mount.

caution

These patterns rely on third-party cloud services (AWS Mountpoint for Amazon S3, s3fs, AWS DataSync, AWS FSx, and Azure Storage Explorer) alongside Golden Copy. Golden Copy configuration is covered under the standard support agreement; configuration, licensing, and support of the cloud provider services themselves is the customer's responsibility, consulting the relevant cloud provider's documentation.

Basic Object Access Pattern (Generic S3 Browser)​

Not every DR requirement needs application-level failover or a rehydrated file service. For a simpler recovery goal — getting people access to the data itself, quickly, without needing the original SMB/NTFS security or a fully failed-over application — a synced Golden Copy object copy can be accessed directly with a generic S3 browser tool.

This pattern fits deployments with:

  • A data set under roughly 100 TB.
  • Data access as the priority, rather than application failover for a large number of end users.
  • Reduced data access speed as an acceptable trade-off during a DR event.
  • No requirement to preserve existing SMB share and ACL security in the DR scenario itself (access is via S3 credentials, not the original file permissions).
  • Cloud object storage (or Dell Object storage) sized to hold the full protected data set off site.

Configuration:

  1. Configure Golden Copy in sync mode with an incremental schedule against the source path, as described in Adding Folders with the CLI.
  2. Run the initial full copy job to seed the target bucket.

Providing DR access to the data:

  1. Install a generic S3 browser tool — such as Cyberduck or S3 Browser — on any Windows PC that needs DR access to the data.
  2. Configure the tool with the access key, secret key, and endpoint of the bucket used as the Golden Copy target.
  3. Test the connection and download a sample file to confirm access is working before relying on it during an actual DR event.
  4. Repeat this setup on any additional host that needs data access during a DR event.

DR scenarios:

  • Source cluster is not accessible: use the S3 browser tool to access data directly from the bucket.
  • Source cluster is accessible again: use the S3 browser tool for immediate access while a Golden Copy recall job restores the data back onto the source cluster in the background — see Recalling Data from Object Storage.
note

This pattern is a basic, low-cost data access option, not a traditional DR solution with automated failover and failback. For application-level recovery in AWS or Azure, use the rehydration-based patterns below instead.

AWS Recovery Patterns​

Mountpoint for Amazon S3 (Read-Only)​

Mountpoint for Amazon S3 is a Linux FUSE-based application that mounts an S3 bucket — including a bucket used as a Golden Copy target — directly onto an EC2 instance's local file system. It is compiled from source and, at the time of this writing, is read-only.

Read/Write Hybrid Cloud Access with s3fs​

This pattern allows a Linux EC2 instance to mount a Golden Copy target S3 bucket in read/write mode using s3fs, so edits made in the cloud can later be recalled back to the source PowerScale cluster.

Requirements:

  • Linux EC2 instance
  • s3fs installed on the instance
  • Golden Copy with the Advanced license key
  • The S3 bucket name used as the Golden Copy target, plus an access key and secret key with read/write access to the bucket

Limitations:

  • Throughput on S3-mounted storage is significantly lower than a traditional file system — a reasonable expectation is roughly 35–40 MB/s.
  • File locking for concurrent access is limited compared to a native file system.

Configuration outline:

  1. Deploy a Linux EC2 instance and install s3fs (for example, zypper install s3fs on SUSE-based images).
  2. Create a credentials file for s3fs containing the access key and secret key, and restrict its permissions.
  3. Create a local mount directory and mount the bucket with s3fs <bucket name> <mount directory>, then verify with a test file create/delete.
  4. Add an entry to /etc/fstab to persist the mount across reboots.

Once mounted, files edited or created on the EC2 instance retain the custom metadata Golden Copy relies on, and a recall job (for example, from the Cloud Browser GUI) can pull new or changed data back to the source PowerScale cluster.

Application DR to AWS FSx (SMB Share) with DataSync​

This pattern uses Golden Copy sync mode to keep an application's data continuously synced to an S3 bucket, and AWS DataSync to copy that data into an AWS FSx for Windows File Server SMB share on demand, so a pre-staged EC2 application server can mount the data and resume operation during a DR event.

Requirements:

  • AWS S3 and FSx for Windows File Server services configured in your AWS account
  • PowerScale OneFS 8.1.x or 8.2.x
  • Golden Copy installed and licensed
  • A single-availability-zone deployment (this pattern's documented scope)

High-level steps:

  1. Golden Copy: create an S3 bucket for the application data, configure a Golden Copy folder definition in sync mode against the application's PowerScale path, set an incremental schedule, and run the initial full sync. See Adding Folders with the CLI and Scheduling Jobs.
  2. Active Directory: deploy or extend Active Directory into AWS (for example, an AWS Managed Microsoft AD instance trusted with the on-premises domain) so SMB share permissions carry over correctly.
  3. FSx file system: create an AWS FSx for Windows File Server file system joined to Active Directory, sized to hold the application data, with one or more SMB shares for the application(s) being protected.
  4. Application server: pre-stage an EC2 application server AMI joined to the same Active Directory domain, left powered off until needed.
  5. AWS DataSync: deploy a DataSync agent in the same region as the S3 bucket and FSx file system, create source (S3) and destination (FSx) locations, and create a DataSync task to copy data from the bucket into the FSx SMB share. Run a test copy to validate the task before relying on it for DR.

DR recovery procedure:

  1. Start the DataSync task to copy the current S3 data into the FSx share. Copy time depends on data volume.
  2. Monitor the DataSync task's progress and completion in the AWS console.
  3. Power on the pre-staged EC2 application server.
  4. Log in to the application server and verify the SMB mount and data availability.
  5. Start the application once the DataSync task has completed.

Azure Recovery Pattern​

Application DR to Azure Blob and Azure File Share​

This pattern mirrors the AWS FSx approach using Azure Blob Storage as the Golden Copy sync target and an Azure Storage Account File Share as the application-facing SMB target.

Requirements:

  • Azure subscription, with all resources created in the same resource group
  • PowerScale OneFS 8.1.x or 8.2.x
  • Golden Copy installed and deployed
  • Active Directory extended to Azure (on-premises AD joined or trusted with an Azure AD instance), so SMB share ACLs resolve correctly

High-level steps:

  1. Golden Copy: create an Azure Storage Account and Blob container for the application data, configure a Golden Copy folder definition in sync mode (default) against the application's PowerScale path using the Azure storage target example in Adding Folders with the CLI, and run the initial full sync.
  2. Conversion VM: deploy a Windows Server VM in the same resource group as the storage account, create an Azure Storage Account File Share for the application, and install Azure Storage Explorer on the conversion VM to browse the synced Blob data.
  3. DR event — rehydrate to the file share: using Azure Storage Explorer on the conversion VM, download the application's Blob data into the mapped Azure File Share. This can take time depending on data volume.
  4. Application recovery: pre-staged application VMs in Azure mount the File Share (using integrated Active Directory authentication over SMB3, which encrypts data in flight) to resume operation.
  5. Sync changed data back to Blob for eventual recall: after the DR event, use Azure Storage Explorer to upload any data that changed on the File Share back into the Blob container (partial, selective uploads are supported), so it can later be recalled to the source PowerScale cluster with a standard Golden Copy recall job. Overwriting an object through this path removes the Golden Copy metadata tags on that object, so metadata will not be restored by Golden Copy for files touched this way.

See Also​

  • Cloud Vault — Immutable, versioned S3 vault architecture using Golden Copy and Ransomware Defender.
  • Configuration Guide — Folder definitions, schedules, recall, and Cloud Browser.
  • Concept — How Data Orchestration's object-to-file recall capability fits with dedicated Disaster Recovery solutions.