QoreStor 7.5.0 - User Guide

There are two ways to perform a recovery from the cloud, also known as a disaster recovery. You can recover data by creating a new QoreStor instance and transferring the data, or you can perform a quick recovery, which provides a read-only version of RDA container data of your current QoreStor instance. To recover your QoreStor configuration and cloud-replicated data from the cloud, perform the steps below. Before performing these steps, make sure you have the following:

A functional, properly licensed QoreStor server.
In the case of Archive Tier, to bring data to S3-Warm Cloud before proceeding with a disaster recovery operation, refer to Manually restoring datastores from Amazon S3 Glacier.
The connection string for your cloud storage account. This is different depending on your cloud provider. Refer to the appropriate section below for more information.

To perform a disaster recovery from the cloud

On a newly installed QoreStor server, run the following recovery command using the definitions provided in the table:

maintenance --disaster_recovery --cloud_string <name> --container_name <name> --cloud_provider_type <name> --passphrase <name> --logfile <name> --quick_ro_recovery no

Table 8: Recovery command definitions
Command option	Definition
--cloud_string	Cloud connection string, to connect to the cloud bucket.
--container_name	Name of the cloud bucket from where data is to be recovered. Valid values are [a-z, 0-9, '-', '.'].
--cloud_provider_type	Name of the cloud service provider, such as <AWS-S3 \| Azure \| Wasabi-S3 \| Google-S3 \| IBM-S3 \|Scality-Artesca-S3\| S3-Compatible>.
--passphrase	Passphrase used on original machine for encrypting the data in the cloud bucket.
--logfile	Log file path to capture the ongoing recovery activity.

This will regenerate configuration data and populate the metadata from the cloud copy.

When completed, you will see the following message:

Filesystem  disaster recovery started successfully.

Please see the /var/log/oca/qsdr.log and the logfile given in the command.

After the data recovery process is complete, perform a filesystem repair with the command
```
maintenance --filesystem --repair_now
```
When the file system repair is finished, the process is complete.

To perform a quick recovery

On a newly installed QoreStor server of the same install mode and configuration as your previous QoreStor server, run the following recovery command using the definitions provided in the table:

maintenance --disaster_recovery [--cloud_string <name>] [--container_name <name>] [--cloud_provider_type <name>] [--passphrase <name>] [--logfile <name>] [--quick_ro_recovery <[yes | no]>]

Table 9: Quick recovery command definitions
Command option	Definition
--cloud_string	Cloud connection string, to connect to the cloud bucket.
--container_name	Name of the cloud bucket from where data is to be recovered. Valid values are [a-z, 0-9, '-', '.'].
--cloud_provider_type	Name of the cloud service provider, such as <AWS-S3 \| Azure \| Wasabi-S3 \| Google-S3 \| IBM-S3 \| Scality-Artesca-S3\| S3-Compatible>.
--passphrase	Passphrase used on original machine for encrypting the data in the cloud bucket.
--logfile	Log file path to capture the ongoing recovery activity.
--quick_ro_recovery	Fast disaster recovery, with data in cloud bucket accessible in RO mode only.--quick_ro_recovery quick read-only recovery.

This will regenerate configuration data and populate the metadata from the cloud copy. When used with a newly deployed QoreStor instance, the --quick_ro_recovery command lets you attach a cloud bucket and conduct read-only restores without disturbing the cloud connection of the existing QoreStor.

When completed, you will see the following message:

Filesystem  disaster recovery started successfully.

Please see the /var/log/oca/qsdr.log and the logfile given in the command.

Next steps

Depending on your configuration, there may be several steps required after recovering your QoreStor server. Some actions to consider are:

If you are using QoreStor with NetVault, you will need to add the new QoreStor as target device and add the container.
Depending on your DMA, you may need to reconfigure DMA or client connections to reference the new QoreStor server.
Once a disaster recovery completes, the recovered source containers will be unencrypted. Before ingesting new data into the recovered containers, you must enabled encryption on the recovered storage groups.

NOTE:The recovered containers contain only stub files. The data remains encrypted in the cloud tier.

Manually restoring datastores from Amazon S3 Glacier

Performing a disaster recovery from an archive tier, involves restoring all datastores to standard Amazon S3 storage, which includes generating the manifest of objects in the cloud bucket used for archive tier and then initiating a Batch Restore from the console.

NOTE: Before performing a recovery, confirm the status of various objects and ensure that they are in warm storage for the duration the readback of data is planned.

To manually restore datastores from Amazon S3 Glacier

Sign in to the AWS Management Console and open the Amazon S3 Console at https://console.aws.amazon.com/s3.
Under Buckets, select the name of the bucket for which you want to configure Amazon S3 inventory.
Click Management.
Under Inventory configurations, click Create inventory configuration.
For Inventory configuration name, enter a name.
Set the Inventory scope by entering the following details:
- For prefix, enter s3://<cloud_bucket_name>/cds.
- For object versions, select Current versions only.

Select the following options:

Table 10: Manifest options

Option

Selection

Report details

Select the location of the AWS account to which you want to save the reports. For example, This account.

Destination

Complete one of the following options:

Select the destination bucket where you want to save the reports, or
Select a different prefix under the same bucket. For example, s3://<cloud_bucket_name>/manifest.

NOTE: The destination bucket must be in the same AWS Region as the bucket for which you are setting up the inventory.

Destination bucket

Here you can see the Destination bucket permissions added to the destination bucket policy which allows Amazon S3 to place data in that bucket. For more information, see Creating a destination bucket policy in the documentation for Amazon S3.

Frequency

Select Daily.

NOTE: The first report may take 24 to 48 hours to generate.

Output format

Select CSV.

Status

Select Enable.

Server-side encryption

Select Disable.

Additional Fields

Do not select any options, as they are not included in the Batch Job submission.

The manifest file generates.

To initiate the Batch Job for restoring datastores, complete the following steps:
1. Navigate to AWS S3 bucket > Management > Inventory Configurations.
2. Select the latest manifest file.
3. In the AWS console, to initiate the batch job, click Create Job from Manifest option in AWS console.

Managing replications

Guidelines and prerequisites for replication

Refer to the following important notes and guidelines for understanding and using replication in QoreStor.

TCP Port Configuration—If you plan to perform replication operations across a firewall, the replication service requires that the following fixed TCP ports be configured to support replication operations:
- port 9904
- port 9911
- port 9915
- port 9916
DMAs and Domain Relationships — To allow replication storage information to be viewed by a corresponding data management application (DMA), the target QoreStor system must reside in the same domain as the source QoreStor system in the replication relationship.
Replication Limits — Refer to the QoreStor Interoperability Guide for details about the supported system limits for replication. For a definition of connections and streams, see Streams and connections.
Version Checking — The QoreStor software includes version checking that limits replication only between other QoreStor systems that run the same system software version. If versions are incompatible, the administrator will be notified by an event, and replication will not continue.
Storage Capacity and Number of Source Systems — Be aware that the storage capacity of the target QoreStor system is directly affected by the number of source systems writing to its containers, and also by the amount being written by each of these source systems.
Bandwidth throttling — Refer to the qs_bw_throttle command in the QoreStor Command Line Reference Guide for information regarding throttling bandwidth consumption for replication between QoreStor systems..
MTU Setting — Primary and secondary replication targets should have the same network maximum transmission unit (MTU) setting.