Блок А.Н.Еще вот этот файл очень важен c:\InterSystems\Cache\mgr\cache.wijПри лёгких сбоях (типа внепланового reset'a или reboot'a), если базы не пострадали - оно, конечно, да. Но если базы рухнули и их надо восстанавливать из бакапа - то уже не важен.

Если по теме, то некоторые мои коллеги поступают так: бакапят Cache по расписанию менеджера задач внутри VM, и бакапят всю VM (с Cache-backup-ами внутри), не останавливая её. После восстановления VM необходимо проверка ^Integrity, и если что-то не так, то "под рукой" оказывается и последний бакап, и журналы. В 99(.9)% случаях ошибок нет, что вызывает у некоторых ложное чувство уверенности, что их и быть не может, что, конечно, неверно.

Не то чтобы мне очень нравилась такая технология, но почему бы и нет. Тем более, что лишний раз целостность проверить никогда не худо. Интересно, у многих ли в расписании разблокирована эта задача, и многие ли заглядывают в её протокол, пока что-нибудь не кольнёт?

И ещё про виртуалки. Имхо, это потенциальный источник проблем при эксплуатации Cache (о разработке молчу), т.к. всевозможные приёмы оптимизации работы с памятью (memory balooning, overcommit) вредны для системы, которая любит , когда разделяемая память в избытке, и она всегда резидентна. Любит работать на процессорах с известным (желательно большим) количеством ядер, не деля ни с кем их мощность. Есть примеры, когда "наевшись досыта", люди переходили к конфигурациям 1 VM = 1 железный хост (но зачем тогда VM?), либо вообще уходили на "железо".

Впрочем, это я о системах с сотнями пользователей. Небольшие, не очень нагруженные системы на VM - почему бы и нет? (можно бы спросить, ради чего в таких системах используется Cache, но не буду )))

sanyock2хотел пояснить цель такого разделения по дискамДа я в принципе с вами согласен, нормальная схема. Опробовал недавно похожую, но на "железе". Снапшот делал средствами LVM (CentOS 6.3). Поскольку это "железо", мой скрипт может полностью контролировать работу Cache. Демона записи Cache замораживается на время создания снапшота (этого всего несколько секунд), поэтому работа пользователей не останавливается, а файлы БД на диске остаются "чистыми". Далее снапшот бакапится и тут же удаляется, так что он не превращается в длительный тормоз в работе системы. По моей оценке, время жизни снапшота 300GB-ной установки Cache составит в моих условиях 40-50 минут.

Плюсы, мне кажется, очевидны: получается действительно полный бакап всей установки Cache, не требующий для запуска дополнительных операций восстановления и/или копирования, только актуальные журналы "подтянуть"...

Места под журналы на быстрых дисках мне не то чтобы очень жалко (у нас журналы составляют < 5% объёма БД), просто Cache даёт более ровную загрузку дисков, без резких всплесков, когда журналы находятся на другом физическом диске. Поэтому уместна модификация схемы, когда журналы находятся на отдельном диске.

То, что вы описали, обычно называют СХД или SAN .

Зеркало предполагает наличие первичного и вторичного тома (хранилища). Не совсем понятно, что вы имеете в виду, говоря о зеркале.