You can customize your backup and restore settings.

MinIO gateway mode

The backup and restore operator and MinIO are deployed with the default settings. The MinIO can be deployed as a statefulset or it can be deployed as a proxy (gateway) to the external datastore. The default behavior is to deploy the MinIO as the statefulset.
Note: When the MinIO is deployed as the statefulset, the backup are stored in MinIO Persistent Volumes (PV), and the backups are not externalized. Which means when the Kubernetes cluster or the MinIO PV is deleted the backups will be erased. To avoid this, you must deploy MinIO as a gateway.

Deploying MinIO as gateway using tcxctl CLI mode:

The following procedure is used to deploy MinIO as a gateway using tcxctl CLI mode:
Note: You must use this procedure if you want to update the backup and restore after the VMware Telco Cloud Service Assurance deployment.
  • If you are configuring MinIO as gateway using AWS S3 or vSAN, update the parameters in the values.yaml file available in $TCSA_WORK_SPACE/tcx-deployer/product-helm-charts/tcsa.
    • For AWS S3, update minioDatastoreType=s3, bucketName, accesskey, and secretkey in the values.yaml file.
      backupAndRestore:
        # (string) minioDatastoreType is the storage backend for minio. Valid options are "s3", "nas" or "local"
        minioDatastoreType: s3
        # (string) the size of the minio storage. Set ONLY if datastoreType is local or nas
        storageSize:
        # (bool) Set to true if the storage backed is on NFS. Set ONLY if datastoreType is local or nas
        nfsProvisionerEnabled: false
        # (string) The IP address/hostname of the NFS server. Set only if minioDatastoreType is set to nas
        nfsServer:
        # (string) The NFS server path. Set only if minioDatastoreType is set to nas
        nfsPath:
        # (string) The S3 bucket name.
        bucketName: <s3-bucket-name>
        # The AWS Access key for S3
        s3AccessKey: <aws-access-key-for-s3>
        # The AWS Secret key for S3
        s3SecretKey: <aws-secret-key-for-s3>
    • For vSAN, update minioDatastoreType=nas, nfsProvisionerEnabled: true, nfsPath, nfsServer, and bucketName in the values.yaml file.
      backupAndRestore:
        # (string) minioDatastoreType is the storage backend for minio. Valid options are "s3", "nas" or "local"
        minioDatastoreType: nas
        # (string) the size of the minio storage. Set ONLY if datastoreType is local or nas
        storageSize: 8Gi
        # (bool) Set to true if the storage backed is on NFS. Set ONLY if datastoreType is local or nas
        nfsProvisionerEnabled: true
        # (string) The IP address/hostname of the NFS server. Set only if minioDatastoreType is set to nas
        nfsServer: <Server-IPAddress>
        # (string) The NFS server path. Set only if minioDatastoreType is set to nas
        nfsPath: <NFS-Path>
        # (string) The S3 bucket name.
        bucketName: <s3-bucket-name>
        # The AWS Access key for S3
        s3AccessKey:
        # The AWS Secret key for S3
        s3SecretKey:
      Note: The backups taken on the previous StatefulSet MinIO are not available in the updated MinIO as a gateway.
  • Trigger deployment using tcxctl CLI.
    root [ ~ ]# cd $TCSA_WORK_SPACE/tcx-deployer/clis
    root [ ~/base/tcx-deployer/clis ]# ./tcxctl deploy product --name tcsa --path <$TCSA_WORK_SPACE>/tcx-deployer --kubeconfig <your-kubeconfig-location> --registry-password <registry-password> --registry-username <registry-username> --timeout <time-in-mins>
After the deployment script exits, manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from the deployment VM.
root [ ~/base/tcx-deployer/scripts/deployment ]# kubectl get tcxproduct
NAME   STATUS            READY   MESSAGE                               AGE
tcsa   updateCompleted   True    All App CRs reconciled successfully   30h

Deploying MinIO as gateway using VMware Telco Cloud Automation UI:

The following procedure is used to deploy MinIO as a gateway using VMware Telco Cloud Automation mode:
  1. Launch the VMware Telco Cloud Automation and navigate to Inventory > Network Function.
  2. Click TCSA CNF and select Reconfigure.
  3. Upload the values.yaml file in VMware Telco Cloud Automation and update the AWS S3 or vSAN storage parameters in the reconfigure edit section as shown in the screenshot.
    • For AWS S3, update minioDatastoreType=s3, bucketName, accesskey, and secretkey in the values.yaml file.
      Note: The accesskey and secretkey are specific to the AWS account details. The bucketName is the user-defined name in which the backup is stored.
    • For VMware vSAN, update minioDatastoreType=nas, nfsProvisionerEnabled: true, nfsPath, nfsServer, and bucketNamein the values.yaml file.
      Note: For configuring the VMware vSAN file service, see Enabling VMware vSAN File Services topic. The details for obtaining the nfsServer and nfsPath are also mentioned in this section. The bucketName is the user-defined name in which the backup is stored.
  4. Click Next > Finish.
After succesful reconfiguration, manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from the deployment VM.
root [ ~/base/tcx-deployer/scripts/deployment ]# kubectl get tcxproduct
NAME   STATUS            READY   MESSAGE                               AGE
tcsa   updateCompleted   True    All App CRs reconciled successfully   30h

Changing the backup bucket

Procedure to override the bucket name using tcxctl CLI

The backup and restore is deployed with a default bucket vmware-tcsa-backup. To override the bucket name, you must update the bucketName in the values.yaml file.
backupAndRestore:
  # (string) minioDatastoreType is the storage backend for minio. Valid options are "s3", "nas" or "local"
  minioDatastoreType: 
  # (string) the size of the minio storage. Set ONLY if datastoreType is local or nas
  storageSize:
  # (bool) Set to true if the storage backed is on NFS. Set ONLY if datastoreType is local or nas
  nfsProvisionerEnabled: false
  # (string) The IP address/hostname of the NFS server. Set only if minioDatastoreType is set to nas
  nfsServer:
  # (string) The NFS server path. Set only if minioDatastoreType is set to nas
  nfsPath:
  # (string) The S3 bucket name.
  bucketName: <bucket-name>
  # The AWS Access key for S3
  s3AccessKey:
  # The AWS Secret key for S3
  s3SecretKey:
Trigger deployment using tcxctl CLI.
root [ ~ ]# cd $TCSA_WORK_SPACE/tcx-deployer/clis
root [ ~/base/tcx-deployer/clis ]# ./tcxctl deploy product --name tcsa --kubeconfig <your-kubeconfig-location> --helm-chart-path <$TCSA_WORK_SPACE>/tcx-deployer/product-helm-charts/tcsa --values-file <$TCSA_WORK_SPACE>/tcx-deployer/product-helm-charts/tcsa/values.yaml --timeout <time-in-mins> 
After the deployment script exits, manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from the deployment VM.
root [ ~/base/tcx-deployer/scripts/deployment ]# kubectl get tcxproduct
NAME   STATUS            READY   MESSAGE                               AGE
tcsa   updateCompleted   True    All App CRs reconciled successfully   30h

Procedure to override the bucket name using VMware Telco Cloud Service Assurance UI

If you are configuring MinIO as gateway using AWS S3 or vSAN, update the required parameters for AWS S3 or vSAN and update the bucket name in the values.yaml file.
backupAndRestore:
  # (string) minioDatastoreType is the storage backend for minio. Valid options are "s3", "nas" or "local"
  minioDatastoreType:
  # (string) the size of the minio storage. Set ONLY if datastoreType is local or nas
  storageSize:
  # (bool) Set to true if the storage backed is on NFS. Set ONLY if datastoreType is local or nas
  nfsProvisionerEnabled: false
  # (string) The IP address/hostname of the NFS server. Set only if minioDatastoreType is set to nas
  nfsServer:
  # (string) The NFS server path. Set only if minioDatastoreType is set to nas
  nfsPath:
  # (string) The S3 bucket name.
  bucketName: <bucket-name>
  # The AWS Access key for S3
  s3AccessKey: 
  # The AWS Secret key for S3
  s3SecretKey: 
Note: The backups taken on the previous StatefulSet MinIO are not available after the mode change to AWS S3 or vSAN.
  1. Launch the VMware Telco Cloud Automation and navigate to Inventory > Network Function.
  2. Click TCSA CNF and select Reconfigure.
  3. Upload the values.yaml file in VMware Telco Cloud Automation.
    If you are configuring MinIO as gateway using AWS S3 or vSAN, update the required parameters for AWS S3 or vSAN and update the bucket name in the values.yaml file.
    backupAndRestore: 
    # (string) minioDatastoreType is the storage backend for minio. Valid options are "s3", "nas" or "local"
    minioDatastoreType: 
    # (string) the size of the minio storage. Set ONLY if datastoreType is local or nas.
    storageSize: 
    # (bool) Set to true if the storage backed is on NFS. Set ONLY if datastoreType is local or nas.
    nfsProvisionerEnabled: false 
    # (string) The IP address/hostname of the NFS server. Set only if minioDatastoreType is set to nas.
    nfsServer:
    # (string) The NFS server path. Set only if minioDatastoreType is set to nas.
    # The bucket name.
    bucketName: <bucket-name>
    # The AWS Access key for S3
    s3AccessKey:
    # The AWS Secret key for S3
    s3SecretKey:
    Note: The backups taken on the previous StatefulSet MinIO are not available after the mode change to AWS S3 or vSAN.
  4. Click Next > Finish.
  5. After succesful reconfiguration, manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from the deployment VM.
    root [ ~/base/tcx-deployer/scripts/deployment ]# kubectl get tcxproduct
    NAME   STATUS            READY   MESSAGE                               AGE
    tcsa   updateCompleted   True    All App CRs reconciled successfully   30h
Note: The backups taken on the previous bucket will not be available in the new bucket.

If you perform a backup while Elasticsearch is not running, the backup can fail, and deleting it can delete the CR. If Elasticsearch is unavailable at the time of deletion, the Elasticsearch snapshot data is not deleted, but the backup CR is deleted.