Прежде всего, взгляните на это: Хранение миллионных изображений в файловой системе . Хотя речь идет не о резервных копиях, но стоит обсудить эту тему под рукой.
И да, большое количество маленьких файлов надоедливо; Они занимают inode, требуют места для имен файлов & c. (И для резервного копирования всех этих метаданных требуется время). По сути это звучит так, как будто вы разобрались с сервировкой файлов; если вы запустите его на nginx с varnish впереди или около того, вы вряд ли сможете сделать это быстрее. Добавление базы данных под этим только усложнит ситуацию; также когда дело доходит до резервного копирования. Увы, я бы предложил больше работать над стратегией резервного копирования FS на месте.
Прежде всего, вы пробовали rsync с -az -ключами (архив и сжатие, соответственно)? Они, как правило, очень эффективны, поскольку не передают одни и те же файлы снова и снова.
С другой стороны, я бы предложил использовать tar + gz для нескольких файлов. В псевдокоде (и при условии, что вы получили их в разных подпапках):
foreach prefix (`ls -1`):
tar -c $prefix | gzip -c -9 | ssh -z destination.example.tld "cat > backup_`date --iso`_$prefix.tar.gz"
end
Это создаст ряд .tar.gz-файлов, которые легко переносятся без особых накладных расходов.