Резервное копирование для 1С

Типовое решение для резервного копирования и восстановления баз данных 1С:Предприятие, работающих на PostgreSQL-подобных СУБД, с применением Platform V CopyWala.

Контекст

1С:Предприятие — одна из наиболее широко применяемых платформ для автоматизации бизнес-процессов в организации. Хранение данных 1С:Предприятие требует надежного резервного копирования для обеспечения безопасности и доступности бизнес-данных.

Организации, использующие 1С:Предприятие, сталкиваются с необходимостью:

• Обеспечения регулярного резервного копирования баз данных 1С с минимальным влиянием на работу пользователей.
• Быстрого восстановления данных в случае сбоев, ошибок или потери данных.
• Извлечения конкретных баз данных 1С из общих резервных копий кластера СУБД.
• Переноса данных между различными средами (промышленной, тестовой, разработки).
• Тестирования обновлений конфигураций 1С на актуальных копиях данных.

Platform V CopyWala предоставляет комплексное решение для резервного копирования баз данных 1С:Предприятие. Продукт поддерживает создание полных и инкрементальных резервных копий, архивирование WAL-сегментов для Point-in-Time Recovery (PITR), а также использование драйвера FUSE для быстрого доступа к данным без полного восстановления.

Проблема

Рассматривается решение следующих проблем:

• Отсутствие быстрого доступа к отдельным базам 1С из резервной копии: Стандартное восстановление полного кластера СУБД требует значительного времени и ресурсов, даже если необходимо извлечь только одну базу данных 1С для тестирования или анализа.
• Сложность переноса данных между средами: Перенос актуальных данных 1С из промышленной среды в среду разработки или тестирования часто требует создания полных копий, что замедляет процесс разработки и тестирования.
• Длительное время восстановления при инцидентах: При необходимости восстановления базы 1С после сбоя или ошибки стандартные инструменты не всегда обеспечивают приемлемое время восстановления (RTO).
• Необходимость тестирования обновлений 1С на реальных данных: Тестирование обновлений конфигураций 1С:Предприятие требует доступа к актуальным данным без риска повреждения промышленной базы.
• Аудит и диагностика: Диагностика проблем или аудит данных на определенный момент времени требует временного восстановления, которое может быть ресурсозатратным.

Решение

Возможно использование одного из подходов:

• стандартный подход PostgreSQL через pg_dump / pg_restore;
• быстрый доступ к базам данных внутри резервной копии с использованием драйвера FUSE Platform V CopyWala без полного восстановления кластера;
• частичное восстановление с помощью флагов --db-exclude и --db-include для выборочного восстановления указанных баз данных из резервной копии;

Стандартный подход через pg_dump / pg_restore

Стандартный подход основан на использовании утилит pg_dump и pg_restore для логического резервного копирования и восстановления баз данных 1С.

Процесс выглядит следующим образом:

1. Выполняется создание дампа базы данных (пример команды):

   pg_dump -U postgres -d <database_name> -F c -f database.backup

2. Дамп переносится на целевой сервер.

3. Выполняется восстановление (пример команды):

   pg_restore -U postgres -d <database_name> database.backup

Такой подход подходит для регулярного переноса отдельных баз данных, но имеет ограничения:

• необходимо заранее создать дамп каждой базы;
• для извлечения одной базы из резервной копии всего кластера требуется дополнительная подготовка;
• восстановление большого объема данных требует времени;
• невозможно быстро получить доступ к состоянию базы на определенный момент времени без предварительного восстановления.

Возможность быстрого восстановления баз данных (используя драйвер fuse)

Данный подход позволяет извлекать отдельные базы данных 1С из резервной копии без полного восстановления всего PostgreSQL-кластера, что существенно сокращает время восстановления и снижает потребление ресурсов.

Ключевым элементом является драйвер fuse (Filesystem in Userspace), который обеспечивает монтирование резервной копии как виртуальной файловой системы. После монтирования архив становится доступен в виде обычного каталога, структура которого соответствует каталогу данных PostgreSQL (PGDATA).

:align: center :::

Команда copywala fuse использует механизм fuse для создания такого виртуального представления резервной копии. Операционная система и инструменты PostgreSQL работают с ним так же, как с локальной файловой системой, при этом фактические данные остаются внутри архива резервной копии.

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

Шаг 1. Получение списка резервных копий

Для получения списка резервных копий, доступных для восстановления, используйте команду:

copywala backups history

Справка по команде copywala backups history

Описание:

Выводит информацию о созданных резервных копиях.

Синтаксис:

copywala backups history [flags]

Обязательные параметры:

Нет.

Опциональные параметры:

[flags] – доступны следующие флаги:

Флаг	Описание
-h|--help	Показать справку по команде
-c|--config <path to copywala config>	Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala.yaml
--detail	Вывод информации о резервных копиях в более подробном виде

В результате выполнения команды будет выведена информация о резервных копиях:

copywala backups history
+----------------------+------------+---------------+-----------------------+---------------------+
| ID                   | HOSTNAME   | LOCATION URI  | INVENTORY STATUS      | INVENTORY TIME      |
+----------------------+------------+---------------+-----------------------+---------------------+
| <Идентификатор РК_1> | <HOSTNAME> |     <URI>     |        success        | 2026-02-04 09:44:50 |
| <Идентификатор РК_2> | <HOSTNAME> |     <URI>     |        failed         | 2026-02-04 09:44:56 |
| <Идентификатор РК_3> | <HOSTNAME> |     <URI>     |        success        | 2026-02-04 09:45:01 |
+----------------------+------------+---------------+-----------------------+---------------------+

Поле	Описание	Пример значения
ID	Уникальный идентификатор РК	019715e5-a1ec-70c4-9a31-753362d26f75
HOSTNAME	Имя хоста агентского приложения, на котором был запущен процесс создания РК	srv-48-53
LOCATION URI	Полный путь к РК: тип хранилища, хост, путь, имя файла	s2://srv-48-53:29500/2025-05-28-10-57_019715e5-a1ec-70c4-9a31-753362d26f75_full_0000000100000018000000A7.cwl
INVENTORY STATUS	Статус РК по результату инвентаризации	- success – успешная инвентаризация РК; - failed – инвентаризация неуспешна (например, возникновение ошибки с файлами РК)
INVENTORY TIME	Время выполнения инвентаризации для данной РК	2026-04-03 22:05:11

Шаг 2. Восстановление отдельной базы данных из кластерной резервной копии

Для восстановления конкретной (отдельной) базы данных 1С из резервной копии используется технология гранулярного восстановления с помощью copywala fuse и pg_dump:

1. Остановите текущий кластер:

   pg_ctl stop

2. Создайте директорию для монтирования CWL-архива:

   mkdir /path/to/cwl_archive_mount_point

3. Смонтируйте архив резервной копии:

   copywala fuse /path/to/mount_point <archive-uri-or-path>

   Справка по команде copywala fuse

   Описание:

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

   Синтаксис:

       
   copywala fuse <mount directory> <archive uri or path> [flags]

   Обязательные параметры:

   • <mount directory> – каталог, в который монтируется архив, и через который его содержимое становится доступным как файловая система.
   • <archive uri or path> – путь к CWL-архиву резервной копии из которой требуется восстановить данные.

   примечание

   Если в команде используется URI, указывающий подключение к DDBoost через S2, его необходимо обязательно заключать в двойные кавычки.

   Это требование связано с тем, что URI содержит символ &, который интерпретируется Bash как оператор фонового запуска команды.

   Ниже приведен пример для команды copywala cwl info:

       
   copywala cwl info "s2://<s2-host>/<ddboost-storage-unit>/path/in/ddboost/storage/unit?driver=ddboost&data_domain_host=<ddboost-host>"

   Опциональные параметры:

   [flags] – доступны следующие флаги:

   Флаг	Описание
   -h|--help	Показать справку по команде
   -c|--config <path to copywala config>	Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala.yaml
   --cache-dir <path/to/cache/dir>	Директория на диске, в которую переносятся данные из оперативной памяти при превышении значения cache-swap-size. Значение по умолчанию — /tmp.
   --cache-swap-size	Размер данных, выгружаемых из архива CWL и хранимых в оперативной памяти. При превышении указанного объема данные, находящиеся в памяти, выгружаются на диск в директорию, указанную в параметре cache-dir. По окончании работы временные данные автоматически удаляются (по умолчанию – 256 МБ)

4. Запустите PostgreSQL на смонтированном каталоге:

   pg_ctl start -D /path/to/mount_point

5. Получите список баз данных в смонтированном кластере:

   psql -U postgres -c "\l"

6. Создайте логический дамп нужной базы данных 1С:

   pg_dump -U postgres -d <имя_базы_1с> -F c -f backup_1c.backup

7. Восстановите базу данных на целевом сервере:

   pg_restore -U postgres -d <имя_базы_1с> backup_1c.backup

8. Завершите работу с FUSE:

   pg_ctl stop -D /path/to/mount_point

   Завершите выполнение команды copywala fuse в терминале.

Дополнительные сценарии использования FUSE

Сценарий	Описание
Диагностика проблем	Быстрый доступ к данным из резервной копии для анализа причин ошибок без полного восстановления
Аудит данных	Проверка состояния данных на определенный момент времени
Миграция между кластерами	Перенос отдельных баз 1С между кластерами PostgreSQL
Тестирование обновлений 1С	Создание тестовых копий баз для проверки обновлений 1С:Предприятие

Частичное восстановление с помощью флагов --db-exclude и --db-include

к сведению

Данный подход позволяет осуществлять восстановление только необходимых баз данных из резервной копии без необходимости полного распаковывания всех данных. В команду copywala restore добавлена поддержка флагов --db-exclude и --db-include, которые позволяют включать или исключать указанные базы данных из процесса восстановления.

Принцип работы

При выполнении частичного восстановления из резервной копии:

• Флаг --db-exclude — исключает указанные базы данных из восстановления. Все остальные базы данных из резервной копии будут восстановлены.
• Флаг --db-include — восстанавливает только указанные базы данных. Все остальные базы данных из резервной копии будут исключены из восстановления.

Передача обоих флагов в одну команду restore невозможна в связи с их взаимоисключающим поведением.

Все файлы исключенных из распаковки баз данных восстанавливаются с нулевым размером, чтобы при запуске сервера и воспроизведении WAL-журналов минимизировать вероятность ошибки.

Шаблонные базы данных template0 и template1 всегда восстанавливаются и не могут быть исключены из распаковки.

При распаковке CWL-архива проверяется наличие в ней переданных в качестве параметров баз данных и выводится ошибка, если указанная база данных не найдена в резервной копии.

Пример использования

Предположим, в экземпляре PostgreSQL существуют базы данных: db1, db2, db3, db4, postgres, template0, template1.

Исключение указанных баз данных из восстановления:

copywala restore latest --db-exclude=db1 --db-exclude=db2 --destination=/pgdata/restored

В папку назначения будут восстановлены: db3, db4, postgres, template0, template1 (базы данных db1 и db2 будут исключены).

Восстановление только указанных баз данных:

copywala restore latest --db-include=db1 --db-include=db2 --destination=/pgdata/restored

В папку назначения будут восстановлены: db1, db2, template0, template1 (базы данных db3, db4 и postgres будут исключены).

Post-восстановление

После запуска сервера рекомендуется исключенные из восстановления базы данных удалить с помощью команд SQL:

DROP DATABASE db1;
DROP DATABASE db2;

Это предотвратит возможные ошибки при работе с пустыми файлами исключенных баз данных.

Сценарии использования частичного восстановления

Сценарий	Описание
Восстановление конкретных баз 1С из общей РК	Быстрое восстановление необходимых баз 1С без затрачивания времени на распаковку лишних данных
Развертывание тестовой среды	Восстановление только тех баз 1С, которые требуются для тестирования, из полной резервной копии промышленного кластера
Экономия места на диске	Исключение неиспользуемых баз данных при восстановлении для снижения требований к дисковому пространству
Ускорение процесса восстановления	Сокращение времени восстановления за счет пропуска ненужных баз данных