Forest Recovery: Add backup locations
This article describes how to add Backup Locations in Cayosoft Guardian.
Backup Locations are network file shares, Azure blob storages, or Amazon S3 storage where the backup files can be created and managed by Cayosoft Guardian. DC Backups are registered backup files that are located in Backup Locations.
Add a backup location
Network storage that supports SMB (Server Message Block) protocol version 3.0 (or higher), Amazon S3, and Azure blob storages can be added as Backup Locations in Cayosoft Guardian.
- Open the Cayosoft Guardian web portal.
- Expand the Forest Recovery node.
- Select the Backup Locations node.
-
Expand the Add drop-down and select a backup locations type:
- Network share
- Azure Blob Storage
- Amazon S3.
- Complete the below fields depending on the backup location type.
- Click Add to add a new backup location.
Network share
| Option | Description |
|---|---|
| Location | Provide a network path to a shared location. For example, |
| Account name |
Enter the name of the account to access the specified share in a
|
| Password | Provide a password for the account used to connect to the share. |
| I want to use this storage with this Cayosoft Guardian installation |
Select this checkbox to allow Cayosoft Guardian to store backups to this location. This checkbox is unchecked by default. (missing or bad snippet)It is not recommended to use the same network storage for multiple installations of Cayosoft Guardian to avoid conflicts. Each instance of Cayosoft Guardian enumerates all stored backup files in the designated folder and deletes backups based on its retention policies. |
Azure Blob storage
| Option | Description |
|---|---|
| Azure subscription | Click the Browse icon and select your Azure subscription. The connection account must have a Storage Blob Data Contributor role in the subscription to create a resource group and all related resources. In case you would like to use a pre-created resource group, the connection account must have a Storage Blob Data Contributor role in the resource group. |
| Resource group name | Provide a name for the resource group. A resource group with the specified name will be created. To use an existing resource group, replace the automatically generated name with the name of your pre-created resource group. If left at the default, the resource group will be named CayosoftGuardianBackups. |
| Storage account name |
Provide a name for a storage account. A storage account with the specified name will be created. To use an existing storage account, replace the automatically generated name with the name of your pre-existing storage account. If no name is provided, one will be auto-generated in the format When a new storage account is created, Cayosoft Guardian applies the following security settings automatically:
|
| Location | Select a location. For example, East US. If no location is specified, the default region is East US. |
| Azure blob container name | Provide a name for the blob container within the Azure Storage account. Blob containers group and organize blobs (binary large objects) similarly to directories in a file system. For example, |
| Make storage immutable |
Enable this option to create the blob container in immutable mode. Immutable storage prevents stored backup data from being modified or deleted for the duration of the retention period. Azure enforces the immutability settings using time-based immutability policies on the blob container, providing additional protection against accidental or malicious data changes. See How immutable storage works for details. |
| Retention period (days) | Specify the number of days that Azure must retain the immutable backup data. During this period, the data cannot be altered or removed. After the retention period expires, backups become deletable according to Azure immutability rules. This field is required when Make storage immutable is enabled. |
When using an existing blob container, the immutability setting must be consistent with the container's current configuration:
- An error will occur, if Make storage immutable is enabled but
- the existing container does not have an immutability policy
- the existing container already has an immutability policy with a different retention period
- the existing container already has an immutability policy.
Similarly, when using an existing storage account, it must belong to the specified resource group and location. Mismatches will result in an error.
Amazon S3 storage
| Option | Description |
|---|---|
| AWS account | Click the Browse icon and select your AWS account. |
| Bucket name | Provide a unique identifier used to organize and manage your data in Amazon S3. Buckets are the containers for objects (files) stored in Amazon S3. For example, |
| AWS region | Select the AWS region where the S3 bucket resides or will be created. For example, |
| Folder name | Provide a folder name. A logical folder (prefix) with the specified name will be created inside the S3 bucket. If no folder name is specified, the default name backups will be used. |
| Make storage immutable |
Enable this option to apply an Object Lock policy to the S3 bucket, ensuring that backup data cannot be modified or deleted during the retention period. Immutable storage protects backups from accidental changes, deletion, or tampering by enforcing AWS WORM (Write Once, Read Many) compliance in Compliance mode. See How immutable storage works for details. |
| Retention period (days) | Specify the number of days that S3 must retain the immutable backup data. During this period, objects cannot be changed or removed. After the retention period expires, the data becomes deletable according to AWS Object Lock rules. |
When using an existing S3 bucket with the Make storage immutable option:
- Object Lock can only be enabled at the time the bucket is created. It cannot be enabled on an existing bucket that was created without Object Lock.
- If Make storage immutable is enabled but the existing bucket does not have Object Lock and versioning enabled, an error will occur.
- If Make storage immutable is disabled but the existing bucket already has Object Lock enabled, an error will occur.
NOTE: Store additional backup files offsite in a secure location so that no backup file of a unique domain exists in only one physical site at any time. This precaution provides extra redundancy in case of physical disaster or theft.
How immutable storage works
The Make storage immutable option protects backup data from modification or deletion by leveraging native cloud provider immutability mechanisms. When enabled, backup files written to the storage cannot be altered or removed until the specified retention period expires. This provides ransomware protection and safeguards against accidental or malicious data loss.
Azure Blob Storage — Time-based immutability policies
When you enable immutable storage for Azure Blob Storage, Cayosoft Guardian performs the following steps:
Creates or reuses a storage account. New storage accounts are created with hardened security settings: TLS 1.2 minimum, public blob access disabled, shared key access disabled, HTTPS-only traffic, Standard LRS redundancy, and StorageV2 account type.
Creates a blob container. A new blob container is created with public access set to None and tagged with metadata identifying it as a Cayosoft Guardian Backup Location.
Applies a time-based immutability policy. After the container is created, Cayosoft Guardian applies a time-based immutability policy to the container. This policy specifies the
ImmutabilityPeriodSinceCreationInDaysvalue equal to the user-specified Retention period (days). Azure counts the retention period from each blob's creation time.Enforces WORM protection. Once the immutability policy is active, blobs written to the container cannot be modified or deleted until their individual retention period (measured from the blob's creation time) expires. This is Azure's native Write Once, Read Many (WORM) storage mechanism applied at the container level.
Propagates settings to backup agents. The
isImmutableandretentionPeriodInDaysproperties are stored in the Cayosoft Guardian data model and are passed to backup agents during backup plan execution, ensuring consistent enforcement.
Validation on existing containers: If the specified blob container already exists, Cayosoft Guardian validates that the container's immutability settings are consistent with the requested configuration. Errors are raised if the container lacks an immutability policy when one is requested, if the existing retention period differs from the requested value, or if the container has an immutability policy when non-immutable storage is requested.
Amazon S3 — Object Lock (Compliance mode)
When you enable immutable storage for Amazon S3, Cayosoft Guardian performs the following steps:
Creates an S3 bucket with Object Lock enabled. The bucket is created with
ObjectLockEnabledForBucketset to true. This is required at bucket creation time — Object Lock cannot be added to an existing bucket that was created without it.Enables bucket versioning. Versioning is a prerequisite for S3 Object Lock and is enabled automatically.
Configures Object Lock. An Object Lock configuration is applied to the bucket.
Sets per-object retention on upload. When individual backup files are uploaded, each object is tagged with Compliance mode retention and a
RetainUntilDatecalculated as the current time plus the specified Retention period (days). In Compliance mode, no user — including the AWS root account — can delete or overwrite the object before the retention date expires.Propagates settings to backup agents. The
isImmutableflag andretentionPeriodInDaysvalue are passed to backup agents. The agent creates an S3 storage client with WORM options (ObjectLockMode = Compliance) so that every backup file uploaded is individually protected.
Validation on existing buckets: If using an existing bucket, Cayosoft Guardian verifies that both versioning and Object Lock are properly enabled. If immutable storage is requested but the bucket lacks Object Lock, or if immutable storage is not requested but the bucket has Object Lock, an error is will be thrown.
Key differences between Azure and AWS immutability
| Aspect | Azure Blob Storage | Amazon S3 |
|---|---|---|
| Immutability scope | Container level — all blobs in the container are subject to the same policy | Object level — each uploaded object gets its own retention date |
| Mechanism | Time-based immutability policy | Object Lock in Compliance mode |
| Retention counting | Azure counts from each blob's creation time automatically | Cayosoft Guardian calculates an explicit RetainUntilDate per object at upload time |
| Retroactive enablement | Can apply an immutability policy to an existing container | Object Lock must be enabled at bucket creation time; cannot be added retroactively |
| Compliance level | Blobs cannot be modified or deleted during retention | Compliance mode — even the root account cannot delete objects during retention |
How to add/delete credentials
To edit the credentials:
- Open the Cayosoft Guardian web portal.
- Expand the Forest Recovery node.
- Select the Backup Locations node.
- Select the storage and click Properties.
- On the General tab, click Edit.
- Click Add + and select the credentials to be added.
For Token credential, specify:
- Account name — the account name for which the credential is being configured.
- Refresh token — the refresh token associated with the account.
- Type — the type of token credentials.
For Password credential, specify:
- Account name — the account name for which the credential is being configured.
- Password — the password associated with the account.
- Type — the type of password credentials.
To delete the credentials:
- Expand the Forest Recovery node.
- Select the Backup Locations node.
- Select the storage and click Properties.
- On the General tab, click Edit.
- Click the vertical kebab icon and click Delete.
- Confirm the deletion.
Comments
0 comments
Please sign in to leave a comment.