Backup Types

SQL Server Full Backups 

The most common types of SQL Server backups are complete or full backups, also known as database backups.  These backups create a complete backup of your database as well as part of the transaction log, so the database can be recovered. This allows for the simplest form of database restoration, since all of the contents are contained in one backup.

BACKUP DATABASE AdventureWorks TO DISK = 'C:\AdventureWorks.BAK'

SQL Server Transaction Log Backups 

If your database is set to the "Full" or "Bulk-logged" recovery model then you will be able to issue "Transaction Log" backups. By having transaction log backups along with full backups you have the ability to do a point in time restore, so if someone accidently deletes all data in a database you can recover the database to the point in time right before the delete occurred.  The only caveat to this is if your database is set to the "Bulk-logged" recovery model and a bulk operation was issued, you will need to restore the entire transaction log.

               A transaction log backup allows you to back up the active part of the transaction log.  So after you issue a "Full" or "Differential" backup the transaction log backup will have any transactions that were created after those other backups completed.  After the transaction log backup is issued, the space within the transaction log can be reused for other processes.  If a transaction log backup is not taken, the transaction log will continue to grow.

BACKUP LOG AdventureWorks TO DISK = 'C:\AdventureWorks.TRN'

SQL Server Differential Backups 

The way differential backups work is that they will back up all extents that have changed since the last full backup.  An extent is made up of eight 8KB pages, so an extent is 64KB of data.  Each time any data has been changed a flag is turned on to let SQL Server know that if a "Differential" backup is created it should include the data from this extent.  When a "Full" backup is taken these flags are turned off.

So if you do a full backup and then do a differential backup, the differential backup will contain only the extents that have changed.  If you wait some time and do another differential backup, this new differential backup will contain all extents that have changed since the last full backup.  Each time you create a new differential backup it will contain every extent changed since the last full backup.  When you go to restore your database, to get to the most current time you only need to restore the full backup and the most recent differential backup.  All of the other differential backups can be ignored.

Differential backups can really speed up restore operations by allowing many transaction log backups to be skipped in the restore process. It's much faster to essentially jump forward in time using a differential backup than to have to replay a lot of transaction log records to get to the same point in time.

BACKUP DATABASE AdventureWorks TO DISK = 'C:\AdventureWorks.DIF' WITH DIFFERENTIAL

SQL Server File Backups 

Another option for backing up your databases is to use "File" backups.  This allows you to backup each file independently instead of having to back up the entire database.  This is only relevant when you have created multiple data files for your database.  One reason for this type of backup is if you have very large files and need to back them up individually.  For the most part you probably only have one data file, so this is option is not relevant.

BACKUP DATABASE TestBackup FILE = 'TestBackup' TO DISK = 'C:\TestBackup_TestBackup.FIL'

SQL Server Filegroup Backups 

In addition to doing "File" backups you can also do "Filegroup" backups which allows you to back up all files that are in a particular Filegroup.  The one advantage of using Filegroup backups over file backups is that you can create a Read-Only Filegroup which means the data will not change.  So instead of backing up the entire database all of the time you can just backup the Read-Write file groups.

BACKUP DATABASE TestBackup FILEGROUP = 'ReadOnly' TO DISK = 'C:\TestBackup_ReadOnly.FLG'

With options

With init option, existing backup set will be overwritten, otherwise new backup will be added to the existing.

NOSKIP

Instructs the BACKUP statement to check the expiration date of all backup sets on the media before allowing them to be overwritten. This is the default behavior.

NOFORMAT

Specifies that the backup operation preserves the existing media header and backup sets on the media volumes used for this backup operation. This is the default behavior.

FORMAT

Specifies that a new media set be created. FORMAT causes the backup operation to write a new media header on all media volumes used for the backup operation. The existing contents of the volume become invalid, because any existing media header and backup sets are overwritten.

You need to use the BACKUP command with the CHECKSUM option to make sure page checksums are checked. This option is extremely useful, because it notifies you when your backup has corruption in it. Furthermore, if a page corruption is found, the backup will fail (again by default) with a message 

After running your backups it is a good idea to use the RESTORE VERIFYONLY option to ensure that the backup that was just created is readable.  This doesn't necessarily mean the restore will work without issue, but it does give you another level of comfort that SQL Server can at least read the backup file.