Think for a moment: what's the main purpose of taking backups?
Yes, you need them to be able to recover as fast as possible in case of some unfortunate event.
That's why you should use the KISS principle when planning your backups. Make the backups sophisticated (so you can restore from some specific date/version), but not TOO sophisticated. Use some alreadily available backup software. Storing binary blobs in MySQL doesn't sound like a fool-proof solution for me. I would store files as files and databases as databases.
I realize that this time you are planning to transfer the data from the ISP to your home, but imagine if the MySQL server is located in the same datacenter than the servers you'd like to backup and the datacenter goes down due an electricity blackout. A Very Important Server gets electrocuted due the blackout and does not boot due a hard drive failure. Your MySQL server boots up, but has some table corruption which needs to be fixed, IF it can be fixed. That would make the recovery part much slower and much more hassle than it should be.
Also, a big part of taking backups is not actually the backup phase, it's regularly TESTING them. It's way easier to see if your latest image backup is correctly done if you can just open up your file manager and browse the pictures, instead of performing some MySQL SELECT's (or use some application that fetches the blobs from the DB).
But databases are not completely useless when it comes to backups. A backup software can use it for all kinds of metadata; backup date, backup set, backup duration, file version, file checksum and so on. That kind of data is easy to store and quick to fetch from a DB. A binary blob, not so much.