У каждого второго клиента, приходящего к нам на поддержку, бэкап «настроен». У каждого четвёртого он при этом не восстанавливается. Разница между этими состояниями обнаруживается ровно один раз — в тот день, когда база нужна обратно. Разберём, какие уровни копирования бывают, что из них чего стоит и как за час проверить, что у вас на самом деле.
Резервное копирование баз 1С: что реально восстанавливается, а что только выглядит бэкапом
Три уровня, и они не заменяют друг друга
Копирование базы 1С делается на трёх разных уровнях, и путаница между ними — источник ложного спокойствия.
Уровень СУБД. Полный бэкап базы плюс бэкапы журнала транзакций. Это основной инструмент. Восстанавливает базу целиком на любой момент времени, если журнал пишется в режиме FULL. Быстро, надёжно, не требует останова.
Уровень платформы. Выгрузка в файл .dt средствами конфигуратора. Медленно, требует монопольного доступа, на базе за 100 ГБ может идти часами. Зато файл переносится между разными СУБД и разными версиями платформы. Это инструмент переезда, а не ежедневного бэкапа.
Уровень инфраструктуры. Снимок или бэкап всей виртуальной машины. Восстанавливает сервер целиком вместе с настройками кластера, публикациями и лицензиями. Незаменим при отказе железа, бесполезен при логической ошибке в данных.
Каждый уровень закрывает свой класс аварий. Удалили документы задним числом — нужен уровень СУБД с точкой восстановления. Умер хост виртуализации — нужен уровень инфраструктуры. Переезжаете с MS SQL на PostgreSQL — нужен .dt.
Схема, которую мы считаем минимально достаточной для офиса до 50 мест: полный бэкап СУБД ежедневно, журнал транзакций каждые 15–30 минут, бэкап ВМ раз в неделю, выгрузка .dt раз в месяц в архив. Плюс копия за пределами площадки.
Почему .dt — плохой ежедневный бэкап
Выгрузка в .dt популярна, потому что понятна: один файл, положил в папку, спокоен. Проблем с ней четыре.
Первая: требуется монопольный доступ. Значит, выгонять пользователей. На практике это означает ночь и невозможность сделать копию среди дня перед рискованной операцией.
Вторая: время. База на 80 ГБ выгружается в .dt сорок минут — час, загружается обратно два-три часа. Бэкап СУБД той же базы делается за 6–8 минут, восстанавливается за 12–20.
Третья: .dt не умеет в точку восстановления. Он даёт состояние на момент выгрузки, и всё. Ошибку, найденную в среду, вы откатите на состояние ночи вторника, потеряв рабочий день целиком.
Четвёртая, самая коварная: выгрузка может пройти успешно, а загрузка — упасть. Формат .dt не содержит контрольных сумм, которые проверялись бы при выгрузке. Битую выгрузку вы обнаружите только при попытке загрузить.
Где .dt действительно нужен: переезд между СУБД, передача базы разработчику, архивная копия перед крупным обновлением, долгосрочное хранение состояния на конец года. Для этих задач он идеален. Для ежедневного бэкапа — нет.
Модель восстановления и журнал транзакций
Ключевая настройка на стороне MS SQL, которую половина инсталляций оставляет неправильной.
Модель SIMPLE означает, что журнал транзакций не сохраняется. Восстановиться можно только на момент полного бэкапа. Потеряли базу в 17:00, последний бэкап был в 01:00 — потеряли весь рабочий день.
Модель FULL плюс регулярный бэкап журнала даёт восстановление на любую минуту. Потеряли базу в 17:00, журнал бэкапится каждые 15 минут — потеряли максимум 15 минут работы.
ALTER DATABASE [buh_prod] SET RECOVERY FULL;
-- и обязательно расписание бэкапа журнала, иначе лог вырастет до размера диска
BACKUP LOG [buh_prod] TO DISK = 'E:\backup\buh_prod_log.trn' WITH COMPRESSION;Вторая строка — не опциональна. Переключить базу в FULL и не настроить бэкап журнала — прямой путь к переполнению диска: журнал не усекается, пока его не забэкапят, и растёт бесконечно. Мы регулярно приходим к клиентам, где база 40 ГБ, а её лог — 300 ГБ.
Проверить текущее состояние:
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases WHERE name NOT IN ('master','model','msdb','tempdb');Колонка log_reuse_wait_desc со значением LOG_BACKUP — прямое указание: журнал ждёт бэкапа и до тех пор не освободится.
RPO и RTO: два числа, которые надо согласовать с бизнесом
Это не абстракция из учебника, а два вопроса, ответы на которые определяют всю схему.
RPO — сколько данных допустимо потерять. Час работы бухгалтерии? Пятнадцать минут? День? Ответ даёт не администратор, а руководитель. От него зависит частота бэкапа журнала.
RTO — сколько времени допустимо лежать. Час? Четыре часа? Сутки? От этого зависит, нужен ли горячий резерв, или достаточно восстановления из файла.
Разговор с клиентом мы строим просто: «Сколько стоит для вас день простоя учёта?» Цифры обычно называют легко. Дальше становится понятно, что имеет смысл, а что избыточно.
| Профиль | RPO | RTO | Схема |
|---|---|---|---|
| Бухгалтерия, 20 мест | 1 час | 4 часа | полный ночью + лог раз в час |
| Торговля с розницей | 15 мин | 1 час | полный ночью + лог 15 мин + резервный сервер |
| Производство, сменная работа | 15 мин | 30 мин | то же + Always On или репликация ВМ |
Обратите внимание: жёсткий RTO стоит денег, жёсткий RPO — почти нет. Уменьшить окно потери данных с часа до пятнадцати минут — это поменять расписание задания. Уменьшить время простоя с четырёх часов до тридцати минут — это второй сервер и репликация.
Правило 3-2-1 и что с ним не так на практике
Классика: три копии, на двух разных носителях, одна вне площадки. Спорить с формулой смысла нет, но её применение в малом офисе имеет особенности.
«Три копии» часто вырождаются в три файла на одном RAID-массиве. Формально три, фактически одна точка отказа. Мы это видим постоянно: бэкапы лежат на диске E: того же сервера, где база на диске D:. Умер контроллер — умерло всё.
«Два носителя» в реальности означает: локальный диск плюс NAS, либо локальный диск плюс внешний USB. Оба варианта рабочие. Важно, чтобы второй носитель не был примонтирован постоянно с правом записи от той же учётки — иначе шифровальщик доберётся и до него. Мы предпочитаем pull-модель: NAS сам забирает бэкапы по расписанию, сервер к нему не имеет доступа на запись.
«Одна вне площадки» — самый пропускаемый пункт и самый важный. Пожар, залив, кража, шифровальщик с правами домена — всё это выносит площадку целиком. Внешняя копия может быть облачным хранилищем, вторым офисом или просто диском, который раз в неделю увозят.
Отдельно про шифровальщиков. Бэкап, доступный на запись из-под доменной учётной записи с сервера, — это не бэкап, а вторая жертва. Иммутабельное хранилище или хотя бы отдельные учётные данные, не совпадающие с доменными, снимают этот класс аварий полностью.
Проверка восстановлением: единственный критерий
Формулировка простая: бэкап, который ни разу не разворачивали, бэкапом не является. Это утверждение, а не фигура речи.
Что мы делаем ежемесячно у клиентов на поддержке:
- Берём случайный бэкап за последние 30 дней, не самый свежий.
- Восстанавливаем на тестовый сервер под именем вида
buh_restoretest. - Запускаем базу, отключая работу с внешними ресурсами.
- Проверяем: заходит ли пользователь, открывается ли последний документ, формируется ли ОСВ.
- Засекаем время всей процедуры — это ваш реальный RTO.
- Записываем результат в журнал с датой.
Пятый пункт даёт неприятные открытия. У клиента с базой 120 ГБ на плане значился RTO четыре часа; фактическая проверка показала семь с половиной, потому что бэкап лежал на NAS с гигабитным каналом и одно только копирование заняло два часа. Исправили переносом свежих копий на локальный SSD, оставив на NAS архив.
Автоматизировать проверку можно скриптом: восстановить, выполнить контрольный запрос, отчитаться в мониторинг. Но раз в квартал стоит сделать полный прогон руками — автоматика проверяет то, что ей сказали, а человек замечает, что дистрибутив платформы нужной версии на тестовом сервере отсутствует.
Что ещё бэкапить кроме базы
Восстановление базы — это половина возврата к работе. Вторая половина обычно всплывает уже в процессе.
- Каталог кластера
srvinfo— в нём список информационных баз и данные сеансов. Без него базу придётся регистрировать в кластере заново. - Файлы лицензий из
C:\ProgramData\1C\licenses. - Каталог публикации с
default.vrd, если база публикуется. - Внешние обработки и печатные формы, если они лежат в файловой системе, а не в базе.
- Правила обмена и настройки интеграций.
- Дистрибутив платформы той версии, на которой работает база. Скачать старую версию с портала можно, но не в момент аварии.
- Сертификаты ЭЦП и настройки криптопровайдера.
Последний пункт стоит комментария. Восстановленная база на новом сервере без сертификатов не отправит ни одного отчёта. Контейнеры закрытых ключей копируются отдельно, и это отдельная процедура, которую надо проверять отдельно.
Мы держим для каждого клиента короткий документ «Что нужно для восстановления учёта с нуля» на одну страницу: список файлов, где лежат, кто владеет паролями, в каком порядке разворачивать. Когда авария случается, этот лист экономит первые два часа — те самые, в которые обычно ищут, у кого пароль от NAS.
Бэкап PostgreSQL для 1С и PITR через WAL
Если СУБД для 1С — PostgreSQL, применяются штатные инструменты: pg_dump в custom-формате с компрессией и ротацией старых дампов.
DATABASES=$(psql -U postgres -t -c "SELECT datname FROM pg_database WHERE datname NOT IN ('postgres','template0','template1');")
for DB in $DATABASES; do
pg_dump -U postgres -Fc -j 4 -f "/backup/postgresql/${DB}_$(date +%Y%m%d_%H%M).dump" "$DB"
done
# Ротация: удаление старше 14 дней
find /backup/postgresql -name "*.dump" -mtime +14 -deleteДля восстановления на произвольный момент времени (PITR) нужно WAL-архивирование — в postgresql.conf: wal_level = replica, archive_mode = on, archive_command = 'cp %p /backup/postgresql/wal/%f'. Без этого PostgreSQL-база восстанавливается только на момент последнего pg_dump, а не на произвольную минуту, как MS SQL с журналом транзакций.
VSS-бэкап файловой базы без отключения пользователей
Volume Shadow Copy позволяет снять бэкап файловой базы 1С (1Cv8.1CD), не отключая пользователей — обычное копирование занятого файла базы либо невозможно, либо портит данные.
# Создание теневой копии тома
$shadow = (Get-WmiObject -List Win32_ShadowCopy).Create("D:\", "ClientAccessible")
$shadowObj = Get-WmiObject Win32_ShadowCopy | Sort-Object InstallDate | Select-Object -Last 1
# Монтирование теневой копии и копирование файла базы
cmd /c mklink /d "C:\shadow_mount" "$($shadowObj.DeviceObject)\"
Copy-Item "C:\shadow_mount\1C_Bases\Accounting\1Cv8.1CD" $backupDir
cmd /c rmdir "C:\shadow_mount"
# Удаление теневой копии
$shadowObj.Delete()Частые вопросы
Достаточно ли ежедневной выгрузки в dt?
Для ежедневного бэкапа — нет. Она требует монопольного доступа, идёт часами на крупных базах и не даёт восстановления на точку времени: потеряете весь день до момента выгрузки. Основной бэкап делается средствами СУБД, а dt остаётся для переездов и архива.
Зачем бэкапить журнал транзакций, если есть полный бэкап?
Полный бэкап даёт состояние на момент своего создания. Бэкап журнала позволяет докатить базу до любой минуты после него — это разница между потерей рабочего дня и потерей пятнадцати минут. Плюс без бэкапа журнала он не усекается и растёт до размера диска.
Как часто проверять бэкапы восстановлением?
Раз в месяц — выборочное восстановление на тестовый сервер, раз в квартал — полный прогон руками с замером времени. Замер важен: фактический RTO почти всегда больше планового, и узнавать об этом лучше не в день аварии.
Спасёт ли бэкап от шифровальщика?
Только если он недоступен на запись с заражённого сервера. Копии на подключённом сетевом диске под доменной учёткой шифруются вместе с базой. Нужны либо иммутабельное хранилище, либо pull-модель, когда хранилище само забирает данные, а сервер к нему писать не может.
#1С#бэкап#восстановление#риски#регламент
Читайте также: резервное копирование 1С для малого бизнеса: что, куда и как часто копировать.
Оставить комментарий