Understanding recovery point objective and recovery time objective
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~RPO~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The first one is the recovery point objective, or RPO, and this is the point in time that data can be restored to, so if your most recent backup is a month ago, you are only going to be able to restore to what the database looked like at that time the backup was taken, so you will potentially lose a month of data.
On the other hand, if your most recent backup was taken five minutes ago, then you can restore up to that point in time and you would only lose five minutes of data.
So you need to ask yourself how much data are you willing to lose, are you willing to lose hours of data, minutes of data, seconds of data, or zero data? If you are unwilling to lose any data, if you absolutely positively have to have zero data loss, then backups alone are not going to solve your problem.
You would need to look into high availability solutions, like clustering, or availability groups. These solutions can get very expensive very quickly, on the other hand, backups are very inexpensive to run, so because of our budget constraints, sometimes we have to live with the fact that we will lose a few minutes of data.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~RTO~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We also need to think about a recovery time objective, RTO, which is the amount of time taken to do the restore.
A very large database can take several hours or maybe a day to restore, and in some cases this would not be acceptable. Typically, running a restore takes slightly longer than running a backup, so if we do a full backup and that takes 20 minutes to run, when you go to restore that full backup you can expect it to take longer than 20 minutes, but we can't say exactly how long it'll be without testing.
Everyone's hardware is different, everyone's bandwidth is different, so if you want an exact number of how long it's going to take to do a restore on your system, you'll need to run some tests.
You also need to think about the time to prepare for a restore. So when a disaster happens, you're going to need to take some time to locate the tapes, or locate the files, login to SQL server and kick off the restore process.
Most of those things shouldn't take too long, but some things to be concerned about if you're storing all of your backup tapes off site, then you'll need to call for those tapes, and the tape would have to be returned to your site.
That could take some amount of time. If you're doing a single restore, then you're fine to use the graphical interface.
If you're going to need to restore multiple backups, then it might be easier to do that with a script. So you have to think how long is it gonna take you to write the script.
Some of it you could write ahead of time, and if you're doing some testing on a regular basis, you would probably have the basics of a restore script. So again, these are some things to think about
Who decides RPO & RTO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The recovery point objective and recovery time objective, ideally, a DBA wouldn't be deciding these things on their own.
You should meet with the head of the IT Department and help you determine what these objectives should be, and also make sure the objectives are clearly communicated throughout the organization, so when a disaster does happen, everyone knows what to expect, they have some expectation of how long it's going to take to do the recovery, and how much data might potentially be lost.
Kerberos VS NTLM
--------------------
NTLM Authentication: Challenge- Response mechanism.
In the NTLM protocol, the client sends the user name to the server; the server generates and sends a challenge to the client; the client encrypts that challenge using the user’s password; and the client sends a response to the server.If it is a local user account, server validate user's response by looking into the Security Account Manager; if domain user account, server forward the response to domain controller for validating and retrive group policy of the user account, then construct an access token and establish a session for the use.
Kerberos authentication: Trust-Third-Party Scheme.
Kerberos authentication provides a mechanism for mutual authentication between a client and a server on an open network.
The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user and the server with the desired service to access. The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). When the client user log on to the network, it request a Ticket Grant Ticket(TGT) from the AS in the user's domain; then when client want to access the network resources, it presents the TGT, an authenticator and Server Principal Name(SPN) of the target server, contact the TGS in the service account domain to retrive a session ticket for future communication w/ the network service, once the target server validate the authenticator, it create an access token for the client user.