Настройка резервного копирования 1С версии 8.3

Основы резервного копирования

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

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

Для MS SQL необходимо:

• Применение кластеров MS SQL;
• Зеркалирование базы данных;
• Журналы транзакций;
• Репликация распределенными базами данных.

Первые версии 1С использовались для разработки с популярным на то время форматом dbf. Его расширение не позволяло хранить в своей базе данных достаточное количество информации для отображения резервного копирования данных в полном объеме. Приходилось использовать большое количество обходных путей, разбивать данные на тома, чтобы резервное копирование функционировало в полном объеме, как этого требовали пользователи.
По выходу версии 8, администраторы сумели расслабиться и вздохнуть. Стационарные средства начали позволять копировать информацию в полном объеме и дублировать её по принципу резервного копирования. Единственным исключением является журнал регистрации, который не входит в резервное копирование данных. Хоть это и не критично, но все же создает некий дискомфорт в работе операторов.
Актуальный вопрос может возникнуть у каждого пользователя системы. Зачем нужно резервное копирование вцелом? Для чего оно необходимо?
В первую очередь, для того чтобы иметь возможность восстановить копию системы при первой же необходимости. Во вторых, при каком-либо сбое системы, все данные не будут утеряны и работа сможет продолжаться с последнего момента разрыва.

Вирусы и опасности

Большую опасность представляют собой вирусы-шифровальщики. Наиболее распространённый способ проникновения данного вируса в систему 1С – это электронная почта. Опасность заключается в том, что они могут привести к поломке системы за счет системных и административных сбоев. Стирание базы данных системы и поломка оборудования могут полностью сорвать и нарушить весь рабочий процесс. Ошибка базы данных полностью поглотит систему, не давая шансов на восстановление системы или на откат до последней исправно рабочей сессии.
Часто этот вирус распространяется по системе под названием 1C.Drop.1. По сути, это троян, который проникает в систему и сжирает её. Это необязательно могут быть конкуренты или злоумышленники. Вирус распространяется сам по системе как паразит, поглощая всё на своем пути. Электронный адрес может находиться в базе контрагентов бухгалтеров, работающих в системе 1С,. Троян-шифровальщик сам делает свою работу без участия хакера-оператора. Вирус с легкостью проникает в базу данных, так как написан на языке системы 1С, и программа его воспринимает без угроз.
Вирус работает по принципу проникания в систему и считывает контрагентов вашей базы, рассылая им тот же злоумышленный вирус в геометрической прогрессии. В качестве самого вируса, троян прикрепляет к письму файл с расширением epf. При запуске данного шифровальщика запускается процесс невозврата вируса.
После завершения рассылки, файл начинает шифровать данные, и на помощь ему приходит Trojan.Encoder.567, который уже непосредственно заражает файловую систему 1С.
Рекомендации по защите базы данных очень просты. Не стоит открывать все файлы, которые приходят вам рассылкой на почтовый ящик. Также, следует проверять систему на вирусы и обновлять базу на наличие новых вирусов в сети с целью защиты вашей системы.
Само по себе, резервное копирование – это надежность и сохранность системы базы данных до последнего момента конфликта системы или же принудительного сбоя программы. Если администратору приходится восстанавливать резервное копирование файлов, то это означает, что он допустил глобальные ошибки в работе или система дала сбой самостоятельно. Стоит учитывать, что данное восстановления не является источником полноценного целостного вытягивания базы данных. Это скорее экстренный рубеж по файлам, их спасение перед полным уничтожением. Сам факт этой процедуры говорит о серьезном риске.
Для перестраховки и надежности сохранения базы данных при резервном копировании, следует использовать другие средства:
1. Защита серверов от физических воздействий на них, перебои в электропитании, пожар, проникновение влаги;
2. Ответственность при угрозе информационной безопасности;
3. Четкая работа по инструкции данных, которая вносится в систему и использования поэтапного плана действий касательно работы в программах.
4. Зеркалирование информации по принципу синхронности и асинхронности данных;
5. Задействование повышенной доступности и надежности к системе. В случае MS SQL, следует сделать акцент на задействовании кластеров MS SQL, журнале транзакций, распределении под средством репликации баз данных 1С.

Отталкиваясь от бюджета и требований доступности системы, можно подобрать решение, которое позволит сократить время простоя и восстановление базы данных после сбоев системы. Стоит использовать технологию повышенной доступности системы MS SQL.
Невзирая на все подводные камни, резервное копирование необходимо. Это гарантия вашей системы и базы данных, которая вас выручит в самый неожиданный момент. Для этого потребуется:
• Информация базы данных хранения MS SQL,
• Система должна быть настроена должным образом и работать соответствующе,
• Оператор системы должен владеть навыками специалиста, работая с данной системой,
• Система должна быть оптимальной и состоять из надежных составляющих компонентов.

MS SQL информация обычно хранится в базе данных файлов с расширением форматов mdf или ndf. Также не стоить забывать о журналах транзакций, которые зачастую имеют расширение формата ldf.
Часто новые специалисты халатно относятся к журналу транзакций, считая что это не столь важный момент их рабочего процесса по отношению к работе производительности и учета хранения. Это неприемлемо. Система работает с точностью да наоборот. Поскольку имеется надежная система резервного копирования, то необходимо этому процессу уделить максимум времени. При желании, можно хранить данные на быстром, но и менее надежном RAID-0, но журнал транзакций должен храниться отдельно на достоверном ресурсе. Как минимум, на RAID-1.
Почему так? Всё дело в том, что в файловых данных хранится информация равная 8 килобайтам, которые, в свою очередь, объединены в экстенты по 64 килобайта. MS SQL не дает никаких гарантий что по завершению выполнения команд, данные попадут в базу файловых данных. Попросту страница приобретает статус потребности сохранить документ вручную. Если сервер располагает достаточным количеством ресурсов, то за очень короткий промежуток времени, данные будут сохранены на диске. Диск по своей специфике, работает оптимистично и, в связи с этим, если изменение данных происходит по транзакции, то они могут быть сохранены на диск еще до самой фиксации той же транзакции. Иными словами, файловые данные должны содержать части одной единой базы данных о транзакции, и они не должны содержать информацию о том, будут ли отменены или зафиксированы.

Настройка архивации базы данных 1С

Техника часто дает сбой и не всегда является надежной. Это может привести к серьезным последствиям, таким как потеря важной информации и базы данных. Это важный аспект работы. В противном случае, из-за этого может пострадать финансовая сторона вопроса компании. Для того чтобы избежать этого, нужно наладить резервное копирование данных системы 1С. Для хорошей и качественной настройки, есть рекомендованный и проверенный софт Effector saver 3. Программа синхронизирует все процессы с настройками, выгоняет нежелательных пользователей сети, тестирует базу и исправляет ошибки, но что самое главное — она автоматически создает копию базы данных и рассылает отчет по указанному графику. Проблем с установкой софта не возникнет, он работает со всеми версиями 1С: 7.7, 8.1, 8.2, 8.3. Легко обрабатывает сессии и таблицы. Программное обеспечение абсолютно бесплатное, но есть и коммерческая версия для более широкого спектра работ. Настройка очень проста и понятна любому пользователю за счет удобного интерфейса и русскоязычного меню. С помощью расширения, работа пойдет проще и надежнее.
Полезная команда «CHECKPOINT», принудительно сообщает серверу о том, что необходимо в данный момент провести операцию сохранения и перебросить данные на диск. 1С эту команду не использует по той причине, что во время работы, файловые данные не расположены целостно, а раскиданы хаотично по системе. Да, это неудобно. И тут на помощь приходит журнал транзакций. Он собирает в себя такие данные как:
• Идентификатор транзакции и данные о его старт-апе,
• Данные о принятии или отмене транзакции,
• Статистические данные об изменении файловых данных.
Данные про все изменения файлов базы данных или структуру базы включают в себя расширение размеров файла, уменьшение файла, опустошение страницы и её выделение, создание индексов и таблиц.
Все операции прописываются по идентификатору транзакции, в которой она была задействована в том объеме, в котором можно проанализировать все шаги от первого исходного момента до завершения, и наоборот. Эти данные записываются на диск мгновенно. До того момента пока команда не записана в журнал транзакций, операция считается невыполненной. В той ситуации, когда журнал транзакций имеет достаточное количество памяти незначительную фрагментацию, то данные записываются поэтапно малыми частями. В журнал транзакций только те данные, которые действительно нужны для восстановления данных, а не все подряд. Например, информация о данных, которые свидетельствуют о том, какой именно текст модификацию, какой план выполнения запроса, кто из пользователей запустил данную операцию – эти данные не нужны и они отсеиваются сразу.
За счет того, что диски работают более продуктивно и быстро при работе с последовательной записью, операции SQL выжидают момент окончания записи журнала транзакции.
Рабочая среда журнала транзакций лучше будет размещаться на разных носителях информации с максимальной защитой, таких как RAID-1.
В случае, если транзакция была приостановлена, то сервер автоматически делает откат и возвращает всё до первоначального состояния.
MS SQL Server проводит операции по времени, равному длительности всей транзакции и по суммарному времени самой транзакции. Не принимайте решение об отмене транзакции преждевременно. Это может привести к зависанию системы или долгой обработке программы. В качестве перестраховки программой, когда сервер оборвет процесс работы, при повторном запуске будет проведен автоматический анализ программой, и неполноценно отрубленные части данных будут автоматически подтянуты, восстановлены и откорректированы. Когда вы перестроили индексы, а особенно большой индекс по содержанию таблицы, плюс перезапустили свой сервер, то на обработку данных уйдет большой промежуток времени. На восстановление данных этой таблицы и прерывание данной процедуры у вас возможности не будет.

Когда журнал транзакций завершил свою работу и дошел до конца, есть промежуточно пустое место вначале. Он переключит свое внимание на это место и начнет писать данные там впредь до занятой позиции по принципу магнитной ленты. Если места оказывается мало, то машинально анализируется всё пространство и определяется потенциальная возможность записи информации вцелом. Происходит виртуальное накопление записи базы данных. По завершению, данные обрабатываются и синхронизируют данные с диском. Если места недостаточно или же стоит запрет на расширение базы данных, это значит что сервер попросту не сумел расширить журнал транзакции. Выскочит ошибка 9002, которая сообщит о проблеме.
Возникает встречный вопрос: как распределять память и свой алгоритм действий, чтобы было место и такие ошибки не всплывали в самый неподходящий момент? Тут-то нам и пригодится резервное копирование, как восстановление. Чтобы отменить транзакцию и восстановить систему корректным способом при спонтанном сбое сервера, необходимо обратиться к журналу данных с откатом, который запомнит первичную стадию и все промежуточные изменения, впредь до вашего последнего корректирования.
Этот минимальный объем информации пишется и сохраняется в резерве журнала транзакции в принудительном порядке. На это не влияют никакие внешние факторы по типу климата, желания системного администратора или каких-либо других настроек. Серверное запрограммированное обслуживание не допустит такой ситуации, чтобы эта информация не была зафиксирована.

Резервное копирование выстроенными средствами 1С

Резервное копирование файловой базы 1С просто необходимо, это делается с целью безопасности системы и защиты данных от неожиданных сюрпризов. Во время копирования, сессия должна постоянно быть открыта и не иметь перебоев с электропитанием. В противном случае, процесс оборвётся. Предварительно стоит настроить файловую базу на локальной основе, после чего приступать к резервному копированию выстроенными средствами 1С. Это рекомендация самой программы 1С для безошибочной архивации.
Пошаговая инструкция выглядит следующим образом:
1. Вам необходимо обновить вашу платформу,
2. Провести очистку вашего кэша и добавить туда базу,
3. Стереть все ранее созданные бэкапы и откаты, в которые они были сохранены.

Варианты резервного копирования для файловой базы и клиент-сервера

Как и любая база данных, резервное копирование позволяет воспроизводить загрузку и выгрузку данных. Это дает возможность сохранять образ информации вне зависимости от места её хранения. Часто эту функцию используют для создания резервной копии. В таком случае, необходимо использовать только протоколы одного пользователя-оператора, а не общей базы в целом. По сути, можно рекомендовать способы создания резервной базы, а именно:
• Во время использования 1С можно создать копию базы данных путем копирования файла 1CV8.1CD посредством копирования для восстановления базы данных или бэкапа в дальнейшем.
• При задействовании клиент-сервиса 1С, на предприятиях появляется возможность создавать резервную копию путем СУБД. К примеру, SQL Server дает возможность выполнять копирование в то время, когда база данных находится в многопользовательском режиме и доступна всем одновременно. Это очень удобно для предприятий и больших компаний.
Важно отметить, что без предварительной резервной копии, разносное копирование не имеет никакого смысла. Рекомендовано хранить эти две копии вместе. Каждая новая разносная копия, по своей специфике, хранит все страницы предыдущих копий. Посему, каждая последующая копия будет больше и больше. Это длится до тех пор, пока не будет создана новая полная копия. Единственный фактор, который может на это повлиять — это алгоритм сжатия данных.
Для того чтобы произвести восстановление, достаточно полной резервной копии. Для определения конкретного отката копии могут понадобиться промежуточные копии. Хотя при полном восстановлении они не потребуются. Резервная копия журналов транзакций дает возможность восстановить копии данных любого промежутка времени в режиме NORECOVERY. Во время форматирования резервной копии в режиме стандартных настроек, место высвобождается впредь до момента последней запущенной транзакции.
Следовательно, резервное копирование журнала транзакций не имеет никакого смысла в модели Simple, потому что журнал данных хранит информацию по последней незакрытой транзакции. При задействовании резервной копии журнала транзакции, появляется такой процесс как – непрерывная цепочка резервного копирования журнала транзакции. Её может прервать потеря резервных копий собственной цепи или же трансформация резервных копий данных в Simple и обратно.
Набор резервного копирования журнала данных в некотором роде не имеет смысл. В том случае, если это копирование не является непрерывной цепочкой. Момент начала копирования данной цепочки должен быть внутри данного цикла.
Резервное копирование журнала транзакций имеет в себе базу данных журнала транзакций с ранее полного или разносного отката (так называемого бэкапа). Бэкап должен привести к опустошению места внутри самого журнала. Также, журнал транзакций необходимо периодически чистить вручную. Но нужно помнить, что если освобождать журнал транзакций между резервной копией, то может быть нарушена цепочка резервной копии журнала транзакций, необходимая для восстановления и бэкапа. Периодические перемены местонахождений и изменение размера файлов приведут, в конечном итоге, к физической и логической фрагментации диска.
В 1С существует единая файловая группа. Оператор базы данных MS SQL может переместить некоторые таблицы, части таблиц и индексы в иные файловые группы или отдельные файлы. Как правило, для того чтобы ускорить работу и доступ к данным. Как вариант, это может быть перемещение файлов на быстрые носители чтения информации или же в ущерб скорости, перемещая данные на более медленные носители чтения информации. Это происходит, если база данных малоиспользуемая, но изрядно объемная.
При работе с группами файлов имеется потенциальная возможность создавать их резервные копии отдельно. В такой же отдельный способ можно восстанавливать базы данных. В этом случае все файловые группы необходимо будет подогнать до одного и того же момента резервного копирования журнала транзакции.
Если размещением данных по разным файловым группам занимается оператор вручную, и в содержимом файлов образуются группы, то данные размещает MS SQL Server самостоятельно. При условии, что размеры файлов одинаковые. Этот процесс используется для равномерного распределение операций ввода и вывода.
Начиная с 2008 года, MS SQL Server запустил возможность компрессировать резервные копии при форматировании автоматически. Это сжимает размер резервной копии и экономит место на диске базы данных 1С в 5-10 раз. Также это влияет на ускорение резервного копирования базы данных, хоть и усиливает нагрузку на сами процессы.
Надеемся, что наша статья помогла вам разобраться в процессе резервного копирования 1С.