Что можно настроить при автоматическом резервном копировании

Дата публикации 27.05.2021

Использован релиз 3.0.93

Регулярное создание архивных копий информационной базы уменьшает риск возможной потери данных. Резервное копирование информационной базы можно настроить в автоматическом режиме с любой частотой. Выполнить настройку резервного копирования может только пользователь с правами «Администратор».

Внимание! При работе через облачные технологии данные архивируются централизованно, без участия пользователей.

Раздел: Администрирование – Обслуживание (рис. 1).
Раскройте блок «Резервное копирование и восстановление».
Перейдите по ссылке «Настройка резервного копирования».

Установите флажок «Выполнять автоматическое резервное копирование». Далее выберите один из вариантов создания копий базы:

«Регулярно по расписанию». При выборе этого варианта перейдите по ссылке рядом, чтобы настроить расписание задания резервного копирования (на закладках: «Общее», «Дневное», «Недельное», «Месячное»), которое затем будет отражаться в ссылке (рис. 2).
«При завершении работы». При выборе этого варианта пользователю с правами «Администратор» при завершении рабочего сеанса в программе будет предложено выполнить резервное копирование. Для этого нужно выбрать кнопку «Продолжить», затем нажать на всплывающее сообщение в правом нижнем углу и в форме «Завершение работы» нажать кнопку «Завершить» (рис. 4). По истечении нескольких секунд сообщение будет скрыто, а в правом верхнем углу программы появляется значок в виде колокольчика. Нажмите его, чтобы открыть форму с сообщением и выполнить дальнейшие действия.

В поле «Каталог для сохранения резервных копий» укажите путь к папке, в которую будут помещаться резервные копии информационной базы. Могут быть выбраны: текущее рабочее место, другой компьютер, внешний носитель (рис. 2).

С помощью переключателя «Хранить резервные копии» выберите срок хранения резервных копий или их количество: «Все» (выбирается, если объем носителя, где будет находиться каталог для резервного копирования, является достаточным), «За последние» (следует выбрать срок хранения — количество и временную единицу (в днях, неделях т.п.) или «Последние» (следует выбрать количество копий) (рис. 2).

Нажмите кнопку «Готово», чтобы подтвердить выбор и вернуться к работе в программе (рис. 3).

Не пропускайте последние новости — подпишитесь
на бесплатную рассылку сайта:

десятки экспертов ежедневно мониторят изменения законодательства и судебную практику;
рассылка бесплатная, независимо от наличия договора 1С:ИТС;
ваш e-mail не передается третьим лицам;

Источник

Бэкап 1С: Семь маленьких путешествий в поисках одной большой утилиты

Резервное копирование данных бизнес-приложений – тема древняя, как Кобол, и вечная, как процесс исправления ошибок на Windows. Истинные джедаи системного администрирования вооружаются с этой целью самопальными скриптами, представляющими обычно такое же удивительно постмодерновое сочетание новейших технологий и допотопного мышления, как световой меч из «Звёздных Войн». Офисные же самураи, в отличие от джедаев из серверной комнаты, идут к своему менеджеру-даймё и выпрашивают у него десяток-другой «коку» риса на покупку разрекламированной фирменной обработки для бэкапа данных. (Для тех, кто не в курсе: «обработкой» называется программа на внутреннем языке 1С, а «коку» — это такая мера объёма, которой самураи меряют свою зарплату.)
О проблеме создания резервных копий 1С задумался и я чуть больше года назад, впервые получив в списке своих служебных обязанностей коротенькую инструкцию – «обеспечить сохранность резервных данных предприятия в системе 1С с возможностью их эффективного восстановления». Увы мне – я не джедай-айтишник и не самурай-менеджер. По натуре своей я путешественник. И вот, воспользовавшись попутным гуглем и некоторыми благоприятными знамениями от бухгалтерии нашего института, я пустился в дальнее странствие, чтобы найти приличную утилиту для бэкапа данных 1С как в файловом, так и в SQL-режимах. Об открытых мною в этом странствии решениях и о связанных с ними различных удивительных приключениях и пойдёт речь в моём дальнейшем повествовании.

Странствие первое. Effector Saver

В любом путешествии есть места, миновать которые невозможно. Например, индийский обезьяний полководец Хануман, летевший из Индии на Ланку, не смог миновать пасти водяной змеи Сурасы; голуби, носившие Зевсу амброзию мимо пограничников, регулярно разбивались о камни Симплегад. Вы сами, попав в Париж, обязательно пойдёте глазеть на Эйфелеву башню. И, разумеется, ни один искатель утилит бэкапа для 1С не сможет миновать контакта с Effector Saver, бесплатной программы для сохранения данных 1С! Ну, вот и я – тоже вляпался!
Нет, я ругаться не буду. Effector Saver – программа очень неплохая. Есть бесплатная версия, есть бэкап SQL-контента 1С наряду с файлами, есть и много других приятных «плюшек», здорово облегчающих сисадмину или эникейщику жизнь.
Особенно радуют такие плюсы, как возможность запуска программы в качестве службы Windows, чтобы не отвлекать внимание пользователя лишними действиями, и автоматическое отключение активных пользователей 1С на время бэкапа. Интерфейс весьма логичен, лёгок в освоении и не даёт оснований задумываться над каждым действием.
Сложности начались при переходе от теории к практике. Я – стреляный воробей и тёртый калач, поэтому, прежде чем доверять судьбу родного предприятия стороннему коммерческому продукту, я прежде всего проверил отзывы пользователей. А они, мягко говоря, противоречивы. И пусть соотношение дёгтя к мёду вполне традиционное – бочка к ложке, — но реакция разработчика программы на обнаруженный дёготь, мягко говоря, далека от совершенства. Иначе говоря, он конфликтен. Он справедливо упирает на то, что сделал очень хорошую (и это так!) бесплатную программу, и что за мелкие проблемы этой программы ругать его совершенно не следует. Но проблема-то не в ругани! 1С – это не файл записи к игрушке под DOS, это штука, под управлением которой внезапно могут крутиться многие миллионы. И никому не захочется терять эти миллионы из-за того, что разработчик (повторюсь, проделавший огромный труд!) не стал прислушиваться к паре-тройке неожиданно возникших мелких замечаний.
Повторюсь: не хочу быть несправедливым. Effector Saver показался мне прекрасной программой. Но там, где дело идёт о деньгах, одной красоты недостаточно. И я вынужден был расстаться, скрепя сердце, с чудесной страной Effector Saver и пуститься в следующее своё странствие.

Читайте также: Ржд не работает wifi

Странствие второе. Handy Backup

Этот продукт изначально пленил меня сочетанием несколько старомодного внешнего исполнения с весьма современным наполнением. По виду он архаичен, как Windows 98, а по функциональности надёжен, как автомат Калашникова. Под замшелым интерфейсом скрывается, как в волшебном гроте, прекрасный набор самых актуальных функций для бэкапа, восстановления и синхронизации данных. Здесь тебе и запись бэкапов на какое угодно коммерческое облако, хоть Dropbox, хоть Amazon S3, хоть OneDrive (не говоря уж о более приземлённых носителях, вроде FTP или USB-диска), здесь и работа со всеми видами баз данных, и хранение нескольких версий под временными метками… Руководство пользователя Handy Backup, сулившее неисчислимые возможности, пленило меня, как нимфа Калипсо пленила некогда застигнутого бурей Одиссея. Там было описано в подробностях всё, вообще всё, что только можно делать с бэкапами! Это было весьма захватывающее чтение…
Я немедленно помчался на официальный сайт Handy Backup и скачал пробную версию на тридцать дней, чтобы убедиться, как рекламные посулы в очередной раз затуманили мне вид на неприглядную истину. Я разочаровался! Нет, не в том смысле: я разочаровался в своих ожидаемых разочарованиях. Handy Backup и в самом деле делает всё, что обещает! В отчаянии, я связался со службой технической поддержки продукта («предоставляемой в течение всего срока жизни лицензии», как написано на сайте) – и внезапно получил грамотную, серьёзную техническую консультацию. Эта функция тоже работает, как и все остальные! Более того, за время моего тестирования Handy Backup вышли два обновления, каждое из которых содержало не затычки и заглушки к предыдущим ошибкам, а новые полезные функции.
Почему же я покинул этот рай земной и отправился дальше, в новые странствия по негостеприимным берегам чужих программных продуктов? Ответ прост: деньги. Handy Backup – платная программа, а душа, как известно, просит программ бесплатных. А у Handy Backup бесплатная только версия, позволяющая сохранять копии чего угодно (да, и 1С тоже!) исключительно на Яндекс.Диск. За всё остальное надлежит выложить денежки, в количестве, зависящем от требуемого набора функций автоматического бэкапа. И если файловую версию 1С Handy Backup способен распознавать и сохранять во всех комплектациях, начиная с базовой Standard примерно за сорок долларов, то за хранение резервных копий СУБД на основе SQL придётся существенно доплатить.
Послав руководству подробный отчёт о прелестях Handy Backup (в надежде, что внезапно всё-таки дадут денег!), я тем временем собрал свой скудный багаж и двинулся в новый путь.

Странствие третье. «Хранитель V»

Странствие четвёртое. «Бэкапер-1С»

Наконец-то судьба вновь занесла меня в цивилизованное место! «Бэкапер-1С», написанный, как мне удалось понять, программистом Алексеем Кармановым, не только живёт, но и время от времени обновляется (последняя версия вышла где-то в середине 2013 года). Эта программа проста, бесплатна и обладает хорошим понятным интерфейсом. К тому же, разработчик очень дружелюбен, хорошо объясняет не только выгоды и преимущества своей программы, но и технику работы с ней, а также, по всей видимости, быстро и адекватно реагирует на замечания пользователей. После контакта с «Бэкапером» короткий опыт общения с Effector Saver кажется годом, проведённым в пещере циклопа Полифема.
«Бэкапер-1С» предназначен для «простых» пользователей 1С и, как следствие, лишён некоторых важных особенностей функционала. В частности, мне не удалось запустить его как службу Windows. Кроме того, для архивирования данных он использует встроенную программу 7-Zip, что бывает весьма удобно для пользователей, но иногда вызывает самые неожиданные проблемы, например, с корпоративной политикой безопасности. И всё же это решение заняло в моём личном рейтинге место рядом с Handy Backup; к нему мне не раз захотелось вернуться.

Странствие пятое: «1СкриптМенеджер для MS SQL»

В этом месте меня начали мучить сомнения: туда ли я попал? Ведь мне нужно сохранять резервные копии и для файловой версии, и для самых разных СУБД! Но, кроме упоминания MS SQL в заголовке, я не нашёл с ходу никаких других вариантов работы с «1СкриптМенеджер». Ужаснула и цена: что-то около пяти с половиной тысяч рублей за продукт с, мягко говоря, ограниченной функциональностью!
Я хотел было уже развернуться и закончить странствие, но меня привлекли неожиданно хорошие отзывы о продукте. Системные администраторы – народ суровый, они без нужды не похвалят ни Стива Джобса, ни Стива Балмера, ни даже, о ужас, Питера Нортона – а тут вдруг собрались на форумах и поют настоящие дифирамбы! Иначе говоря, если бэкап 1С с базой на MS SQL – это именно то, что нужно лично вам, то этот вариант, по всей видимости, вполне можно и нужно рассматривать. Мне же настоятельно необходим был бэкап именно для файловой версии. Поэтому я расстроился и уехал с этого ресурса.

Источник

Практические рекомендации по политике резервного копирования

Резервное копирование

Проводите резервное копирование ПЕРЕД обновлением системы

Перед установкой обновлений приложений и операционной системы, переходом на новые версии программного обеспечения, модернизацией оборудования и проведением других значительных изменений в системе, целесообразно выполнить резервное копирование, так как, если обновление пройдет не успешно и система войдет в некорректное состояние, то у администратора будет возможность откатить изменения и вернуться к стабильному состоянию с наименьшими потерями для бизнеса (с точки зрения RPO).

Предположим следующий сценарий:

Плановый бэкап проходит в ночь со вторника на среду
До среды система используется в режиме «как обычно»
Вечером в среду система обновляется (устанавливается новая версия системного программного обеспечения). В виду того, что перед установкой release notes были прочитаны не достаточной внимательно, система входит в нестабильное состояние.
Система переустановлена с потерей данных на момент своего состояния во вторник
В четверг пользователи вынуждены пересоздать все данные, созданные за среду

Хотя этот пример может показаться несколько утрированным, тем не менее, законы Мэрфи действуют в полной мере и в информационных технологиях. Поэтому все же не стоит пренебрегать созданием «лишней» инкрементальной резервной копии перед обновлением системы. Если же компания не может себе позволить «терять время» на «профилактическое» резервной копирование, то стоит задуматься над применением отказоустойчивого кластера, автоматических аппаратных снапшотов СХД, или других способов обеспечения постоянной доступности системы без ущерба для надежности ее данных.

Проводите ПОЛНОЕ резервное копирование сразу после существенного обновления системы

Пример:

Полная резервная копия создается по пятницам, в остальные дни создаются инкрементальные копии
В среду было произведено обновление сервера базы данных до новой версии, которое сопровождалось обновлением некоторых общих системных файлов, относящихся к операционной системе
В ночь на четверг была, как обычно, получена инкрементальная резервная копия
В четверг утром произошел критический сбой, потребовавший восстановления системы
Изучив характер сбоя, администратор понимает, что повреждены только системные файлы и для восстановления функционирования системы достаточно было бы восстановить только множество системных фалов (system state), используя последнюю полную резервную копию. Однако, если сделать только это, то обновленная версия сервера базы данных перестанет работать, так как ей требуются более новые версии системных файлов (например, последняя версия .NET Framework), которые были установлены вместе с ним. Это приводит к необходимости продолжать процесс восстановления, просматривая необходимые инкрементальные копии, которые содержат изменения в system state. Это ведет, в конечном счете, к увеличению трудоемкости процесса восстановления и увеличению времени RTO, вплоть до нарушения SLA.

Общую рекомендацию можно сформулировать следующим образом: если кумулятивный объем инкрементальных резервных копий превосходит объем полной резервной копии, рационально сделать внеплановую полную резервную копию.

Проводите полное резервное копирование СРАЗУ после восстановления системы

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

«Не гонитесь за двумя зайцами» или «Модернизация — зло»

Не стоит совмещать процесс восстановления системы после сбоев и процесс ее модернизации. Несмотря на то, что это может показаться очевидным, дефицит времени на технологические процедуры во время непрерывного производственного функционирования системы, а также нежелание вносить (даже необходимые) изменения в «то, что и так нормально работает», может вызвать желание использовать момент вынужденного простоя системы во время сбоя для того, чтобы выполнить модернизацию, так сказать «за одно».

Рассмотрим несколько примеров, что из этого может получиться:

Система удачно восстановлена после сбоя, но администратор принимает решение сразу установить самые последние обновления на систему, чтобы потом не прерывать работу пользователей для этих целей. Однако один из патчей некорректно устанавливается, и система рушится. В результате систему опять приходится восстанавливать с нуля.
Произошел критический сбой сервера приложения версии X.1. Система не была затронута сбоем. Администратор решил в процессе восстановления установить новую версию X.2 с установочного диска и восстановить из резервной копии данные приложения и дополнительные программные модули, реализующие специфичную бизнес логику. Однако после восстановления данных и модулей выяснилось, что они не совместимы с новой версией X.2 из-за небольших изменений в логике работы некоторых программных функций и в спецификациях некоторых программных интерфейсов. В результате сервер приложений пришлось восстанавливать сервер приложений версии X.1.
Произошел критический сбой операционной системы версии X. Пользователь не нашел установочный диск версии X (так как эта версия была установлена 3 года назад) и установил версию X+1. У администратора возникла проблема с учетом лицензий, кроме того, одно используемое для работы бизнес приложение оказалось не совместимо с новой версией операционной системы. Систему пришлось переустанавливать.

Как следствие можно рекомендовать установление политики по процедуре восстановления после сбоев, в рамках которой никакие действия по модернизации не будут рассматриваться как допустимые. Целью процедуры восстановления является исключительно восстановление работоспособности исходной системы за минимальное время (RTO). Мероприятия по модернизации системы должны проводится отдельно в специально запланированное время, и сопровождаться процедурами предварительного тестирования обновлений, запланированных для установки.

Обо всем понемногу

Читайте документацию ПЕРЕД тем как настроить резервное копирование

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

Пример «нюансов» такого рода:

В процессе резервного копирования не сохраняются различные пароли и информация о лицензии. А это означает, что при восстановлении не удастся получить работоспособное приложение или операционную систему, а план восстановления после сбоев в части декларированного RTO окажется сорванным.
Системная конфигурация приложения должна сохраняться по специальной процедуре, отдельной от процедуры бэкапа самих данных
Процедура бэкапа открытых на запись файлов является специальным образом оговоренной в документации (требуется заранее включить определенные настройки в конфигурации приложения).

Процесс восстановления должен производится администраторами

Тестирование восстановления должно проводиться регулярно

Само наличие резервных копий еще не означает, что восстановление пройдет без проблем. Во-первых данные могут быть неверно сохранены, во-вторых, данные при хранении могут со временем исказиться, или при восстановлении вдруг выяснится, что в резервной копии были сохранены не все необходимые данные. Подробнее об этом было уже написано в посте: Тестирование восстановления из резервных копий.

Учитывайте зависимости от инфраструктурных компонентов сети

Предположим, что сбой произошел на DNS сервере. После запуска процедуры восстановления оказалось, что используемый продукт резервного копирования использует DNS в рамках работы с собственной инфраструктурой (например, соединяется с репозиторием резервных копий, используя FQDN имя сервера). В результате получается «циркулярная зависимость», не позволяющая автоматически выполнить восстановление после сбоя. Аналогичная ситуация может наблюдаться с контролером домена (но здесь спасает то, что контролеров домена обычно в компании несколько).

Таких циркулярных зависимостей следует стараться избегать. Выявлять их позволяет тестирование восстановления резервных копий в изолированную от продуктивной сети песочницу, например, с помощью технологии Veeam SureBackup.

Документирование процедур стадии восстановления

Аккуратно документируйте процедуру восстановления после сбоев

Что тестировать в рамках проверки процедуры восстановления после сбоев?

Для того, чтобы инструкции, применяемые в процессе восстановления после сбоев, были максимально корректны, нужно проводить «учебные восстановления». В процессе проведения тестирования процесса восстановления нужно обратить внимание по крайней мере на такие вопросы как:

В случае полного разрушения сайта, будут ли резервные копии содержать всю информацию, необходимую для его восстановления?
Как будет проходить процесс восстановления, если главный системный администратор будет недоступен (скажем, будет находится в заграничном отпуске)?
Что произойдет, если окажется поврежденным носитель информации (лента/диск), на котором размещена резервная копия, наиболее подходящая для использования в процессе восстановления?
Что будет в случае т.н. «вторичного сбоя»? То есть, в случае, когда после успешного завершения процесса восстановления, окажется, что восстановленная система не работает?
Укладывается ли время, затраченное на процесс восстановления, в оговоренный SLA? Знают ли вовлеченные в процесс люди о существовании SLA и его параметрах, и принимают ли его во внимание в своей работе?
Как скажется на процесс восстановления отказ инфраструктурных компонентов продуктивной сети (почтовый сервер, сервер мгновенных сообщений, DNS, контролер домена и т.д.)
Качество документации: cможет ли нетренированный администратор восстановить продуктивную систему, следуя письменным инструкциям?
Скорость реакции компании, если причиной разрушения информации стал вирус (любого типа). Специфичность этой угрозы в том, что вирус может исказить данные и приложения, не нарушив при этом их доступность,- в результате чего системы обеспечения отказоустойчивости не зафиксируют сбой, кроме того, настроенные механизмы репликации изменений данных автоматически разнесут эти искажения по остальным репликационным партнерам (или узлам кластера/геокластера).
Зависит ли процесс восстановления от специфичной аппаратуры (которая может выйти из строя в момент восстановления)?
Можно ли провести процесс восстановления полностью удаленно?
Что будет, если будет нарушена работа канала, связывающего бэкап-сайты компании?

Разумеется при составлении списка угроз работоспособности продуктивной системы, нужно учитывать также вероятность возникновения этих угроз, и сравнивать с потенциальным ущербом от простоя системы в каждом случае.

Общий вывод

Планирование и тестирование резервного копирования и восстановления является важнейшим фактором, позволяющим минимизировать RTO и выполнить условия SLA. Наличие в продукте резервного копирования функционала в части автоматизации тестирования восстановления из резервных копий является крайне важным.

Источник