Бэкап 1С: как настроить файловая/SQL, как часто, куда хранить, как проверять
Бэкап 1С обычно вспоминают в момент, когда уже поздно играть в “может, само пройдет”.
Типичная сцена: база не открывается, бухгалтер держится из последних сил, а кто-то говорит сакральное: “Да у нас же есть копия… где-то”.
И вот тут начинается лотерея.
Потому что “копия есть” и “копия спасает” это две разные вселенные.
Я видел ситуации, когда бэкап реально вытаскивал компанию за 15 минут. И видел, когда бэкапов было “целая папка за год”, но ни один не восстанавливался. Ощущение примерно как открыть шкаф с парашютами и понять, что они нарисованы.
Давай сделаем так, чтобы у тебя был бэкап, который не просто лежит, а работает.
1) От чего бэкап спасает на самом деле
Не только от “сгорел сервер”. Это редкость.
Чаще прилетает что-то бытовое и гадкое:
свет моргнул, база стала “формат потока”
диск тихо умирает, но делает вид, что он бодрячком
шифровальщик или “случайно удалили папку”
обновились и внезапно нужно откатиться
кто-то провел массовую обработку и понял, что зря… через 10 дней
Самое важное: бэкап должен позволять вернуться назад не в теории, а руками. Быстро. Без танцев.
2) Файловая база (1Cv8.1CD): как делать правильно и не попасть в ловушку
Файловая база это когда у вас есть конкретный файл 1Cv8.1CD. Часто он лежит на сетевой папке, и все ходят туда “как в холодильник”.
Главная ловушка: копировать базу, пока люди в ней работают.
Выглядит невинно: “мы же просто копируем файл”.
По факту это как переписывать книгу, пока кто-то вырывает страницы и вставляет новые. Иногда повезет. Иногда копия получится битой, и вы узнаете об этом в самый плохой день.
Что делать нормально:
Способ 1. Выгрузка в dt
Это самый понятный “честный” вариант.
делается из Конфигуратора
получаете файл .dt, который потом можно развернуть обратно
Минус один: на больших базах это может занять время.
Но это лучше, чем часами потом расковыривать повреждения.
Способ 2. Копия 1Cv8.1CD, но только когда все вышли
Работает. И часто быстрее, чем dt.
Правила простые, как табличка “не прислоняться”:
все пользователи вышли
база не открыта ни у кого
вы копируете файл, а не “папку на глаз”
Если база на сетевой шаре и пользователей много, я обычно сразу говорю честно: это временное решение. Не “плохо”, просто рано или поздно сеть моргнет, и файл словит приключения.
3) SQL база: что считается настоящим бэкапом
Если у вас клиент-сервер, база живет на SQL.
Тут бэкап это SQL backup (полный/дифференциальный/логи, если вы их используете). Не “скопировали папку” и не “снапшот виртуалки иногда”.
Снапшоты иногда помогают, но в день, когда все горит, хочется опираться на штуку, которая:
делается по расписанию
хранится нормально
проверена восстановлением
Потому что SQL умеет быть капризным, если цепочка логов рвется, если место кончилось, если бэкап “успешен”, но внутри сюрприз. Да, бывает и так.
4) Как часто делать бэкап: вопрос не про “как надо”, а про “сколько готовы потерять”
Самый честный вопрос звучит так:
Если база умрет, сколько времени работы вы готовы выкинуть?
готовы потерять день? делайте раз в сутки
готовы потерять 3–4 часа? делайте 2–4 раза в сутки
готовы потерять максимум час? делайте каждый час (или логи транзакций в SQL)
Кейс из практики, который вспоминается без смеха: склад + продажи, документы летят каждые 5–10 минут. Бэкап был раз в сутки. В день сбоя потеряли почти весь рабочий день и потом пытались “вспомнить по чекам”. После этого поставили бэкап раз в 2 часа. Потери стали измеряться не “катастрофой”, а “ну неприятно, но переживем”.
Хорошая рабочая схема для многих:
полный бэкап ночью
еще один-два днем (по ситуации)
отдельная точка перед опасными действиями: обновление, массовая обработка, миграции
5) Куда хранить: бэкап рядом с базой это как второй ключ под ковриком
Если бэкап лежит на том же сервере, где база, это не “защита”. Это “копия для успокоения”.
Нормальная логика простая:
одна копия рядом (быстро восстановиться)
вторая копия в другом месте (если сервер умер/украли/зашифровали)
В идеале:
локально (сервер/NAS)
плюс облако или удаленная площадка
И важный нюанс, который многие пропускают: доступы.
Если шифровальщик попал в сеть и имеет права на NAS, он зашифрует и базу, и бэкапы. Двойной удар.
Минимально разумно:
учетная запись для бэкапа пишет в папку
у обычных пользователей туда нет прав
чтение только у 1–2 админов
6) Проверка бэкапа: та самая часть, которую откладывают “на потом”
Вот правда жизни: наличие файла бэкапа ничего не гарантирует.
Гарантирует только восстановление.
Как проверять без боли:
раз в неделю (или раз в две недели, если совсем тяжело)
восстановить копию в тестовую базу
зайти
открыть пару важных мест: документ, список, отчет
Это занимает 10–30 минут.
Зато в день Х вы не будете выяснять, что “оно не открывается”.
Самая грустная история, которую я видел несколько раз: компания копировала папку базы “как придется”, бэкапы копились месяцами. В день аварии выяснилось, что половина из них битая. И тут уже не “настроить бэкап”, тут уже “как не потерять учет”.
7) Сколько хранить бэкапы: лестница вместо свалки
Хранить “вечно” обычно бессмысленно, а хранить “3 дня” рискованно.
Рабочая схема:
ежедневные: 7–14 дней
еженедельные: 4–8 недель
ежемесячные: 6–12 месяцев (если нужно)
Почему так: ошибки часто замечают не сразу.
Сегодня “все ок”, через 9 дней внезапно “а почему справочник стал странный”. И если у вас есть точка назад, вы спасли себе кучу времени.
8) Отдельное правило: бэкап перед обновлением
Перед обновлением бэкап обязателен. Всегда.
Идеальная последовательность выглядит так:
сделали бэкап
(в идеале) убедились, что он восстанавливается хотя бы периодически
обновили на тестовой копии
обновили боевую
проверили ключевые сценарии
Обновление без бэкапа это как прыжок в воду в незнакомом месте. Может быть мелко, а может быть бетон.
9) Короткий чек-лист “чтобы уже сегодня стало лучше”