Попробую дополнить ответ Дмитрия.

AlexKB1. До какого значения можно увеличивать таймаут, чтобы у Каше крыша все-таки не поехала, или же он просто проигнорирует мое значение, а подставит свое максимальное или свое по умолчанию?Можно выставить любое значение, контроля нет. Обрати внимание, что там два таймаута, и (для некластерных систем) надо использовать ExternalFreezeTimeOut. В нормальных условиях WRTDMN активируется по истечении 80с или по заполнении 25000 буферов, что наступит раньше. Если же WRTDMN (демон записи) заморожен, заполнение кэша будет продолжаться. См. статистику работы вашей системы (mgstat), насколько интенсивно она пишет в БД, и прикинь, как быстро заполнятся 75% кэша (надо ведь и для чтения что-то оставить) в худших условиях в то время суток, когда выполняется бэкап.

AlexKB3. Как лучше всего выводить из ступора Каше, если метод ExternalThaw() выполнится с ошибкой, бывало ли у кого такое? (перезапуск - понятно)
Только перезапуск, но вероятность ошибки здесь мала; не видел такого.

P.S. ИМХО, попытка использовать заморозку на время внешнего бэкапа, если он идёт десятки минут, добавляет проблем, которых в принципе нет, если использовать он-лайн бэкап Cache, обычно выполняющийся ненамного медленнее внешнего бэкапа. Кстати, придумана была технология заморозки прежде всего для заморозки записи в БД на время создания snapshot'а (о чём недвусмысленно "намёкнуто" в документации), причём подразумевался snapshot на уровне СХД, хотя есть и другие варианты. Создание shapshot'a - быстрая операция, обычно занимает несколько секунд, поэтому 10 минут выбраны с большим запасом.

В нормальных условиях WRTDMN активируется по истечении 80с или по заполнении 25000 буферов, что наступит раньше.Поэтому представление, что изменённые данные где-то "накапливаются", неверно. Я не видел более 24000 "грязных" буферов даже на очень загруженных системах, с тысячами пользователей.

Проблемы видятся как минимум две: при внезапном ("внеплановом") всплеске активности во время бэкапа может не хватить:
1- заданного таймаута
или
2- буферов в кэше.

Простой пример: допустим, система пишет 20000 буферов 1 раз в 80 секунд. Сколько потребуется кэша, чтобы удержать их в памяти в течение 30 минут?
20000/80*(30*60)*8/1024 ~ 3.4GB

Если размер кэша глобалов хотя бы 6GB, пережить заморозку скорее всего удастся.

Но допустим БД вдвое выросла, и нам требуется уже 60 минут, а администратор забыл увеличить таймаут? Имеем проблему №1: WRTDMN оттает раньше, чем завершится бэкап, и он у нас будет "грязным".
Если же админ увеличил таймаут до 3600 сек, но забыл увеличить кэш, имеем проблему №2: система просто зависнет.

Ни одной из этих проблем не просматривается при он-лайн бэкапе Cache. За что ты его так не любишь? :)

Если есть нежурналируемые БД (отличные от CACHETEMP), данные в которых тем не менее нельзя терять при перезапуске Cache, добавляется проблема №3: если во время заморозки произойдёт "лёгкий" сбой в работе Cache, в результате которого её придётся перезапустить, то все изменения, проделанные в нежурналируемых БД во время заморозки, будут потеряны.