1

00:00:00,840 --> 00:00:07,180

Hello and welcome to this lecture, in this lecture, we look at the various back up and restore methodologies.



2

00:00:07,980 --> 00:00:12,480

Let's start by looking at what you should consider backing up in a carbon atoms cluster.



3

00:00:13,560 --> 00:00:18,540

So far in this course, we have deployed a number of different applications on our carbon atoms closer



4

00:00:18,540 --> 00:00:22,040

using deployment parts and service definition files.



5

00:00:22,860 --> 00:00:29,310

We know that the ETSI the cluster is where all cluster related information is stored, and if your applications



6

00:00:29,310 --> 00:00:36,120

are configured with persistent storage, then that is another candidate for backups with respect to



7

00:00:36,120 --> 00:00:38,130

resources that we created in the cluster.



8

00:00:38,190 --> 00:00:44,370

At times we use the imperative way of creating an object by executing a command such as well, creating



9

00:00:44,370 --> 00:00:49,650

a namespace or a secret or config map or at times for exposing applications.



10

00:00:50,640 --> 00:00:56,520

And at times, we used the declarative approach by first creating a definition file and then running



11

00:00:56,520 --> 00:00:58,770

the cube controller play comment on that file.



12

00:00:59,640 --> 00:01:05,220

This is the preferred approach if you want to save your configuration, because now you have all the



13

00:01:05,220 --> 00:01:11,520

objects required for a single application in the form of object definition files in a single folder.



14

00:01:11,940 --> 00:01:15,420

This can easily be reused at a later time or shared with others.



15

00:01:16,830 --> 00:01:20,610

Of course, you must have a copy of these files saved at all times.



16

00:01:21,540 --> 00:01:25,740

A good practice is to store these on source code repositories.



17

00:01:25,770 --> 00:01:28,290

That way it can be maintained by a team.



18

00:01:29,400 --> 00:01:35,190

The source code repository should be configured with the right backup solutions with managed or public



19

00:01:35,190 --> 00:01:37,000

source code repositories like GitHub.



20

00:01:37,290 --> 00:01:40,590

You don't have to worry about this with that.



21

00:01:41,010 --> 00:01:46,440

Even when you lose your entire cluster, you can redeploy your application on the cluster by simply



22

00:01:46,440 --> 00:01:49,020

applying these configuration files on them.



23

00:01:50,460 --> 00:01:55,800

While the declarative approach is the preferred approach, it is not necessary that all of your team



24

00:01:55,800 --> 00:01:57,540

members stick to those standards.



25

00:01:58,350 --> 00:02:02,920

What if someone created an object the imperative way without documenting that information anywhere?



26

00:02:03,690 --> 00:02:11,100

So a better approach to backing up resource configuration is to query the Cuba API server, query the



27

00:02:11,100 --> 00:02:18,120

Cuba server using the Q control or by accessing the API server directly and save all resource configurations



28

00:02:18,120 --> 00:02:21,410

for all objects created on the cluster as a copy.



29

00:02:22,320 --> 00:02:27,870

For example, one of the commands that can be used in a backup script is to get all ports and deployments



30

00:02:27,870 --> 00:02:34,920

and services in all namespace using the cube control utilities get all command and extract the output



31

00:02:34,920 --> 00:02:37,760

in a Yamal format, then save that file.



32

00:02:38,430 --> 00:02:40,480

And that's just for a few resource group.



33

00:02:41,190 --> 00:02:44,180

There are many other resource groups that must be considered.



34

00:02:44,850 --> 00:02:48,080

Of course, you don't have to develop that solutions yourself.



35

00:02:48,600 --> 00:02:55,200

There are tools like ARGE are now called Volero by Habtoor You that can do this for you.



36

00:02:55,770 --> 00:03:00,720

It can help in taking backups of your communities cluster using the coordinators API.



37

00:03:02,430 --> 00:03:04,530

That is now move on to Ezzedine.



38

00:03:05,610 --> 00:03:12,210

The SCD cluster stores information about the state of our cluster, so information about the cluster



39

00:03:12,210 --> 00:03:18,010

itself, the nodes and every other resources created within the cluster are stored here.



40

00:03:18,180 --> 00:03:24,060

So instead of backing up resources as before, you may choose to back up the server itself.



41

00:03:25,560 --> 00:03:32,700

As we have seen, the SCD cluster is hosted on the master nodes while configuring SCD with specified



42

00:03:32,710 --> 00:03:35,220

a location where all the data would be stored.



43

00:03:35,610 --> 00:03:42,000

The data directory that is the directory that can be configured to be backed up by your backup to.



44

00:03:43,970 --> 00:03:51,620

Etc. also comes with a built in snapshot solution, you can take a snapshot of the city database by



45

00:03:51,620 --> 00:03:58,340

using the ETSI, the control utilities snapshot, save Kimmett, give the snapshot a name, snapshot



46

00:03:58,640 --> 00:03:59,170

DBE.



47

00:03:59,930 --> 00:04:03,520

A snapshot file is created by the name in the current directory.



48

00:04:04,190 --> 00:04:08,180

If you want it to be created in another location, specify the full path.



49

00:04:09,050 --> 00:04:12,950

You can view the status of the backup using the Snapshot Status Command.



50

00:04:15,280 --> 00:04:18,470

To restore the cluster from this back up at a later point in time.



51

00:04:18,970 --> 00:04:26,230

First stop the overservice has the restore process will require you to restart the Exelis cluster and



52

00:04:26,230 --> 00:04:27,910

the server depends on it.



53

00:04:29,260 --> 00:04:36,700

Then run the controls, snapshot, restore command with the path set to the path of the backup file,



54

00:04:36,820 --> 00:04:45,160

which is the snapshot to be filed when SCADA restores from a backup, it initializes a new cluster configuration



55

00:04:45,160 --> 00:04:50,260

and configures the members of SCD as new members to a new cluster.



56

00:04:50,860 --> 00:04:57,540

This is to prevent a new member from accidentally joining an existing cluster and running this command.



57

00:04:57,550 --> 00:05:04,760

And new data directory is created in this example at location var lib city from backup.



58

00:05:05,500 --> 00:05:10,570

We then configure the etsi the configuration file to use the new data directory.



59

00:05:14,460 --> 00:05:18,090

Then reload the service demon and restart active service.



60

00:05:20,500 --> 00:05:27,400

Finally, start the Kubis overservice, your Kloster should now be back in the original state.



61

00:05:28,660 --> 00:05:34,870

A quick note before I let you go, with all the outside commands, remember to specify the cert files



62

00:05:34,870 --> 00:05:42,460

for authentication, specify the end point to the outside cluster and the senior cert, the server cert



63

00:05:42,700 --> 00:05:43,390

and the key.



64

00:05:44,760 --> 00:05:50,730

So we have seen two options, a backup using a CD and a backup by querying the server.



65

00:05:51,270 --> 00:05:53,740

Now, both of these have their pros and cons.



66

00:05:54,210 --> 00:06:02,120

Well, if you're using a managed environment, then at times you may not even have access to the outside



67

00:06:02,130 --> 00:06:02,600

cluster.



68

00:06:03,120 --> 00:06:07,680

In that case, backup by acquiring the server is probably the better way.



69

00:06:08,370 --> 00:06:10,210

Well, that's it for this demo.



70

00:06:10,440 --> 00:06:16,710

Head over to the practice test and practice backing up a CD in a cluster and then restoring from backups.