TsyklopНо все же.
Если оперировать терминами RPO и RTO, то при хранении файлов на ФС можно выжать лучшие показатели при меньших расходах. Bottom line такой: когда надо записать файл, генерируем для него айдишник (long например), каждый октет, кроме последнего, определяет каталог ФС, последний - имя файла, в итоге все пути получаются уникальные и в каждом каталоге не особо много файлов получается (до 256), записываем файл на ФС, записываем информацию о файле в базу, коммитим транзакцию. Нужно обновить файл? Создаем новый, а не обновляем старый! То что при таком подходе ФС может уходить вперед от БД (при откатах или восстановлениях БД) - ничего страшного в этом нет, к потеряшкам все равно никто обращаться не будет (нет записей в БД) - делаем фоновое задание, которое будет удалять потеряшки и все. Нужно время бэкапа уменьшить? Ок, создаем несколько каталогов для хранения файлов, для каждого отдельный пул идентификаторов в базе, один из них помечаем активным - куда будет идти запись новых файлов, как только переключились с одного каталога на другой переключаем старый в RO, делаем ему последний бэкап и перестаем бекапить вообще. Нужно что-то еще более продвинутое? Впихиваем гибридную ФС, которая сама будет старье куда-нибудь на ленту сливать, а то к чему недавно обращались держать на ФС, либо колхозим временное хранение в BLOB/BFILE и слитие в ФС.