 Now, what the users see about your website, there is a lot of things which are underneath it, which they are not aware of. And what are those things which you are aware of, you are managing, is that how your website is distributed, and what servers it reside, are those servers physically at the same place or they are different place, and how the linkage is there, how the static pages are being worked with, how their dynamic pages are being processed, how the mirroring is done, what is happening in the product. So there are many, many things, which of course, you have to take care of because it is your web application. So in this module, I will be covering all those things. So let's look at the module coverage. So there are different environments we are talking about over here. This we are talking about the production environment. We are about talking about the mirror, about the backup, about the test environments. And of course, the environments and the archives, and why all of this matters? Why? That is the question you should always be asking yourself, that why this, and then trying to get the answers to those why's. That is the way to learn. So production server and the environment, web server, you don't have any control of which in which directory you are going to place your material. Okay, your ISP of course will provide you a directory. And of course, you can create directory structure within that directory, but beyond that you don't have any control to web server directory contents are important that way you place them. And you have to backup, backing up your web server files. Now it is your responsibility because you are the admin, you are the administrator. It is your responsibility to take a backup of all your files. Now this is the mirror copy of the production environment mirror copy is that you have your, your data, you have your application. Okay, that is replicated across other servers also. And there are many advantages and which will be covered also of mirroring your website. Most of all is fault tolerance. And then this performance is also there. So it is your responsibility to take a backup and mirror your website. And multiple mirror environments are cheaper. They are cheaper. Why because it because instead of getting one powerful server or one which is going to be very expensive, it is much cheaper and economical to have multiple servers which are cheap and using their performance that that is the benefit of multiple mirrors. Multiplicity increases redundancy also because when you are you have mirroring your website across multiple servers across the end servers. So if if one server fails, you have n minus one servers working n minus one are working. But if there is only one server, if that fails, then everything is gone. So this is what you call as graceful degradation. So that is the benefit of mirroring your website. Then is the production backup complete copy of a website on a separate computer separate means that you are you make a complete copy of the backup. Whatever is on your main server, you make a copy and that copy is not on that server. That copy is on a separate server or on a separate computer. So that if there is a problem with the main server, you have a you have a backup and you can restore from your that backup. And you this is your backup. This is your responsibility. Don't don't ask and don't expect the ISP or the database service provided to take a backup. You this is your web application. You take the backup and you are responsible for it. And the thing is that keep the two sides identical. Whatever is at the so-called master website that should be copied or backup on a computer and they should be identical. The file names, the hierarchy, the structure, everything should be identical. And if for some reason there are certain files which are which which are not matching or which have been created, but that have not been duplicated. It is prudent. It is better to delete those files and they should be identical, not similar identical. Test on backup move to production. Now your your backup is the copy of your actual system. It is actual system. Now if you have to make any changes, you don't make those changes at the production. You make the changes in the backup. Okay. And as a matter of fact, you don't make the changes in the backup. You load the changes in the backup and run them there. And when they're okay, then you load into your production. Test environments to for experiments, few files, text environment is not a backup. There are only few files over there and you are experimenting those files and no modifications, no modifications in the production, no modifications. Even no motivations in in the backup. You do the experiments in the in the experiment environment. And then you load them into the production and you test them over there. Because remember in the test environment, you don't have all the files. Okay. And if there are multiple servers in the production environment, your test environment should also have multiple servers. And and you know something. The thing is that if you are trying to cut corners to making shortcuts and you had multiple servers in your production, but in the test environment, you don't have multiple servers and you make the name changes rest assured. The things will work perfectly in your scaled on test environment, but they are not going to work. They will fail in your production environment. Remember that. And finally is the this is this development environment. Freedom to develop the ideas. You can develop your ideas over there. You can test them. You can experiment them and you can you can you can develop your ideas and change them make experiments. Okay. But you are not allowed to do this in the production environment or the test environment. Okay. And take a regular backup of mirror of the changes. Whatever changes are there, you should make a take a backup of those changes so that you have their record of the changes. Why it matters standard way to control large systems. If you are new to such an environment and not accustomed to it, get used to it. If you think it's a lot of work after a while, you will see the benefits of this and you will be following this cutting corners can lead to disaster. People might not you you or maybe you are not very convinced, but the same goes for the backup. When the system crashes, then the people remember then the people somebody told them something good advice. So you should have these different types of environments in which this thing your application is being developed and your website is a very public area. Keep it clean. You would not like your boss to ask you why this mess up in your public website. And of course, web database applications cost quickly. The cost quickly add up. Okay. Because now because it's a complex problem. You have your web database application. You have your web server. You have your application server. You have your database server. You need a licenses. You need patches. You need upgrades. You need servers hardware to the cost add up quickly. So look at what you need and what you can afford. That is the message. Thank you for your time.