BackUp of SQL Server

Hello everyone, I haven't written anything for a long time. Recently, I 've been playing Starship in Haofang. Even if I don't even recognize it, I still have a bright future when I come back to develop a database, at least I can barely find that confidence here !!!
Doing backups is just like buying insurance. You can do this without having to worry about it every day. You can also do it to make the system run normally and have tenacious regeneration capabilities, at the same time, everyone will ignore your existence and always make a mess, and then you will play the savior again, so that everyone will know that your existence is valuable, your salary should be XXX, so I personally feel that it is not very nice to back up data !!!
The backup mechanism of microsoft SQL server is much more powerful than that of SYBASE. First, sybase does not support partial restoration of the database. This is achieved by backing up SQL SERVER files and file groups, sybase is a little powerless to delete error records because load tran does not support specified time points or named transactions, and sybase does not have a recovery model, in this way, the determination of recovery mechanisms between different enterprises does not have an intuitive scale. I will explain the advantages of SQL SERVER one by one in the following text (maybe the next article)
Recovery model:
SQL SERVER has three recovery models: Simple recovery, full recovery, and large-capacity log recovery. Each model has its own characteristics and is applicable to different enterprise backup requirements. Models can be switched to each other, this is also a relatively prone issue.
Simple recovery:
Like its name, this recovery model is the simplest. It only supports full backup and differential backup of the database, and also provides good support for saving the log file space, because logs are automatically truncated at the checkpoint, log files will not grow. However, when a large transaction is committed, the Risk Index is also high due to limited backup capabilities, if the database is damaged, it can only be restored to the last full backup or the last differential backup. There is no way to handle subsequent transactions. To be precise, non-active transaction logs should be deleted.
     
Large-capacity log recovery:
This model is similar to the full recovery mentioned later, but there are still many differences. It supports database integrity, differences, and log Backup. For example, select into, bulk insert, BCP and other large-capacity log operations provide performance optimization. In full recovery mode, logs record the specific details of the above operations, in this mode, only such a thing is recorded in the log, and the specific details are ignored. This greatly improves the storage speed and saves the log space, because the log record contains the minimum log changes that ignore details, the large-capacity recovery model does not support restoration at specific time points, that is, the stopat clause cannot be specified in the restore log, the following is the operation and error information.
/* Large-capacity log recovery model
Restore database chj733 from disk = 'E: chj733_dat.bck 'with norecovery