Сервер резервного копирования 1С — это отдельный сервер или система хранения, предназначенная для создания, хранения и восстановления резервных копий базы 1С, виртуальных машин и связанных с ними данных.
Для небольшой информационной базы может быть достаточно обычной копии базы данных. Однако для критически важных систем 1С такой подход не всегда обеспечивает быстрое восстановление после сбоя сервера, повреждения данных, аппаратной неисправности или атаки ransomware.
При организации резервного копирования 1С важно защищать не только данные информационной базы, но и серверную среду, в которой работает 1С.
В этой статье рассмотрим, что именно необходимо резервировать на сервере 1С, какие способы резервного копирования существуют, где хранить резервные копии, как автоматизировать процесс и как восстановить сервер после серьезного сбоя.
Что необходимо резервировать на сервере 1С
Прежде чем выбрать способ резервного копирования 1С, необходимо определить, какие компоненты инфраструктуры нужно защищать.
В простом случае достаточно резервной копии базы данных. Однако если 1С используется для критически важных бизнес-процессов, рекомендуется учитывать также операционную систему, сервер 1С, СУБД, конфигурацию и виртуальную машину.
| Объект | Что необходимо защитить | Возможный способ резервного копирования |
|---|
| База 1С | Данные информационной базы | Резервная копия базы |
| Microsoft SQL Server | База данных и журналы транзакций | SQL Server Backup |
| PostgreSQL | База данных и WAL | PostgreSQL Backup |
| Сервер 1С | ОС, приложения и конфигурация | Резервное копирование сервера |
| Виртуальная машина | Вся серверная среда | Резервное копирование ВМ |
| Конфигурационные файлы | Настройки и параметры | Файловая копия |
| Резервные копии | Backup-данные | Отдельное или удаленное хранилище |
Например, сервер 1С может включать операционную систему, сервер приложений 1С, базу данных, сетевые настройки и другие компоненты. Если резервируется только база, после отказа сервера остальные компоненты придется устанавливать и настраивать заново.
Поэтому для критически важных систем целесообразно использовать многоуровневый подход:
резервное копирование базы + резервное копирование сервера или виртуальной машины + отдельное хранение копий.
Способы резервного копирования 1С
Способ резервного копирования зависит от типа базы 1С, используемой СУБД и архитектуры сервера.
Основными вариантами являются резервное копирование файловой базы, базы Microsoft SQL Server, PostgreSQL и виртуальной машины.
Файловая база
Если 1С работает с файловой базой, данные информационной базы хранятся в файловой структуре.
Один из вариантов — создание копии базы и сохранение ее на отдельном носителе.
Такой способ относительно прост и может подходить для небольших систем. Однако при работе с производственной базой необходимо учитывать целостность данных и активность пользователей.
Кроме того, копия файла базы не является полноценной резервной копией сервера 1С.
При выходе сервера из строя администратору может потребоваться дополнительно:
установить операционную систему;
установить сервер 1С;
настроить необходимые службы;
восстановить параметры сервера;
восстановить базу;
проверить подключение пользователей.
Поэтому файловое копирование может использоваться как один из уровней защиты, но не обязательно должно быть единственным способом резервирования.
Microsoft SQL Server
Многие корпоративные информационные системы 1С работают с Microsoft SQL Server.
В этом случае для резервного копирования базы можно использовать стандартные механизмы SQL Server:
Full Backup — полное резервное копирование;
Differential Backup — дифференциальное резервное копирование;
Transaction Log Backup — резервное копирование журнала транзакций.
Полная резервная копия содержит данные базы на момент создания копии и может использоваться как основа для последующего восстановления.
Дифференциальная копия содержит изменения после последней полной резервной копии. Это позволяет уменьшить объем данных по сравнению с частым созданием полного backup.
Резервное копирование журнала транзакций позволяет создавать более частые точки восстановления и уменьшать потенциальную потерю данных.
Например, стратегия может выглядеть следующим образом:
| Тип резервной копии | Пример использования |
|---|
| Full Backup | Один раз в день или неделю |
| Differential Backup | Несколько раз в день |
| Transaction Log Backup | Каждые 15–30 минут |
Конкретное расписание необходимо выбирать с учетом объема базы, нагрузки на сервер и требований бизнеса к RPO.
Важно понимать, что резервная копия SQL Server защищает прежде всего базу данных. Если выходит из строя весь сервер 1С, одной копии базы может быть недостаточно для быстрого восстановления рабочей среды.
PostgreSQL
PostgreSQL также используется в качестве СУБД для 1С.
В зависимости от требований к восстановлению можно использовать различные механизмы резервного копирования PostgreSQL, включая логические и физические резервные копии, а также механизмы, связанные с WAL.
При выборе стратегии необходимо учитывать:
размер базы данных;
скорость изменения данных;
требуемую частоту резервирования;
допустимую потерю данных;
время восстановления;
объем доступного хранилища.
Как и в случае с Microsoft SQL Server, резервное копирование PostgreSQL решает прежде всего задачу защиты базы данных.
Для полного восстановления сервера 1С после серьезного сбоя может потребоваться дополнительное резервное копирование всей серверной среды.
Виртуальная машина
Если сервер 1С работает внутри виртуальной машины, можно резервировать не только базу данных, но и всю виртуальную машину.
Это принципиальное отличие от обычного database backup.
Виртуальная машина может содержать:
операционную систему;
сервер 1С;
СУБД;
конфигурацию;
системные настройки;
необходимые приложения;
данные.
При резервном копировании виртуальной машины все эти компоненты могут быть защищены как единая серверная среда.
Если физический сервер или виртуальная машина выходит из строя, восстановление ВМ позволяет избежать повторной установки всей инфраструктуры с нуля.
Поэтому резервное копирование виртуальной машины 1С особенно актуально для критически важных систем и инфраструктуры, где важна минимизация времени простоя.
Как настроить автоматическое резервное копирование 1С
Ручное создание резервных копий не подходит для большинства производственных систем.
Администратор может забыть выполнить резервирование, сохранить копию не в то место или не заметить ошибку задания.
Поэтому рекомендуется настроить автоматическое резервное копирование 1С.
При создании политики резервного копирования необходимо определить:
расписание;
тип резервной копии;
срок хранения;
место хранения;
количество точек восстановления;
уведомления;
процедуру проверки восстановления.
Расписание
Частота резервного копирования зависит от того, насколько быстро меняются данные и какую потерю данных организация может принять в случае аварии.
Одним из ключевых показателей является RPO (Recovery Point Objective) — максимально допустимый объем потерянных данных, выраженный во времени.
Например, если организация допускает потерю данных максимум за 30 минут, резервные копии или точки восстановления должны создаваться с соответствующим интервалом.
Для одной компании может быть достаточно ежедневного резервного копирования. Для другой, где данные 1С изменяются постоянно, может потребоваться резервирование каждые несколько минут.
Поэтому универсального расписания для всех систем 1С не существует.
Full Backup
Full Backup — полная резервная копия базы или защищаемого объекта.
Она содержит полный набор данных на момент создания копии и обычно используется как основа для дальнейшего восстановления.
Преимущество полного резервного копирования заключается в простоте восстановления.
Недостаток — сравнительно большой объем данных и более высокая нагрузка на систему при частом выполнении.
Поэтому в крупных системах полное резервное копирование часто комбинируется с дифференциальными и другими типами backup.
Differential Backup
Differential Backup содержит изменения, произошедшие после последней полной резервной копии.
Например:
воскресенье — Full Backup;
понедельник — Differential Backup;
вторник — Differential Backup;
среда — Differential Backup.
При восстановлении обычно используется последняя полная копия и последняя соответствующая дифференциальная копия.
Такой подход позволяет уменьшить объем данных, который необходимо сохранять при каждом запуске резервного копирования.
Transaction Log
Transaction Log Backup применяется прежде всего в средах Microsoft SQL Server.
Журнал транзакций содержит информацию об изменениях в базе данных и позволяет создавать более частые точки восстановления.
Например, если журнал резервируется каждые 15 минут, при аварии можно восстановить базу до точки, близкой к моменту сбоя, при условии корректной цепочки резервных копий.
Для систем 1С с высокой интенсивностью изменения данных это может быть важным элементом стратегии резервного копирования.
Хранение
Создание резервной копии — только часть задачи.
Необходимо также определить срок хранения копий.
Например:
ежедневные копии — 7–30 дней;
еженедельные копии — несколько месяцев;
ежемесячные копии — более длительный срок.
Конкретная политика хранения зависит от требований компании, объема данных и нормативных требований.
При этом следует контролировать объем хранилища. Если резервные копии не удаляются автоматически в соответствии с политикой хранения, пространство может быстро закончиться.
Уведомления
Система автоматического резервного копирования должна сообщать администратору о результате выполнения задания.
В частности, полезно отслеживать:
успешное завершение;
ошибку резервного копирования;
нехватку места;
недоступность хранилища;
слишком длительное выполнение задания;
ошибки при проверке или восстановлении.
Это особенно важно для критически важных серверов 1С.
Если резервное копирование перестало работать, администратор должен узнать об этом до того, как произойдет авария.
Где хранить резервные копии 1С
Резервную копию не рекомендуется хранить только на том же сервере, где находится рабочая база 1С.
Если сервер будет поврежден, украден, зашифрован ransomware или полностью недоступен, локальная резервная копия может оказаться недоступной одновременно с рабочими данными.
Локальный сервер
Хранение резервных копий на локальном сервере обеспечивает быстрый доступ к данным.
Это удобно для оперативного восстановления и может использоваться как один из уровней резервирования.
Однако такой вариант не должен быть единственной копией.
Если физически поврежден сервер или произошла атака на инфраструктуру, рабочие данные и локальные backup могут быть потеряны одновременно.
NAS
NAS может использоваться как отдельное сетевое хранилище резервных копий.
Это позволяет вынести backup за пределы основного сервера 1С и увеличить объем доступного пространства.
При использовании NAS необходимо учитывать вопросы доступа и безопасности.
Если NAS постоянно доступен из производственной сети с широкими правами, ransomware потенциально может получить доступ и к резервным копиям.
Поэтому желательно использовать дополнительные механизмы защиты и ограничивать доступ к backup-хранилищу.
Система хранения данных (СХД)
В крупных организациях резервные копии могут храниться в специализированных системах хранения данных.
Такой подход позволяет обеспечить:
большой объем хранения;
высокую производительность;
отказоустойчивость;
централизованное управление;
длительное хранение резервных копий.
Выбор конкретной СХД зависит от объема данных, требуемой скорости восстановления и бюджета.
Облачное хранилище
Облачное хранилище может использоваться для создания дополнительной удаленной копии.
Преимущество заключается в том, что backup находится за пределами локальной инфраструктуры.
При этом необходимо учитывать:
скорость интернет-соединения;
объем передаваемых данных;
стоимость хранения;
стоимость восстановления;
требования к безопасности;
требования к расположению данных.
Для больших баз 1С желательно заранее оценить время, необходимое для передачи и восстановления данных.
Удаленное и изолированное хранилище
Для критически важных систем рекомендуется иметь хотя бы одну резервную копию за пределами основной инфраструктуры.
Например:
Сервер 1С → локальное backup-хранилище → удаленное хранилище
Если в результате аварии становится недоступен весь основной дата-центр, удаленная копия может использоваться для восстановления.
Правило 3-2-1 для резервного копирования 1С
Одним из распространенных принципов организации резервного копирования является правило 3-2-1.
Оно предполагает:
как минимум 3 копии данных;
использование 2 разных типов носителей или систем хранения;
как минимум 1 копию за пределами основной инфраструктуры.
Например:
Сервер 1С
│
┌──────────┴──────────┐
↓ ↓
Локальная копия Удаленная копия
│ │
NAS ДЦ / Облако
В результате отказ одного сервера не должен приводить к потере всех копий.
Для критически важных систем можно дополнительно использовать изолированное или неизменяемое хранилище резервных копий.
Однако даже наличие нескольких копий не гарантирует возможность восстановления.
Резервные копии необходимо регулярно проверять.
Почему одной копии .dt недостаточно для защиты сервера 1С
Формат .dt может использоваться для сохранения и восстановления информационной базы 1С.
Это удобный вариант для определенных сценариев, однако .dt не является полной копией серверной среды.
Например, если сервер 1С полностью вышел из строя, после восстановления .dt может потребоваться:
установить операционную систему;
настроить сервер;
установить сервер 1С;
установить и настроить СУБД;
восстановить базу;
настроить необходимые службы;
восстановить конфигурацию;
проверить подключение пользователей.
То есть .dt помогает решить задачу восстановления информационной базы, но не обязательно решает задачу быстрого восстановления всего сервера.
Сравним два подхода:
Копия .dt | Резервная копия ВМ |
|---|
| Информационная база | Вся виртуальная машина |
| Данные 1С | Операционная система |
| Конфигурация базы | Сервер 1С |
| — | СУБД |
| — | Системные настройки |
| — | Другие компоненты сервера |
Поэтому для критически важных систем можно сочетать логическое резервное копирование базы с резервным копированием виртуальной машины.
Как защитить резервные копии 1С от ransomware
Ransomware может представлять серьезную угрозу для инфраструктуры 1С.
Если злоумышленник получает доступ к производственному серверу и backup-хранилищу, он может попытаться зашифровать или удалить не только рабочие данные, но и резервные копии.
Поэтому стратегия резервного копирования должна учитывать защиту самого backup.
Основные меры включают:
Изоляцию.
Резервное хранилище не должно иметь больше доступа к производственной инфраструктуре, чем необходимо.
Удаленное хранение.
Хотя бы одна копия должна находиться за пределами основной инфраструктуры.
Неизменяемые резервные копии.
Immutable backup позволяет защитить определенные копии от изменения или удаления в течение установленного периода.
Ограничение прав доступа.
Доступ к резервной инфраструктуре необходимо предоставлять только тем учетным записям и администраторам, которым он действительно необходим.
Регулярное тестирование восстановления.
Необходимо периодически проверять, можно ли реально восстановить данные из существующих резервных копий.
Важно понимать: резервная копия, которую невозможно восстановить, не является надежным механизмом защиты.
Как восстановить сервер 1С после сбоя
Способ восстановления зависит от того, какой объект был зарезервирован.
Восстановление базы
Если доступна только резервная копия базы данных, сначала необходимо подготовить рабочую серверную среду.
Общий процесс может выглядеть следующим образом:
Резервная копия
↓
Восстановление СУБД
↓
Восстановление базы 1С
↓
Проверка данных
↓
Запуск 1С
↓
Проверка доступа пользователей
Такой способ подходит для восстановления базы при повреждении данных или ошибках СУБД.
Однако если одновременно поврежден весь сервер, потребуется дополнительно восстановить серверную среду.
Восстановление виртуальной машины
Если заранее создавались резервные копии виртуальной машины, восстановление может быть организовано на уровне всей ВМ.
Общий сценарий:
Сбой сервера
↓
Выбор резервной копии ВМ
↓
Восстановление ВМ
↓
Запуск виртуальной машины
↓
Проверка сервера 1С
↓
Возобновление работы пользователей
Преимущество этого подхода заключается в том, что администратору не нужно каждый раз создавать сервер с нуля.
Вместо последовательной установки операционной системы, 1С Server, СУБД и дополнительных компонентов можно восстановить уже настроенную виртуальную машину.
Восстановление на другой сервер
При серьезной аппаратной неисправности исходный сервер может быть полностью недоступен.
В таком случае особенно важно иметь возможность восстановить защищенную систему на другом доступном сервере или виртуализационном хосте.
Сценарий может выглядеть следующим образом:
Исходный сервер 1С
↓
Сбой
↓
Backup Repository
↓
Другой сервер / хост
↓
Восстановление ВМ
↓
Проверка 1С
↓
Возобновление работы
Такой подход позволяет сократить время простоя и является важной частью стратегии аварийного восстановления.
Резервное копирование сервера 1С с помощью Vinchin Backup & Recovery
Если сервер 1С развернут в виртуальной инфраструктуре, резервное копирование виртуальной машины может стать дополнительным уровнем защиты наряду с резервным копированием самой базы данных.
Vinchin Backup & Recovery предназначен для централизованного резервного копирования и восстановления виртуальной инфраструктуры.
В сценарии с 1С его можно использовать для защиты виртуальных машин, в которых развернут сервер 1С, в зависимости от используемой виртуализационной платформы и конкретной архитектуры инфраструктуры.
Общая схема может выглядеть следующим образом:
Сервер 1С / ВМ
│
↓
Vinchin Backup & Recovery
│
Backup Repository
┌────┴────┐
↓ ↓
Local Remote
Backup Backup
Вместо того чтобы ограничиваться копированием отдельных файлов, организация может использовать резервное копирование виртуальной машины для защиты более полного серверного окружения.
Это особенно полезно, если 1С является критически важным приложением и простой даже на несколько часов приводит к существенным потерям для бизнеса.
В зависимости от архитектуры инфраструктуры стратегия может включать:
регулярное резервное копирование виртуальных машин;
планирование заданий по расписанию;
хранение нескольких точек восстановления;
использование отдельных backup-хранилищ;
создание удаленных копий;
восстановление виртуальной машины после сбоя.
При этом резервное копирование виртуальной машины не обязательно заменяет резервное копирование базы 1С.
Для критически важных систем целесообразно использовать несколько уровней защиты: резервное копирование базы данных, резервное копирование ВМ и отдельное хранение резервных копий.
Сравнение методов резервного копирования 1С
Разные способы резервного копирования решают разные задачи.
| Метод | Защита базы 1С | Защита всей ВМ | Автоматизация | Восстановление сервера | Подходит для аварийного восстановления |
|---|
.dt | ✓ | ✕ | Частично | ✕ | Ограниченно |
| SQL Server Backup | ✓ | ✕ | ✓ | ✕ | Частично |
| PostgreSQL Backup | ✓ | ✕ | ✓ | ✕ | Частично |
| Файловое копирование | ✓ | ✕ | ✓ | ✕ | Ограниченно |
| Резервное копирование ВМ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Платформа резервного копирования | ✓ | ✓ | ✓ | ✓ | ✓ |
Для небольшой системы может быть достаточно резервного копирования базы.
Однако для критически важной инфраструктуры 1С рекомендуется использовать многоуровневую стратегию.
Она может включать:
резервное копирование базы → резервное копирование ВМ → локальное хранилище → удаленная копия → регулярное тестирование восстановления.
FAQ
Вопросс 1：Что такое сервер резервного копирования 1С?
Ответ ：Сервер резервного копирования 1С — это отдельный сервер или система хранения, используемая для создания, хранения и восстановления резервных копий базы 1С, серверов или виртуальных машин.
Вопрос 2：Как сделать резервную копию сервера 1С?
Ответ ：Способ зависит от архитектуры системы. Можно создавать резервные копии базы 1С, использовать механизмы Microsoft SQL Server или PostgreSQL либо выполнять резервное копирование всей виртуальной машины, в которой работает сервер 1С.
Вопрос 3：Как настроить автоматическое резервное копирование 1С?
Ответ ：Необходимо определить расписание, тип резервных копий, срок хранения, место хранения и правила уведомления. Для критически важных систем также следует предусмотреть удаленную копию и регулярное тестирование восстановления.
Вопрос 4：Где хранить резервные копии 1С?
Ответ ：Не рекомендуется хранить единственную копию на том же сервере, где работает 1С. Можно использовать NAS, отдельный backup-сервер, систему хранения данных, облачное или удаленное хранилище.
Заключение
Для критически важных систем недостаточно просто создать одну резервную копию базы.
Надежная стратегия должна учитывать весь жизненный цикл данных:
создание резервной копии → безопасное хранение → удаленная копия → защита от изменения и удаления → регулярная проверка → быстрое восстановление.
Если сервер 1С работает в виртуальной инфраструктуре, резервное копирование виртуальных машин позволяет дополнительно защитить операционную систему, сервер 1С, СУБД и другие компоненты рабочей среды.
Vinchin Backup & Recovery может использоваться как часть такой стратегии для централизованного резервного копирования и восстановления виртуальной инфраструктуры.
Главная цель резервного копирования — не просто иметь копию данных, а обеспечить возможность быстро восстановить работу 1С после сбоя.
