Group: Forum Members
I went through this designing a solution for a client. The short answer is that if you're going to back up an entire volume/partition, rather than only wanting specific folders within it, then an image backup will almost always be the better choice.
The only exception that's occurred to me because it was relevant to this client is if you have a volume/partition that has a lot of custom NTFS permissions defined throughout. In my client's case, it was an office file server, so different shared folders had different permissions, and there were even subfolders that were more or less permissive than their parent folders. In that situation, the benefit of a File & Folder backup is that the RESTORE wizard for those backups includes an option to restore any custom NTFS permissions that had been defined on the restored data. With an image backup, you'll get those back if you restore the entire partition, but if you only want to restore certain FILES from a previous backup instead of rolling back the entire partition, then the only way to do that is to mount the backup as a virtual drive to extract the desired content. There are ways to copy data back to the source in a way that carries over the custom NTFS permissions defined within the backup, but it's an extra step and a more complex process that a less experienced user would not know about or handle properly. Most users would just do a copy/paste within Windows Explorer to restore the desired data, but that will NOT carry over custom NTFS permissions defined on the source. The restored data in that case would inherit the permissions of the folder you copied the data into. This can result in the permissions being more or less permissive than they originally were, either of which could be a problem. Since this client was somewhat small and did not have full-time IT, I wanted to design a solution that they would be able to manage if something ever happened to me. I even wrote documentation for how to do these sorts of restores. And I decided that trying to explain to an average user how to perform a custom copy operation to carry over NTFS permissions just wasn't feasible. So instead I used File & Folder backups so that the user could just restore data that way and check that "Restore custom NTFS permissions" box.
I suppose another case where F&F would be useful would be if you were backing up a partition that Reflect didn't support backing up as an image, such as an exFAT partition or data residing on a network location. But in that case you of course don't have a choice.
But apart from that, if you're backing up an entire partition, you will likely find that an image backup runs MUCH more quickly than an F&F backup of the same data. In my client's case, an image backup is about 2.5x faster. The reason is that an F&F backup is a file-level operation, which means it incurs per-file overhead. This file server has about 500,000 files with a relatively small average size, so that's a lot of overhead. An image backup is a block-level operation and therefore doesn't have that sort of overhead. And while I haven't had an occasion to test this yet, I would expect that an image restore would similarly run much faster than a full F&F restore too. And lastly, as of this writing, while it is possible to mount an F&F backup as a virtual drive, any files within the backup that are larger than 4GB get split up into 4GB chunks and therefore will not restore properly if you simply copy/paste the chunks out of a mounted backup. This is because F&F backups don't have an inherent file system and therefore Reflect has to emulate a file system to mount the backup as a virtual drive. Currently Reflect emulates a FAT32 file system, which has a 4GB file size limit. So in order to restore larger files properly, you need to use the actual restore wizard. Image backups do not have this limitation because image backups do contain their own full file system as part of the image backup.