Hello and welcome to this lecture, in this lecture, we look at the various back up and restore methodologies.
Let's start by looking at what you should consider backing up in a carbon atoms cluster.
So far in this course, we have deployed a number of different applications on our carbon atoms closer
using deployment parts and service definition files.
We know that the ETSI the cluster is where all cluster related information is stored, and if your applications
are configured with persistent storage, then that is another candidate for backups with respect to
resources that we created in the cluster.
At times we use the imperative way of creating an object by executing a command such as well, creating
a namespace or a secret or config map or at times for exposing applications.
And at times, we used the declarative approach by first creating a definition file and then running
the cube controller play comment on that file.
This is the preferred approach if you want to save your configuration, because now you have all the
objects required for a single application in the form of object definition files in a single folder.
This can easily be reused at a later time or shared with others.
Of course, you must have a copy of these files saved at all times.
A good practice is to store these on source code repositories.
That way it can be maintained by a team.
The source code repository should be configured with the right backup solutions with managed or public
source code repositories like GitHub.
You don't have to worry about this with that.
Even when you lose your entire cluster, you can redeploy your application on the cluster by simply
applying these configuration files on them.
While the declarative approach is the preferred approach, it is not necessary that all of your team
members stick to those standards.
What if someone created an object the imperative way without documenting that information anywhere?
So a better approach to backing up resource configuration is to query the Cuba API server, query the
Cuba server using the Q control or by accessing the API server directly and save all resource configurations
for all objects created on the cluster as a copy.
For example, one of the commands that can be used in a backup script is to get all ports and deployments
and services in all namespace using the cube control utilities get all command and extract the output
in a Yamal format, then save that file.
And that's just for a few resource group.
There are many other resource groups that must be considered.
Of course, you don't have to develop that solutions yourself.
There are tools like ARGE are now called Volero by Habtoor You that can do this for you.
It can help in taking backups of your communities cluster using the coordinators API.
That is now move on to Ezzedine.
The SCD cluster stores information about the state of our cluster, so information about the cluster
itself, the nodes and every other resources created within the cluster are stored here.
So instead of backing up resources as before, you may choose to back up the server itself.
As we have seen, the SCD cluster is hosted on the master nodes while configuring SCD with specified
a location where all the data would be stored.
The data directory that is the directory that can be configured to be backed up by your backup to.
Etc. also comes with a built in snapshot solution, you can take a snapshot of the city database by
using the ETSI, the control utilities snapshot, save Kimmett, give the snapshot a name, snapshot
DBE.
A snapshot file is created by the name in the current directory.
If you want it to be created in another location, specify the full path.
You can view the status of the backup using the Snapshot Status Command.
To restore the cluster from this back up at a later point in time.
First stop the overservice has the restore process will require you to restart the Exelis cluster and
the server depends on it.
Then run the controls, snapshot, restore command with the path set to the path of the backup file,
which is the snapshot to be filed when SCADA restores from a backup, it initializes a new cluster configuration
and configures the members of SCD as new members to a new cluster.
This is to prevent a new member from accidentally joining an existing cluster and running this command.
And new data directory is created in this example at location var lib city from backup.
We then configure the etsi the configuration file to use the new data directory.
Then reload the service demon and restart active service.
Finally, start the Kubis overservice, your Kloster should now be back in the original state.
A quick note before I let you go, with all the outside commands, remember to specify the cert files
for authentication, specify the end point to the outside cluster and the senior cert, the server cert
and the key.
So we have seen two options, a backup using a CD and a backup by querying the server.
Now, both of these have their pros and cons.
Well, if you're using a managed environment, then at times you may not even have access to the outside
cluster.
In that case, backup by acquiring the server is probably the better way.
Well, that's it for this demo.
Head over to the practice test and practice backing up a CD in a cluster and then restoring from backups.