SQL Server Backup and Restore - Simple Talk

Chapter 1: Basics of Backup and Restore
In short, when operating in FULL recovery model, you must be taking transaction log
backups to manage the growth of data in the transaction log; a full database backup does
not cause the log file to be truncated. Once you take a transaction log backup, space in
inactive VLFs will be made available for new transactions (except in rare cases where you
specify a copy-only log backup, or use the NO_TRUNCATE option, which will not truncate
the log).
Bulk Logged
The third, and least-frequently used, recovery model is BULK_LOGGED. It operates in a
very similar manner to FULL model, except in the extent to which bulk operations are
logged, and the implications this can have for point-in-time restores. All standard
operations (INSERT, UPDATE, DELETE, and so on) are fully logged, just as they would
be in the FULL recovery model, but many bulk operations, such as the following, will be
minimally logged:
• bulk imports using the BCP utility
• BULK INSERT
• INSERT … SELECT * FROM OPENROWSET(bulk…)
• SELECT INTO
• inserting or appending data using WRITETEXT or UPDATETEXT
• index rebuilds (ALTER INDEX REBUILD).
In FULL recovery model, every change is fully logged. For example, if we were to use
the BULK INSERT command to load several million records into a database operating in
FULL recovery model, each of the INSERTs would be individually and fully logged. This
puts a tremendous overhead onto the log file, using CPU and disk I/O to write each of
the transaction records into the log file, and would also cause the log file to grow at a
tremendous rate, slowing down the bulk load operation and possibly causing disk usage
issues that could halt your entire operation.
44