Few things about backup

If you are using sql 2008 then you can split backup into different file.

BACKUP DATABASE [Northwind] TO

DISK = 'D:\Northwind_file1.bak',

DISK = 'D:\Northwind_file2.bak',

DISK = 'D:\Northwind_file3.bak',

DISK = 'E:\Northwind_file4.bak'

WITH INIT , NOUNLOAD , NAME = 'Northwind backup', NOSKIP , STATS = 10, NOFORMAT

TRUNCATE_ONLY

               If you get a "stuck" transaction, and your log grows continually and you're unable to shrink, TRUNCATE_ONLY comes in very handy. But, if you get a “stuck” transaction and the log grows, truncate only isn't going to truncate the active portion of log space held open by the stuck transaction.  You would have to commit/rollback/kill the transaction to allow that space to truncate out.  At that point, a log backup would clear the space allowing it to be reused. 

               Forcing someone to switch to SIMPLE recovery to truncate the log contents pretty much guarantees that they know they are breaking their ability to perform a point in time recovery, since that is not possible with SIMPLE recovery. BACKUP LOG WITH TRUNCATE_ONLY is a dangerous command: it empties out the contents of your SQL Server’s transaction log without really backing it up.  Database administrators sometimes run this command right before shrinking their log file with a DBCC SHRINKFILE command, thereby freeing up drive space.

               Microsoft recommends that instead of truncating logs, you switch to simple recovery mode instead.  That way you don’t generate logs you won’t be using, and you won’t incur performance impacts from repeatedly filling and truncating the logs.  You also remove the need to regularly back up the transaction log.

Internal process while taking backup

1.       Checkpoint – to make sure that pages on disk are up to date with current changes

2.       Mark the log – backup began here

3.       Read from data files – writes pages directly from disk – even though they might be changing WHILE the backup is occurring therefore backup is considered an inconsistent set of pages (NOT a problem – the log will know the transactional consistency)

4.       Mark the log – backup ended here

5.       Copy the transaction log – backup includes transaction log to make consistent. No point making the data

          Misconception about full backups is that they only contain data. Both full backups and differential backups also contain some transaction log records so that the restored component (database, file, or filegroup) can be made transactionally consistent. Consider an example transaction that inserts a record into a table with a single nonclustered index. The transaction is split into two parts internally: a record insertion into a data page in the table and then the insertion of the required record in an index page in the nonclustered index. If the backup process just happens to read the nonclustered index page before the record insertion, but reads the table data page after the record insertion, then the database represented by just the data in the backup is transactionally inconsistent.

              

            The data contained in a full backup is not necessarily all of the contents of all data files. The backup will only contain the allocated pages from the data files. For example, a single-file database may be 100GB but only contain 15GB of allocated data. In that case, the full backup will only contain the 15GB of allocated data plus the necessary transaction log.