Сколько у вас систем и как часто они модифицируются?Если системы НЕ находится в разработке, то достаточно половинки тетрадного листка: "мой бокс фром скрэтч" всунутого в корпус.
Главное, чтобы листок не сгорел при землетрясении, после чего эту систему можно просто накатить с нуля по алгоритму: ставим ось, ставим AMP и т.д. ...
После чего заливаем полтора DVD данных. Операция бекапа здесь - принципиально излишня.
Функции поддержания целостности данных сиполняют багор и ящик с песком в конце коридора, поскольку система и требовани к ней есть заключены в "минимал инсталл", а данные - в бекофисах и могут быть вновь залиты на любую систему за часы или минуты.
А вот когда на системе работает полсотни чувствительных к простоям сервисов, находящихся в разработке - скрипты с "в кучу одни и те же фалы, дублируя их сотни раз" - то без чего жить нельзя. Прощелкал пару апострофов - и ищи-свищи. Или откатись из "в кучу одни и те же фалы, дублируя их сотни раз". А вот поверх всего этого - бакула.
Суешь нос в исходники - прежде чем открыть файл для изменений - "в кучу одни и те же фалы, дублируя их сотни раз" для своей директории.
Развертывать полсотни CVS'ов ? Дольше настраивать, чем писать само приложение, исходники которого будут сидеть в CVS'е.
#!/bin/sh
.....
OUTF="XXXXXXXXX_$(date +%Y)-$(date +%h)-$(date +%d)_$(date +%H)-$(date +%M).tgz"
tar -c -Z -f $TGTD$OUTF $SRCD
echo "мама, я живой!"
И утоптать сверху бакулкой. Все эти сотни микроснэпов.
Объемы же резервного копирования по любэ ВСЕГДА будут в СОТНИ и ТЫСЯЧИ раз превышать объемы сохряняемых данных. И до тех пор, пока вы этого не поняли - вы в страшной опасности, если ваши сервисы чувствителны к простоям. Теряйте хотя бы сотку ЛИЧНЫХ баксов в час и вы зацените концепт пяти девяток.
