CloudCasa is a powerful and easy-to-use Kubernetes backup and cloud database backup service for developers, DevOps, Platform engineers and IT Ops teams. With CloudCasa, you don't have to be a storage or data protection expert to get started with backing up your cluster resources and their persistent data.
Just follow the simple steps below to get started with CloudCasa or Velero management for Kubernetes backups.
CloudCasa for Velero makes managing your Velero backup jobs easy. The steps below walk through the process of creating a new backup definition in the CloudCasa UI for clusters in Velero. However, since CloudCasa communicates with Velero in real time, backup jobs can be invoked ad hoc from the CloudCasa UI or can be run directly from Velero. CloudCasa also leverages schedules defined in Velero to ensure that your clusters are continuously protected.
This quick backup guide helps you walk through the process of identifying existing Velero backups and create new Velero backup jobs in CloudCasa.
Point your favorite web browser to signup.cloudcasa.io and create an account. No payment information is required for the Free service plan. Once you've signed in, you can invite other people to join your organization under Configuration/Users.
From the menu bar, go to Configuration > Clusters.
Click "Add cluster +" to create a new cluster. Ensure you select the option to "Manage an existing Velero instance". Once added, pick your preferred installation method to install the CloudCasa Agent to manage Velero on your cluster. Once the installation of the agent on your cluster is completed, the cluster will automatically be shown as "Active" in the portal, and an initial inventory of Velero Custom Resources (CRs) will be done.
CloudCasa will auto-detect the Velero installation on your cluster. If the cluster has more than one Velero installation, please set the Velero namespace to manage under the Advanced Settings.
CloudCasa will automatically inventory all Velero CRs on agent installation or restart. The cataloged CRs include Backup, BackupStorageLocation, VolumeSnapshotLocation, Restore and Schedule.
Under Protection > Clusters page, a Cluster overview is available where you can review the dashboard, backups, restores, recovery points, activities and settings.
During initial cluster inventory, following the cluster registration, CloudCasa will identify any existing Velero CRs. This includes any Backups, Restores, Recovery Points, Activities, or Special Settings in the Velero instance. Pre-existing backup jobs can be viewed by selecting the cluster under the "Protection" tab and then clicking on Backups at the bottom of the screen.
You can manually run any of these existing backup jobs by hovering over the “Actions” icon on the far right, and then selecting “Run now”.
To create a new Backup job for your Velero clusters in CloudCasa, go to the Dashboard or Protection > Clusters > Backups and Click the “Define backup +” button. The “Define Backup +” button will open a wizard to define a new backup job for your cluster. First, select the Velero cluster that you would like to back up. Click “Next”.
Next, the “Selections” tab allows you to define what resources will be included in the backup. You can protect the entire cluster, or you can choose to exclude specific namespaces. If you do not need to protect the entire cluster, but only certain namespaces, you can “Select namespaces” and chose individual namespaces, or multiple namespaces to be included in the backup job. You also have the option to select resource types or labels to define a backup at a more granular level. Finally, you will specify a backup type: Snapshot or Filesystem Backup or choose to follow pod annotations during runtime. Once Selections are made, click “Next.”
In this step in the backup Job creation, you have the option to specify some Velero-specific settings. First, specify if the backup should include cluster scope resources. Then you have the ability to define the backup Storage location, as well as multiple locations for the snapshot. Next, provide the cron spec to assign a schedule to this Velero backup job. And finally, specify a retention for the backup.
Once you have defined the Velero Settings, click “Next”
App Hooks is another optional step in the backup process that allows you to add pre and/or post App Hooks to the backup job. App hooks can be used to execute custom code at specific points in the backup and restore process.
Click “Next” and the “Summary” step provides an overview of the new backup job definition, including the protected resources, custom settings, schedules, and app hooks included in the job. At this point, you must give the new backup job a name, and add any optional “tags” for the job.
You can choose to run the job immediately and monitor the job's progress realtime in the Activity Page of the Dashboard. At the end of the job, Velero logs are also available in the Activity tab.
That's all there is to it! You can add as many clusters as you have, create backup job definitions for your different use cases, and you can centrally manage your velero installations across multiple clusters.
The CloudCasa agent must be installed on every Kubernetes cluster that you want to protect. Installation and configuration is rapid and easy - just follow the steps below which include the ability to auto-discovery your clusters in your cloud accounts.
Point your favorite web browser to home.cloudcasa.io and create an account. No payment information is required for the Free service plan. Once you've signed in, you can invite other people to join your organization under Configuration/Users.
If some of your Kubernetes clusters are running in AWS, Azure, or GCP, we recommend adding your cloud accounts under Configuration/Cloud Accounts. This allows CloudCasa to auto-discover your EKS, AKS, and GKE clusters, back up EKS, AKS, and GKE cluster parameters, auto-create clusters on restore, and automatically back up non-CSI EBS volumes on EKS. For some configurations, it also gives you the option of auto-installing the agent.
If your clusters were auto-discovered, you'll just need to find them in the Clusters list under your cloud account in Configuration/Cloud Accounts and click on the install icon for each one. If not, you can add them manually by clicking Add cluster under Protection/Clusters Overview. Then enter your cluster name and description and click Register cluster. Either way, you will see a cluster ID and a kubectl command to run that will install a lightweight agent on the cluster. If you are installing via our Helm chart or via a partner marketplace instead, make a note of the Cluster ID and follow the instructions specific to your installation method. Once installed, the agent will connect and register itself with the CloudCasa service, completing the process.
A backup policy allows you to define when backups that use it will run, and for how long they will be retained. You can have multiple schedules with different retention times in one policy. For example, a policy may specify the creation of hourly backups that are retained for 7 days, and daily backups that are retained for 30 days. You can add or edit policies under Configuration/Policies. Add a new one by clicking the "Add policy" button.
Go to the dashboard and click Define Backup. Enter the name for your backup and select your cluster. Choose what namespaces to protect and/or select resources by tag. Choose whether to create local snapshots of your PVs or copy them to CloudCasa’s secure storage. By default, everything will be protected including PVs. Finally, select the policy to apply. If you create a backup with no policy, it will not run automatically but can be started manually on an ad hoc basis.
That's all there is to it! Now you can sit back and relax, knowing that your clusters are protected.
If you don't already have a CloudCasa account, you can create one now for free!
Select the Configuration tab and select Cloud Accounts. Then click Add Cloud Account and select Amazon Web Service. Then click Next and hit the Launch Stack button. This will open a browser tab that will prompt you to sign in to AWS, and will then launch a CloudFormation stack that will grant CloudCasa the access it needs. Be sure to log in as an administrator so that CloudFormation can run.
Do this for each of your AWS account containing RDS databases. After adding your accounts, any RDS databases in them will be auto-discovered and appear in the CloudCasa UI under Protection/Databases Overview.
Go to Protection/Databases Backups and click the “Define Backup” button in the upper right corner of the screen. The “Add backup” pane will open, and you will be able to select one or more databases to include in your new backup definition. You can also choose to select the databases to include using AWS tags. In this case, any databases tagged with the name/value pairs you enter at the time the job runs will be selected. Click “Next” once you have chosen databases to proceed to the next page. Here you can set a name for your backup and choose whether or not to have it copy to another region. Then click "Next" again.
If you are protecting a database that is part of a Kubernetes application, you may want to use the same backup policy that you use for the application’s namespace. You can also create a new policy, or select "None" if you want to initiate backups manually. When selecting "None", you can choose to enable the Run Now option to start an ad-hoc backup immediately.
this quick restore guide to help make the process as easy for you as possible.
First, does the cluster you wish to restore to exist or do you need to re-create it? If
it exists, and is registered in CloudCasa, you can go on to step 3. If it doesn’t, you
will need to create a new cluster. If your backup used CSI snapshots of persistent
volumes (PVs) rather than copies, you will need to create it using storage that has
access to your existing snapshots, and the CSI driver will need to have the same
name as before so that your snapshots can be accessed.
If you are restoring an AKS or EKS cluster, and you have linked your Azure or AWS
cloud accounts under Configuration/Cloud Accounts, CloudCasa will have backed up
the cloud metadata associated with your cluster. This will allow it to create a new
cluster for you automatically, if you wish. In this case, skip ahead to step 3.
If you had to re-create your cluster, or if the cloudcasa-io namespace was deleted from
your cluster for some reason, you will need to re-register the cluster with CloudCasa
before you can start to restore. This is easy. Just log in to the CloudCasa UI, click on
the Protection tab and select Clusters. Now select your cluster in the list on the left. If
the CloudCasa agent isn’t running on the cluster the state will not be “Active”.
If you previously installed the agent using a Helm chart or marketplace like Rancher
or Digital Ocean 1-click, just make a note of the displayed cluster ID and re-install the
agent as you installed it before. If you previously installed the agent using
kubectl, note the kubectl command displayed at the bottom of the Cluster details
tab. This is the same kubectl command that you used to register your cluster the first
time. Run it against your cluster again now to re-register it.
Within a few minutes, the cluster state should change to Active in the setup tab. If it
doesn’t, verify that the agent pod has started in the cloudcasa-io namespace, and
that your network configuration allows outgoing TCP connections from your
cluster to the CloudCasa service (agent.cloudcasa.io) on port 443.
Go to the Protection tab, select Clusters Overview, and then select the cluster you wish to restore from. Next select the Recovery Points tab, find the recovery point you wish to restore from, and click the Restore icon.
The Restore Backup pane will now show you the backup name and timestamp of the
recovery point that you have selected. Next you can choose whether you want to restore
all namespaces in the backup, or only selected namespaces. If you choose the latter, you
will be given a list of namespaces from which you can select. Remember that only
namespaces included in the backup will be shown. Also, namespaces cannot be overwritten, so if you want to restore an existing namespace to a cluster, you will need to
delete the old one first. You can also rename namespaces when restoring (later). You can
add labels to be used to select resources for restore as well. These are key:value pairs,
and will not be validated by the UI. You can add them one at a time or add multiple pairs at
once, separated by spaces. Finally, you need to choose whether or not to restore PV
snapshots. If you toggle off the Exclude persistent volumes option (it is by defualt), PVs
will be restored using the snapshots or copies associated with the recovery point you’ve
selected. Remember that if you have selected specific namespaces or labels for restore,
only PVs in the namespac-es or with the labels you’ve selected will be restored.
Click Next again, and you’ll be presented with just a few more options. First you will be
prompted to name the restore job. Restore jobs have names so that you can more easily
track the status of them. The system will also save the job under its name so that you can
modify and re-run it later. You can name it whatever you want. Nobody will judge you.
Next you can choose an alternate cluster to restore to using the Cluster dropdown under
Select Destination. By default, the restore will go to the original cluster. If you are restoring
an EKS or AKS cluster, you can also choose to automatically create a new cluster to
restore to here. Finally, you can choose to rename restored namespaces by adding a
prefix and/or suffix. Remember that ALL restored name-spaces will have these prefixes or
suffixes added, so if you want to rename only specific namespaces, you should run
multiple restores and select those namespaces explicitly.
Now click Restore and CloudCasa will do the rest! You can watch the progress of your
restore job in the In Progress pane. You can also edit and re-run it, if you wish, under
the cluster’s Restore tab
That's all there is to it! Now you can sit back and relax, knowing that your clusters are protected.
You should first make sure that CloudCasa has your most up-to-date AWS data by
running an inventory. You can do this by going to the Cloud Accounts page under
the Configuration tab, and clicking the Run inventory button for each account that
you are interested in. The inventory jobs should complete within a few minutes.
You can see their status in the dashboard's Activity tab.
Now for the restore. Under the Protection tab, select Databases, then click the
Restore icon next to the database you wish to restore. The Restore RDS Instance
pane will appear. Next you must select the recovery point. Depending on what
backups are enabled for that database, you can choose recovery of the database
state at an arbitrary point in time (Restore from point in time) or recovery of a specific snapshot (Restore from available recovery points). Choose the recovery point
you want and click Next. Next enter a name for the restore job (we name our
restore jobs for tracking purposes, and so that they can be easily re-run) and the
DB identifier you wish to use for the new recovered database.
If you want to restore the database with the same parameters it had before, just
click Restore.
If you need to modify the DB parameters for the restore, you can do this by selecting Modify DB Parameters. There you can specify the Subnet Group, VPC Security
Group, DB Instance Class, etc. Click Save when you are done to run the restore
with your updated parameters.
Once the restore starts, you can monitor the status of it in the Activity tab or in the
Dashboard. When the status changes from Running to Completed, your recovery is
done!
Note that if you are restoring an Aurora cluster, only the primary read/write
instance will be automatically re-created. You will need to manually re-create any
additional replicas.
This video will take you through all the following points and give you a clear idea of how CloudCasa Backup and Restore works.
Streamline your Red Hat OpenShift operations with CloudCasa's powerful ...
Discover the ultimate flexibility in Kubernetes data protection with ...