Keeping (Partial) Backups Small when using SQL Server FILESTREAM

The problem this caused was that the log file (which also gets backed up) is now unnecessarily large because it includes the FILESTREAM data.

I'm not sure if you mean the log file itself is too large or that the log file backups become too large.

If it's the former then how often were you backing the log up? Depending on the application design you may be able to reduce the size by backing up more frequently (and every 5 minutes is not too frequently). However if you were already doing that and it was still ballooning then you're probably out of luck. Why is the large log file a problem again?

If it's the latter - it sounded like you were happy to continue with simple recovery model and no point in time restores if it let you have smaller backups; in which case stay in full mode and discard your log backups.

A solution for a database set to recovery mode SIMPLE is having the FILESTREAM data in a read-only file group (which isn't your ideal option), and then backing up only the read/write file groups with DIFFERENTIAL like this:

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

It will get any data that has changed in any read/write filegroups. That's the easiest, out of the box, that you can keep partial backups manageable without getting the FILESTREAM data. It would however require that the load process for the aforementioned data would need to modify the filegroup to be read/write, load any additional data, and then set to read only again. Certainly not ideal.

I feel dirty providing this as an option, but if you choose to segregate the FILESTREAM data into its own database, you could maintain RI between the tables in the separate dbs by way of triggers:

Triggers -> Remarks -> Limitations:
A trigger is created only in the current database; however, a trigger can reference objects outside the current database.

Expect performance issues and a section of your scalp to become hairless after pulling out tufts of your head fur in frustration, but theoretically you could do this. I don't recommend this approach on any level, instead I strongly suggest you increase the frequency of your tlog backups and/or switch to the bulk-logged recovery model and see how much space that saves you, BUT this is a possible solution. Really you'd need to weigh the benefit of separating out this data and dealing with a Frankensteinian database design, but it's an option.

...I have to go take a shower now...