Choosing S3 for Disaster Recovery

In addition to on-premises Swarm storage, your organization may want to take advantage of public cloud services for off-premises disaster recovery (DR) storage. With its S3 protocol support, Swarm gives you the choice of many public cloud providers including AWS S3, AWS S3 Glacier, and Wasabi. 

By implementing an S3 backup feed from Swarm, you have the security of knowing that your backups are continuous, have minimal latency, and require little intervention and monitoring by you. Using Swarm's feed mechanism for backup leverages numerous existing strengths: its long-term iteration over objects in the cluster, proven method for tracking work as it is performed, and support for TLS network encryption and forward proxies. Using the parallelism of the entire Swarm cluster makes best use of your network bandwidth, while sending the backups through an optional forward proxy allows you to implement bandwidth throttling if needed.

Back up — S3 Backup is an integral part of your operating Swarm cluster. In the Swarm UI, you will create a new feed of type S3 Backup, giving credentials and information about the network path to the service. After the feed is started, you can monitor its progress and be warned of blockages and particular object failures, as with any other feed. The S3 Backup feed will honor the versioning settings in your cluster, as enabled, disabled, or suspended throughout the domains and buckets. While you can create multiple S3 Backup feeds, each one requires its own dedicated target bucket.

Clean up — No action on your part is needed to keep the backup current and trimmed. Whenever you disable Swarm versioning on buckets or domains, delete buckets or domains, or have object lifepoints expire, the Swarm feeds mechanism will process the expired content as deleted, allowing the S3 Backup feed to clear them from the S3 bucket. Throughout content additions and deletions, the total number objects in your S3 bucket will always approximate twice the number of logical objects that you are backing up from the source cluster (because AWS functionality requires there to be one for the object's content and another for its metadata).

Restore — The Restore tool runs outside of Swarm, using a command-line interface for executing the data and restoration tasks. You can restore what you need: either the entire cluster, or only portions. Swarm supports bulk restores at the granularity of cluster, domain, or bucket, as well as more surgical restores of a few objects. You can also run multiple copies to achieve a faster, parallel recovery. See the S3 Backup Restore Tool.

Standard or Cold Storage?

Swarm 12 supports the AWS S3 storage classes for standard buckets and those using S3 Glacier and S3 Glacier Deep Archive. For this discussion, cold storage refers to S3 Glacier and S3 Glacier Deep Archive, and standard storage refers to the traditional S3 storage classes.

Refer to the documentation for your public cloud provider, and consider these points when choosing among the AWS S3 storage classes:

• Cold storage offers the lowest monthly prices per byte stored compared to the standard storage classes.
• Standard storage classes have low-latency retrieval times, which can allow a Swarm Restore to complete in a single run.
• Cold storage has longer retrieval latency, as much as 12-48 hours for S3 Glacier Deep Archive, to pull content from archival storage. Depending upon how a restore is performed, you may need to run the Swarm Restore tool multiple times over several hours in order to complete a restoration.
• Cold storage incurs additional charges for egress and API requests to access your backup, so it is best suited to low-touch use cases.
• S3 Glacier Deep Archive rounds up small objects, so the overall footprint being charged may be larger because of Swarm's use of metadata objects.

Public storage pricing is competitive, and you might find that services such as Wasabi Hot Cloud Storage compare very favorably with AWS cold storage, especially when you consider egress and API charges.

Setting up the S3 Bucket

To implement an S3 backup feed, you will first complete a one-time set up of the S3 side: you will set up an account with an S3 cloud service provider and then create an S3 bucket that will be dedicated to backing up this cluster only.

While these instruction steps are for AWS S3 (see also S3 Backup Feeds to Wasabi), S3-based public cloud providers will have a similar setup process:

1. Service — If needed, sign up for Amazon S3.
   1. Go to aws.amazon.com/s3 and choose Get started with Amazon S3.
   2. Follow the on-screen instructions.
   3. AWS will notify you by email when your account is active and ready to use.
   4. Note that you will access S3 for your new bucket but the separate IAM service for your new user:
      
2. Bucket — Create a bucket that will be dedicated to backing up your Swarm cluster.
   1. Sign in and open the S3 console: console.aws.amazon.com/s3
   2. Choose Create bucket. (See S3 documentation: Creating a Bucket.) 
   3. On tab 1 - Name and region, make your initial entries:
      1. For Bucket name, enter a DNS-compliant name for your new bucket. You will not be able to change it later, so choose well:
         1. The name must be unique across all existing bucket names in Amazon S3.

         2. The name must be a valid DNS name, containing only lowercase letters and numbers (and internal periods, hyphens, underscores), between 3 and 64 characters. (See S3 documentation: Rules for Bucket Naming.)
            Tip: For easier identification, incorporate the name of the Swarm cluster that this bucket will be dedicated to backing up.

      2. For Region, choose the one that is appropriate for your business needs. (See S3 documentation: Regions and Endpoints.)
   4. On tab 2 - Configure options, take the defaults. (See S3 documentation: Creating a Bucket, step 4.)
      Best practice: Do not enable versioning or any other optional features, unless it is required for your organization.
   5. On tab 3 - Set permissions, take the default to select Block all public access; now only the bucket owner account has full access.
      Best practice: Do not use the bucket owner account to provide Swarm's access to the bucket; instead, you will create a new, separate IAM user that will hold the credentials to share with Swarm. 
   6. Choose Create, and record the fully qualified bucket name (such as "arn:aws:s3:::example.cluster1.backup") for use later, in policies.
   7. Record these values for configuring your S3 Backup feed in Swarm:
      • Bucket Name
      • Region
3. User — Create a programmatic (non-human) user that will be dedicated to Swarm access.
   1. On the Amazon S3 console, select the service IAM (Identity and Access Management), click Users.
      
      
   2. Add a dedicated user, such as caringo_backup, to provide Programmatic access for Swarm.
      
      
   3. The IAM console generates an access key (an access key ID + secret access key), which you must record immediately.
      (See S3 documentation: Managing Access Keys for IAM Users and Understanding and Getting Your Security Credentials.)
      • This is your only opportunity to view or download the secret access key, so save it in a secure place.
   4. Record the fully qualified user (such as "arn:aws:iam::123456789012:user/caringo_backup") for use later, in policies.
   5. Record these values for configuring your S3 Backup feed in Swarm:
      • Access Key ID
      • Secret Access Key

4. Policies — Create policies on both the user and the bucket so that the programmatic user has exclusive rights to your S3 bucket. You may use the policy generators provided or enter edited versions of the examples below.

   1. Create an IAM policy for this user, allowing it all S3 actions on the backup bucket, which you need to specify as a fully qualified Resource (which you recorded above), starting with arn:aws:s3:::
      

      IAM policy

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": "s3:*",
                  "Resource": "arn:aws:s3:::example.cluster1.backup"
              }
          ]
      }

   2. Create a matching bucket policy to grant access to the dedicated backup user, which you need to specify as a fully qualified Principal, which is the User ARN (which you recorded above) starting with arn:aws:iam:: (See S3 Using Bucket Policies.) 
      Using the Policy Generator, be sure to allow all S3 actions for your bucket, using the full ARN name:
      

      Bucket policy

      {
        "Id": "Policy1560809845679",
        "Version": "2012-10-17",
        "Statement": [
          {
            "Sid": "Stmt1560809828003",
            "Action": "s3:*",
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::example.cluster1.backup",
            "Principal": {
              "AWS": [
                "arn:aws:iam::123456789012:user/caringo_backup"
              ]
            }
          }
        ]
      }

5. Best practice for security: After you implement the S3 Backup feed in Swarm, write a script to automate rotation of the S3 secret access key on a regular basis, including updating in the S3 Backup feed definition in Swarm (using the management API call, given in Rotating the S3 Access Key, below).
   

Configuring the S3 Backup Feed

The S3 Backup Feed option is available in Swarm 11 and higher, and it may be used immediately after upgrading Swarm Storage. (v11.0)

In addition to Swarm's other feed types, Search and Replication, you can create a dedicated S3 Backup feed. It resembles a Replication feed, but it requires an S3 bucket as the destination and has defaults appropriate for use with a cloud service.

1. Go to the Feeds page.
   
2. Select + Add at the top right.
   
3. Choose the S3 Backup feed type:
   

An S3 Backup feed has these parameters:

Rotating the S3 Access Key

It is a DevOps best-practice to routinely change your cloud access credentials and to automate this S3 access key rotation for your S3 Backup feed.

1. Through your public cloud provider, create a new S3 access key and grant the correct permissions for the target S3 bucket.
2. Using Swarm's management API, update the access credentials for your existing S3 backup feed.
3. Upon confirming successful feed operations with the new credentials, expire/remove the old S3 access key.

The following command template demonstrates how to use the Swarm management API to update the access credentials for an existing S3 backup feed:

curl -X PATCH --header 'Content-Type: application/json' -u <admin>:<password> -d '[       \
{"op": "replace", "path":"destination/accessKeyId", "value":"<newAccessKeyID>"},          \
{"op": "replace", "path":"destination/secretAccessKey", "value":"<newSecretAccessKey>"}]' \
'http://<nodeIP>/api/storage/s3backupfeeds/<s3feedid>'

• <admin> — The Swarm administrative user name, which is usually admin.
• <password> — The Swarm administrative password, required for all management API calls that perform actions.
• <newAccessKeyID> — The new access key ID for the target S3 bucket.
• <newSecretAccessKey> — The new secret access key for the target S3 bucket.
• <nodeIP> — The IP address of any Swarm node in the cluster.
• <s3feedid> — The small integer feed ID that is associated with the S3 Backup feed. It appears as the feed's ID field in the Swarm UI.

Using Feed Actions

Clicking on an existing feed in the Feeds list opens the Feed Settings page, with the existing settings populated. The Actions (gear) icon menu at the top right supports multiple feed actions, appropriate to the type of feed:

Troubleshooting Feeds

• Feed Diagnostics: Double-click a blocked feed to open the settings page, click the gear icon, and select View feed table, which displays the SNMP Repository Dump for the selected node to troubleshoot. (v2.0)
  

  

  Review the feedPluginState status to identify the blockage. 
  Example: feedPluginState blocked: Destination cluster onyx1 reports invalid request: Castor-System-Cluster value must refer to a remote cluster on RETRIEVE request

• Idle Feeds: A feed can appear to be idle with items still queued for processing. Plan for the fact that feed status reporting is a best-effort snapshot, not a low-latency or guaranteed transaction mechanism.

• Feed Prioritization: Domain and bucket context objects are prioritized for all types of feeds; this improves usability when remote sites are initiated.

• Retries for Blocked Feeds: Blocked feeds are retried every 20 minutes, but if the definition for a blocked feed is changed, it triggers an immediate attempt with the new definition, which may clear the blockage. (v10.1)