Пролезание бекапа из стораджа на уровень приложений ("поддержка горячих бекапов на уровне API...") - так себе идея, сокращающая гибкость проектирования.
У меня только на постгресе получалось при помощи libpq выгружать в таблицу данные на скорости сетевого интерфейса.
Это печальный опыт, 100% надёжного ничего нет. Один раз в Raid10 три диска потерял из 8, и не фатально, кстати - случаи бывают разные. =) Но ZFS тоже можно потерять, по мне, так даже проще, я уже пробовал...
RAID на железке можно покупать, если таких железок есть больше трех штук, чтобы в случае проблем можно было поменять.
опирование диска не только занимает более трех часов (>2 Tb) оно еще и нагружает второй диск из пары (и может его довести до выхода из строя). А под нагрузкой это чудо может обрываться и начинаться сначала - зависит от алгоритма.
бывают пожары,
реже - бывают кражи
бывают сбои высокоуровневые (не сбои ФС или RAID) когда в файлы пишется шняга, а RAID послушно повторяет эту шнягу по всем дискам.
бывают злоумышленники (или ошибающиеся) которые пишут шнягу в файлы, а RAID послушно повторяет эту шнягу по всем дискам.
в дополнение к RAID нужен еще RAID для копии.
копия должна быть в другом здании, изолированном от основного "датацентра предприятия".
как лучший вариант - в другом подразделении на другом конце города.
и, практика показывает, что мало полной копии, а нужна еще копия с историей изменений (а это очень много места).
еще практика показывает, что в нужный момент бэкап оказывается поврежденным сам. то есть бэкапа нужно 2.
а еще нужно время от времени (а лучше автоматом регулярно) проверять работоспособность и бэкапа и RAID
как вариант хранить копии резервные в специализированном хранилище бэкапов, например, Amazon Glacier и Backblaze