SQL Server Backup and Restore - Simple Talk

Why Partial Backups?
Chapter 10: Partial Backup and Restore
Partial backups allow us to back up, on a regular schedule, only the read-write objects
and data in our databases. Any data and objects stored in read-only filegroups will not,
by default, be captured in a partial backup. From what we've discussed in Chapter 9, it
should be clear that we can achieve the same effect by capturing separate file backups of
each of the read-write filegroups. However, suppose we have a database that does not
require support for point-in-time restores; transaction log backups are required when
performing file-based backups, regardless, so this can represent an unnecessarily complex
backup and restore process.
With partial backups, we only need to take transaction log backups if they are needed
for point-in-time recovery, and so they are ideal for use with SIMPLE recovery model
databases, as a means to trim database backups down to a more manageable size, without
introducing the added administrative overhead of log backups. Note that partial backups
are valid for databases operating in any recovery model; it's just that they were specifically
designed to simplify back up for very large, SIMPLE recovery model databases that
contain a large portion of read-only data.
So, in what situations might we want to adopt partial backups on a database in our
infrastructure? Let's say we have a SQL Server-backed application for a community
center and its public classes. The database holds student information, class information,
grades, payment data and other data about the courses. At the end of each quarter,
one set of courses completes, and a new set begins. Once all of the information for a
current quarter's courses is entered into the system, the data is only lightly manipulated
throughout the course lifetime. The instructor may update grades and attendance a few
times per week, but the database is not highly active during the day. Once the current set
of courses completes, at quarter's end, the information is archived, and kept for historical
and auditing purposes, but will not be subject to any further changes.
This sort of database is a good candidate for partial backups. The "live" course data will
be stored in a read-write filegroup. Every three months, this data can be appended to a
349