velmar1. При каких параметрах сервера 19 часов полного бекапа - это большое приложение, а при каких - это дохлый сервер Хотя я бы говорил не о приложениях а об объеме данных.
Действительно, как уже было сказано выше, все сильно зависит от размеров БД, а так же от того как этат бекап делается. При больших размерах БД в несколько терабайт, нужно разумеется и достаточно быстрое хранилище. Но это еще не все. К примеру, при таких размерах, имеет смысл найти и выделить данные которые не меняются на протяжении долгого времени, такие данные можно выделить в отдельную БД и закрыть на запись, и теперь эту БД не требуется бекапить периодически, так как актуальность последнего не теряется. А новые бекапы будут для меньшего объема и выполнятся быстрее. Далее, в нашей практике на версии 2012.2 столкнулись с ошибками работы встроенного бекапа, если выполнять его по сети, у нас было подключено быстрое хранилище на другом сервере и соединение между машинами было достаточно быстрое, но скорость бекапа всего для пары терабайт занимала непозволительно много времени и не успевало выполнится за ночь, и скорость явно была сильно ниже пропускной способности всех элементов.

velmar2. Какие есть аргументы в пользу внешнего бекапа?Если открыть документацию то там можно увидеть такие строки в самом начале.
External backup is currently the recommended best practice for backing up Caché. Т.е. Внешний бекап, на данный момент рекомендуемая лучшая практика для бекапов.

Ptnvelmar3. Каким образом внешний бекап может гарантировать целостность данных датасета без остановки записи в базу?
Внешний бэкап подразумевает остановку cacheНе обязательно, есть снапшоты, которые могут выполнятся на рабочей системе, и есть бекапы с заморозкой записи в БД.

Ptnservit, & DAiMor

Хорошо про это не подумал.

Но с по хорошему то что запрет записи что отмонтирование базы, с точки зрения работы в области по сути "выключение" приложения, на мягко говоря неопределенный срок.Опять не верно, замораживание записи не равно замораживание приложения. Да это может произойти если буфер демона записи закончится и он не будет еще разморожен. Но при небольшой БД, и в период наименьшей загруженности можно успеть сделать бекап.

velmar,

Самое простое, зеркало и бекап с него
Зеркало, будет копировать 24/7 данные на другой сервер, что само по себе уже резервирование, и сервер может встать в строй автоматом сразу как упадет основной сервер
ну и бекапы можно делать любым способом, потому что для этого сервера уже не критична круглосуточная работа

kalin,

Вы бы для тех кто не совсем понял ваш код написали, что ваш бекап это просто экспорт указанных глобалов в некий файл, и его архивация. и все это на линуксе.
для тех кто хочет такой путь можно делать наверно не экспорт а копирование глобалов в другую БД, и восстановление быстрее будет.

kalinКак правило, нет необходимости каждый день хранить всю базу с программами и данными.Как правило соотношение программ к данным, такое что, объем программ не существеннен по сравнению с объемом данных. Даже у нас БД с кодом который мы поставляем около 450МБ, обычно объемы данных у нас начинаются с 100ГБ, для проектов которые уже какое то время работают, а так от 20ГБ.

AlexShiryaev,

А какая версия Cache ?
На самом деле у нас были похожие проблемы при бекапе на сетевой диск скорорость была низкая, точно не скажу причин, но вроде как решение было внутри ядра Cache.

AlexShiryaevПрошу прощения, забыл указать версию:
Cache for Windows (x86-64) 2010.2.7 (Build 1004_0_11142U) Wed Dec 21 2011 15:29:56 ESTКак то уж совсем старенькая версия, может стоит попробовать да хотя бы оценить скорость на последней релизной версии 2015.2