Module aws_sdk_backup::types

source ·
Expand description

Data structures used by operation inputs/outputs.

Modules§

  • Builders
  • Error types that AWS Backup can respond with.

Structs§

  • A list of backup options for each resource type.

  • Contains detailed information about a backup job.

  • This is a summary of jobs created or running within the most recent 30 days.

    The returned summary may contain the following: Region, Account, State, RestourceType, MessageCategory, StartTime, EndTime, and Count of included jobs.

  • Contains an optional backup plan display name and an array of BackupRule objects, each of which specifies a backup rule. Each rule in a backup plan is a separate scheduled task and can back up a different selection of Amazon Web Services resources.

  • Contains an optional backup plan display name and an array of BackupRule objects, each of which specifies a backup rule. Each rule in a backup plan is a separate scheduled task.

  • An object specifying metadata associated with a backup plan template.

  • Contains metadata about a backup plan.

  • Specifies a scheduled task used to back up a selection of resources.

  • Specifies a scheduled task used to back up a selection of resources.

  • Used to specify a set of resources to a backup plan.

    Specifying your desired Conditions, ListOfTags, NotResources, and/or Resources is recommended. If none of these are specified, Backup will attempt to select all supported and opted-in storage resources, which could have unintended cost implications.

  • Contains metadata about a BackupSelection object.

  • Contains metadata about a backup vault.

  • Contains DeleteAt and MoveToColdStorageAt timestamps, which are used to specify a lifecycle for a recovery point.

    The lifecycle defines when a protected resource is transitioned to cold storage and when it expires. Backup transitions and expires backups automatically according to the lifecycle that you define.

    Backups transitioned to cold storage must be stored in cold storage for a minimum of 90 days. Therefore, the “retention” setting must be 90 days greater than the “transition to cold after days” setting. The “transition to cold after days” setting cannot be changed after a backup has been transitioned to cold.

    Resource types that are able to be transitioned to cold storage are listed in the "Lifecycle to cold storage" section of the Feature availability by resource table. Backup ignores this expression for other resource types.

  • Contains an array of triplets made up of a condition type (such as StringEquals), a key, and a value. Used to filter resources using their tags and assign them to a backup plan. Case sensitive.

  • Includes information about tags you define to assign tagged resources to a backup plan.

  • Contains information about which resources to include or exclude from a backup plan using their tags. Conditions are case sensitive.

  • A list of parameters for a control. A control can have zero, one, or more than one parameter. An example of a control with two parameters is: "backup plan frequency is at least daily and the retention period is at least 1 year". The first parameter is daily. The second parameter is 1 year.

  • A framework consists of one or more controls. Each control has its own control scope. The control scope can include one or more resource types, a combination of a tag key and value, or a combination of one resource type and one resource ID. If no scope is specified, evaluations for the rule are triggered when any resource in your recording group changes in configuration.

    To set a control scope that includes all of a particular resource, leave the ControlScope empty or do not pass it when calling CreateFramework.

  • The details of the copy operation.

  • Contains detailed information about a copy job.

  • This is a summary of copy jobs created or running within the most recent 30 days.

    The returned summary may contain the following: Region, Account, State, RestourceType, MessageCategory, StartTime, EndTime, and Count of included jobs.

  • This is a resource filter containing FromDate: DateTime and ToDate: DateTime. Both values are required. Future DateTime values are not permitted.

    The date and time are in Unix format and Coordinated Universal Time (UTC), and it is accurate to milliseconds ((milliseconds are optional). For example, the value 1516925490.087 represents Friday, January 26, 2018 12:11:30.087 AM.

  • Contains detailed information about a framework. Frameworks contain controls, which evaluate and report on your backup events and resources. Frameworks generate daily compliance results.

  • Contains detailed information about all of the controls of a framework. Each framework must contain at least one control.

  • Pair of two related strings. Allowed characters are letters, white space, and numbers that can be represented in UTF-8 and the following characters: + - = . _ : /

  • A legal hold is an administrative tool that helps prevent backups from being deleted while under a hold. While the hold is in place, backups under a hold cannot be deleted and lifecycle policies that would alter the backup status (such as transition to cold storage) are delayed until the legal hold is removed. A backup can have more than one legal hold. Legal holds are applied to one or more backups (also known as recovery points). These backups can be filtered by resource types and by resource IDs.

  • Contains an array of Transition objects specifying how long in days before a recovery point transitions to cold storage or is deleted.

    Backups transitioned to cold storage must be stored in cold storage for a minimum of 90 days. Therefore, on the console, the “retention” setting must be 90 days greater than the “transition to cold after days” setting. The “transition to cold after days” setting cannot be changed after a backup has been transitioned to cold.

    Resource types that are able to be transitioned to cold storage are listed in the "Lifecycle to cold storage" section of the Feature availability by resource table. Backup ignores this expression for other resource types.

  • A structure that contains information about a backed-up resource.

  • A list of conditions that you define for resources in your restore testing plan using tags.

    For example, "StringEquals": { "Key": "aws:ResourceTag/CreatedByCryo", "Value": "true" },. Condition operators are case sensitive.

  • Contains detailed information about the recovery points stored in a backup vault.

  • Contains detailed information about a saved recovery point.

  • Contains information about the backup plan and rule that Backup used to initiate the recovery point backup.

  • This is a recovery point which is a child (nested) recovery point of a parent (composite) recovery point. These recovery points can be disassociated from their parent (composite) recovery point, in which case they will no longer be a member.

  • This specifies criteria to assign a set of resources, such as resource types or backup vaults.

  • Contains information from your report plan about where to deliver your reports, specifically your Amazon S3 bucket name, S3 key prefix, and the formats of your reports.

  • Contains information from your report job about your report destination.

  • Contains detailed information about a report job. A report job compiles a report based on a report plan and publishes it to Amazon S3.

  • Contains detailed information about a report plan.

  • Contains detailed information about a report setting.

  • Contains information about the restore testing plan that Backup used to initiate the restore job.

  • This is a summary of restore jobs created or running within the most recent 30 days.

    The returned summary may contain the following: Region, Account, State, ResourceType, MessageCategory, StartTime, EndTime, and Count of included jobs.

  • Contains metadata about a restore job.

  • This contains metadata about a restore testing plan.

  • This contains metadata about a restore testing plan.

  • This contains metadata about a restore testing plan.

  • This contains metadata about a restore testing plan.

  • Required: Algorithm; Required: Recovery point types; IncludeVaults(one or more). Optional: SelectionWindowDays ('30' if not specified);ExcludeVaults (list of selectors), defaults to empty list if not listed.

  • This contains metadata about a specific restore testing selection.

    ProtectedResourceType is required, such as Amazon EBS or Amazon EC2.

    This consists of RestoreTestingSelectionName, ProtectedResourceType, and one of the following:

    • ProtectedResourceArns

    • ProtectedResourceConditions

    Each protected resource type can have one single value.

    A restore testing selection can include a wildcard value ("*") for ProtectedResourceArns along with ProtectedResourceConditions. Alternatively, you can include up to 30 specific protected resource ARNs in ProtectedResourceArns.

    ProtectedResourceConditions examples include as StringEquals and StringNotEquals.

  • This contains metadata about a restore testing selection.

  • This contains metadata about a restore testing selection.

  • This contains metadata about a restore testing selection.

Enums§

  • When writing a match expression against AggregationPeriod, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against BackupJobState, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against BackupJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against BackupVaultEvent, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against ConditionType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against CopyJobState, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against CopyJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against LegalHoldStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against RecoveryPointStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against RestoreDeletionStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against RestoreJobState, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against RestoreJobStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against RestoreTestingRecoveryPointSelectionAlgorithm, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against RestoreTestingRecoveryPointType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against RestoreValidationStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against StorageClass, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against VaultState, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
  • When writing a match expression against VaultType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.