Granular vs Full Restore
Granular Restore: Recovering One Item at a Time
A granular restore is the recovery of a single item from a backup, such as one file, one database, one mailbox or one email, without restoring everything else the backup holds. It is the opposite of a full restore, which brings back an entire website, account or server in one operation.
The distinction matters because most data loss is small. A customer deletes one product page, a plugin update overwrites a single configuration file, or a contact form stops saving entries to one database table. In these cases, rolling back the whole site would also undo every correct change made since the backup, including new orders, comments and pages.
Granular restore lets you pick out the affected item and return only that to its earlier state. Backup tools that support it index the contents of each backup, so individual items can be found and extracted without touching the rest.
When a Full Restore Is the Right Choice
A full restore is the better option when the damage is widespread. If a disk failure destroys a server, or a ransomware attack has encrypted most of the files, trying to repair items one by one takes longer and risks missing something.
Full restores also rebuild the environment as well as the data. A complete server image includes the operating system, installed software and settings, which a file-by-file approach may not capture. When a disaster takes a whole machine offline, that completeness is what gets the site back online.
The trade-off is that a full restore resets everything in its scope to the moment the backup was taken. Changes made after that point are lost unless they are recovered from another source, which is why the frequency of backups matters as much as the restore method.
A Small Shop Needs Both Kinds of Restore
A small online shop finds on Monday that its order confirmation emails have stopped sending. The cause is one email template file, edited by mistake on Sunday evening. A granular restore of that single file fixes the problem in minutes and leaves Sunday's orders, new products and customer accounts untouched.
Two days later, a failed storage array takes the whole site offline. Here a full restore is the right tool. The owner restores the site from the most recent backup, then checks the orders placed since that backup against the payment provider's records.
Why Restore Options Matter When Choosing a Backup Solution
Not every backup product offers the same level of detail. Some can only restore a complete account or server. Others can restore individual files, a single database, a mailbox or one message. When you compare solutions, check which items can be restored separately, because the option you need on a bad day may be the granular one.
Consider the data your site depends on. A content site may mostly need file-level recovery. A site that stores orders, memberships or bookings in a database needs database-level recovery as well, which is covered in what a complete backup should include. If email is hosted with the website, confirm whether individual mailboxes or messages can be recovered.
Granular restore also depends on how the backup was made. A backup stored as one opaque archive may not allow item-level recovery until the whole archive is restored to a separate location. Testing item-level restores before you need them is the only reliable way to know, as explained in why backup testing matters.
Frequently asked questions
Can I restore a single file from a full backup?
Yes, if the backup tool supports granular restore. Many modern tools can browse the contents of a full backup and extract one file, folder or database without restoring the rest. If the backup is a single archive with no index, you may need to restore the archive to a separate location first and copy out the file you need.
Can a single database be restored without restoring the whole site?
In many setups, yes. Database backups are often stored apart from site files, so one database can be restored on its own. Files and database should still match. Restoring an older database beside newer files can cause errors, so use components from the same restore point where possible.