#[non_exhaustive]pub struct PutBackupVaultLockConfigurationInputBuilder { /* private fields */ }
Expand description
A builder for PutBackupVaultLockConfigurationInput
.
Implementations§
Source§impl PutBackupVaultLockConfigurationInputBuilder
impl PutBackupVaultLockConfigurationInputBuilder
Sourcepub fn backup_vault_name(self, input: impl Into<String>) -> Self
pub fn backup_vault_name(self, input: impl Into<String>) -> Self
The Backup Vault Lock configuration that specifies the name of the backup vault it protects.
This field is required.Sourcepub fn set_backup_vault_name(self, input: Option<String>) -> Self
pub fn set_backup_vault_name(self, input: Option<String>) -> Self
The Backup Vault Lock configuration that specifies the name of the backup vault it protects.
Sourcepub fn get_backup_vault_name(&self) -> &Option<String>
pub fn get_backup_vault_name(&self) -> &Option<String>
The Backup Vault Lock configuration that specifies the name of the backup vault it protects.
Sourcepub fn min_retention_days(self, input: i64) -> Self
pub fn min_retention_days(self, input: i64) -> Self
The Backup Vault Lock configuration that specifies the minimum retention period that the vault retains its recovery points. This setting can be useful if, for example, your organization's policies require you to retain certain data for at least seven years (2555 days).
This parameter is required when a vault lock is created through CloudFormation; otherwise, this parameter is optional. If this parameter is not specified, Vault Lock will not enforce a minimum retention period.
If this parameter is specified, any backup or copy job to the vault must have a lifecycle policy with a retention period equal to or longer than the minimum retention period. If the job's retention period is shorter than that minimum retention period, then the vault fails that backup or copy job, and you should either modify your lifecycle settings or use a different vault. The shortest minimum retention period you can specify is 1 day. Recovery points already saved in the vault prior to Vault Lock are not affected.
Sourcepub fn set_min_retention_days(self, input: Option<i64>) -> Self
pub fn set_min_retention_days(self, input: Option<i64>) -> Self
The Backup Vault Lock configuration that specifies the minimum retention period that the vault retains its recovery points. This setting can be useful if, for example, your organization's policies require you to retain certain data for at least seven years (2555 days).
This parameter is required when a vault lock is created through CloudFormation; otherwise, this parameter is optional. If this parameter is not specified, Vault Lock will not enforce a minimum retention period.
If this parameter is specified, any backup or copy job to the vault must have a lifecycle policy with a retention period equal to or longer than the minimum retention period. If the job's retention period is shorter than that minimum retention period, then the vault fails that backup or copy job, and you should either modify your lifecycle settings or use a different vault. The shortest minimum retention period you can specify is 1 day. Recovery points already saved in the vault prior to Vault Lock are not affected.
Sourcepub fn get_min_retention_days(&self) -> &Option<i64>
pub fn get_min_retention_days(&self) -> &Option<i64>
The Backup Vault Lock configuration that specifies the minimum retention period that the vault retains its recovery points. This setting can be useful if, for example, your organization's policies require you to retain certain data for at least seven years (2555 days).
This parameter is required when a vault lock is created through CloudFormation; otherwise, this parameter is optional. If this parameter is not specified, Vault Lock will not enforce a minimum retention period.
If this parameter is specified, any backup or copy job to the vault must have a lifecycle policy with a retention period equal to or longer than the minimum retention period. If the job's retention period is shorter than that minimum retention period, then the vault fails that backup or copy job, and you should either modify your lifecycle settings or use a different vault. The shortest minimum retention period you can specify is 1 day. Recovery points already saved in the vault prior to Vault Lock are not affected.
Sourcepub fn max_retention_days(self, input: i64) -> Self
pub fn max_retention_days(self, input: i64) -> Self
The Backup Vault Lock configuration that specifies the maximum retention period that the vault retains its recovery points. This setting can be useful if, for example, your organization's policies require you to destroy certain data after retaining it for four years (1460 days).
If this parameter is not included, Vault Lock does not enforce a maximum retention period on the recovery points in the vault. If this parameter is included without a value, Vault Lock will not enforce a maximum retention period.
If this parameter is specified, any backup or copy job to the vault must have a lifecycle policy with a retention period equal to or shorter than the maximum retention period. If the job's retention period is longer than that maximum retention period, then the vault fails the backup or copy job, and you should either modify your lifecycle settings or use a different vault. The longest maximum retention period you can specify is 36500 days (approximately 100 years). Recovery points already saved in the vault prior to Vault Lock are not affected.
Sourcepub fn set_max_retention_days(self, input: Option<i64>) -> Self
pub fn set_max_retention_days(self, input: Option<i64>) -> Self
The Backup Vault Lock configuration that specifies the maximum retention period that the vault retains its recovery points. This setting can be useful if, for example, your organization's policies require you to destroy certain data after retaining it for four years (1460 days).
If this parameter is not included, Vault Lock does not enforce a maximum retention period on the recovery points in the vault. If this parameter is included without a value, Vault Lock will not enforce a maximum retention period.
If this parameter is specified, any backup or copy job to the vault must have a lifecycle policy with a retention period equal to or shorter than the maximum retention period. If the job's retention period is longer than that maximum retention period, then the vault fails the backup or copy job, and you should either modify your lifecycle settings or use a different vault. The longest maximum retention period you can specify is 36500 days (approximately 100 years). Recovery points already saved in the vault prior to Vault Lock are not affected.
Sourcepub fn get_max_retention_days(&self) -> &Option<i64>
pub fn get_max_retention_days(&self) -> &Option<i64>
The Backup Vault Lock configuration that specifies the maximum retention period that the vault retains its recovery points. This setting can be useful if, for example, your organization's policies require you to destroy certain data after retaining it for four years (1460 days).
If this parameter is not included, Vault Lock does not enforce a maximum retention period on the recovery points in the vault. If this parameter is included without a value, Vault Lock will not enforce a maximum retention period.
If this parameter is specified, any backup or copy job to the vault must have a lifecycle policy with a retention period equal to or shorter than the maximum retention period. If the job's retention period is longer than that maximum retention period, then the vault fails the backup or copy job, and you should either modify your lifecycle settings or use a different vault. The longest maximum retention period you can specify is 36500 days (approximately 100 years). Recovery points already saved in the vault prior to Vault Lock are not affected.
Sourcepub fn changeable_for_days(self, input: i64) -> Self
pub fn changeable_for_days(self, input: i64) -> Self
The Backup Vault Lock configuration that specifies the number of days before the lock date. For example, setting ChangeableForDays
to 30 on Jan. 1, 2022 at 8pm UTC will set the lock date to Jan. 31, 2022 at 8pm UTC.
Backup enforces a 72-hour cooling-off period before Vault Lock takes effect and becomes immutable. Therefore, you must set ChangeableForDays
to 3 or greater.
Before the lock date, you can delete Vault Lock from the vault using DeleteBackupVaultLockConfiguration
or change the Vault Lock configuration using PutBackupVaultLockConfiguration
. On and after the lock date, the Vault Lock becomes immutable and cannot be changed or deleted.
If this parameter is not specified, you can delete Vault Lock from the vault using DeleteBackupVaultLockConfiguration
or change the Vault Lock configuration using PutBackupVaultLockConfiguration
at any time.
Sourcepub fn set_changeable_for_days(self, input: Option<i64>) -> Self
pub fn set_changeable_for_days(self, input: Option<i64>) -> Self
The Backup Vault Lock configuration that specifies the number of days before the lock date. For example, setting ChangeableForDays
to 30 on Jan. 1, 2022 at 8pm UTC will set the lock date to Jan. 31, 2022 at 8pm UTC.
Backup enforces a 72-hour cooling-off period before Vault Lock takes effect and becomes immutable. Therefore, you must set ChangeableForDays
to 3 or greater.
Before the lock date, you can delete Vault Lock from the vault using DeleteBackupVaultLockConfiguration
or change the Vault Lock configuration using PutBackupVaultLockConfiguration
. On and after the lock date, the Vault Lock becomes immutable and cannot be changed or deleted.
If this parameter is not specified, you can delete Vault Lock from the vault using DeleteBackupVaultLockConfiguration
or change the Vault Lock configuration using PutBackupVaultLockConfiguration
at any time.
Sourcepub fn get_changeable_for_days(&self) -> &Option<i64>
pub fn get_changeable_for_days(&self) -> &Option<i64>
The Backup Vault Lock configuration that specifies the number of days before the lock date. For example, setting ChangeableForDays
to 30 on Jan. 1, 2022 at 8pm UTC will set the lock date to Jan. 31, 2022 at 8pm UTC.
Backup enforces a 72-hour cooling-off period before Vault Lock takes effect and becomes immutable. Therefore, you must set ChangeableForDays
to 3 or greater.
Before the lock date, you can delete Vault Lock from the vault using DeleteBackupVaultLockConfiguration
or change the Vault Lock configuration using PutBackupVaultLockConfiguration
. On and after the lock date, the Vault Lock becomes immutable and cannot be changed or deleted.
If this parameter is not specified, you can delete Vault Lock from the vault using DeleteBackupVaultLockConfiguration
or change the Vault Lock configuration using PutBackupVaultLockConfiguration
at any time.
Sourcepub fn build(self) -> Result<PutBackupVaultLockConfigurationInput, BuildError>
pub fn build(self) -> Result<PutBackupVaultLockConfigurationInput, BuildError>
Consumes the builder and constructs a PutBackupVaultLockConfigurationInput
.
Source§impl PutBackupVaultLockConfigurationInputBuilder
impl PutBackupVaultLockConfigurationInputBuilder
Sourcepub async fn send_with(
self,
client: &Client,
) -> Result<PutBackupVaultLockConfigurationOutput, SdkError<PutBackupVaultLockConfigurationError, HttpResponse>>
pub async fn send_with( self, client: &Client, ) -> Result<PutBackupVaultLockConfigurationOutput, SdkError<PutBackupVaultLockConfigurationError, HttpResponse>>
Sends a request with this input using the given client.
Trait Implementations§
Source§impl Clone for PutBackupVaultLockConfigurationInputBuilder
impl Clone for PutBackupVaultLockConfigurationInputBuilder
Source§fn clone(&self) -> PutBackupVaultLockConfigurationInputBuilder
fn clone(&self) -> PutBackupVaultLockConfigurationInputBuilder
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreSource§impl Default for PutBackupVaultLockConfigurationInputBuilder
impl Default for PutBackupVaultLockConfigurationInputBuilder
Source§fn default() -> PutBackupVaultLockConfigurationInputBuilder
fn default() -> PutBackupVaultLockConfigurationInputBuilder
Source§impl PartialEq for PutBackupVaultLockConfigurationInputBuilder
impl PartialEq for PutBackupVaultLockConfigurationInputBuilder
Source§fn eq(&self, other: &PutBackupVaultLockConfigurationInputBuilder) -> bool
fn eq(&self, other: &PutBackupVaultLockConfigurationInputBuilder) -> bool
self
and other
values to be equal, and is used by ==
.impl StructuralPartialEq for PutBackupVaultLockConfigurationInputBuilder
Auto Trait Implementations§
impl Freeze for PutBackupVaultLockConfigurationInputBuilder
impl RefUnwindSafe for PutBackupVaultLockConfigurationInputBuilder
impl Send for PutBackupVaultLockConfigurationInputBuilder
impl Sync for PutBackupVaultLockConfigurationInputBuilder
impl Unpin for PutBackupVaultLockConfigurationInputBuilder
impl UnwindSafe for PutBackupVaultLockConfigurationInputBuilder
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
Source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left
is true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left(&self)
returns true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
Source§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the foreground set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red()
and
green()
, which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg()
:
use yansi::{Paint, Color};
painted.fg(Color::White);
Set foreground color to white using white()
.
use yansi::Paint;
painted.white();
Source§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
Source§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
Source§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Source§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
Source§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
Source§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
Source§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
Source§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the background set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red()
and
on_green()
, which have the same functionality but
are pithier.
§Example
Set background color to red using fg()
:
use yansi::{Paint, Color};
painted.bg(Color::Red);
Set background color to red using on_red()
.
use yansi::Paint;
painted.on_red();
Source§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
Source§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
Source§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
Source§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
Source§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Source§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling Attribute
value
.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold()
and
underline()
, which have the same functionality
but are pithier.
§Example
Make text bold using attr()
:
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);
Make text bold using using bold()
.
use yansi::Paint;
painted.bold();
Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Source§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi
Quirk
value
.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask()
and
wrap()
, which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk()
:
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);
Enable wrapping using wrap()
.
use yansi::Paint;
painted.wrap();
Source§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.
fn clear(&self) -> Painted<&T>
resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.Source§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the Condition
value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted
only when both stdout
and stderr
are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);