Резервное копирование 1С: как не потерять базу бухгалтерии

Каждый год ко мне приходят компании с одной и той же историей. Жёсткий диск умер. Сервер сгорел. Сотрудник удалил базу — и выясняется, что последний рабочий бэкап был три месяца назад. Или его вообще не существовало. За 12 лет в IT-аутсорсинге я видел это десятки раз, и каждый раз одно и то же выражение лица у директора. Поэтому — никакой теории. Только конкретные схемы резервного копирования 1С, цифры и то, что реально работает.

Почему бэкап 1С — это отдельная история

1С — это не просто файлик на сервере. Там первичка за несколько лет, зарплаты, налоговая отчётность, взаиморасчёты с контрагентами. База ломается в момент сдачи квартального отчёта — и начинается катастрофа: штрафы от ФНС, срыв платёжек, паника в бухгалтерии. Не преувеличиваю.

Был у нас один клиент — торговая компания, 15 человек. Их системный администратор решил, что ежедневный бэкап — лишняя работа. Настроил копирование раз в неделю. И на ту же машину, где жила сама база. Потом поехал жёсткий диск. Итог: база недельной давности, куча незакрытых отгрузок и две недели ручного восстановления данных. Считайте сами, во что это обошлось.

У 1С есть важная особенность, о которой часто забывают. База бывает двух типов: файловая или серверная — на Microsoft SQL Server или PostgreSQL. Это принципиально разные вещи. Файловую копировать можно стандартными средствами Windows. С серверной так не получится — SQL держит файлы базы открытыми постоянно, и если просто скопировать их, получите повреждённый мусор вместо рабочего бэкапа. Об этом дальше — подробно.

Файловая или серверная база: от этого зависит всё

Файловый вариант 1С — это когда база лежит папкой с файлом 1Cv8.1CD на сетевом диске или прямо на компьютере бухгалтера. Так чаще всего работают компании до 5–7 пользователей. Технически скопировать несложно. Но есть одна ловушка.

Копировать файловую базу на лету, пока в ней кто-то работает, — плохая идея. Получите повреждённую копию, которая не откроется в нужный момент. Правильный путь — делать резервную копию через встроенную выгрузку 1С в файл с расширением dt. Это легко автоматизируется через Планировщик Windows: скрипт запускается ночью, когда в базе никого нет, и утром свежий бэкап уже готов. Бесплатно, просто, работает.

Серверный вариант — это 1С в режиме клиент-сервер, база живёт на SQL. Здесь копировать нужно средствами СУБД: SQL Server Agent для Microsoft SQL, pg_dump для PostgreSQL. Либо — выгрузка через конфигуратор 1С. Оба варианта рабочие, у каждого свои плюсы и ограничения. Главное — сначала понять, какой тип базы у вас. И только потом выстраивать схему бэкапа.

Куда копировать: три места хранения и одна распространённая ошибка

Золотое правило резервного копирования — схема 3-2-1. Три копии данных, на двух разных типах носителей, одна — вне офиса. Звучит просто. На практике большинство небольших компаний не выполняют даже первый пункт: хранят бэкап на том же диске, что и сама база. Это не бэкап. Это самообман.

Первое место хранения — отдельное локальное сетевое хранилище. Недорогой NAS типа Synology DS223 стоит около 18–22 тысяч рублей. Два жёстких диска по 2 ТБ — ещё 8–10 тысяч. Итого за 30 тысяч рублей у вас нормальное сетевое хранилище с RAID-зеркалом, которое переживёт смерть одного диска без потери данных. Это минимум. Не экономьте.

Второе место — облако. Яндекс Диск, S3-совместимые хранилища Selectel или VK Cloud. На нашей практике лучше всего работает S3 с включённым версионированием — можно откатиться к любой версии файла за последние 30 дней. Стоит смешные деньги: 50 ГБ — порядка 100–200 рублей в месяц. Третье место — физический носитель вне офиса. Внешний диск, который раз в неделю забирает домой директор или главбух. Звучит старомодно, согласен. Но именно это спасает при пожаре или затоплении серверной.

Как часто делать резервные копии

Универсального ответа здесь нет — всё зависит от того, сколько данных вы готовы потерять. В профессиональной среде это называется RPO, Recovery Point Objective — допустимая глубина потери. Если через вашу 1С за день проходит 300 накладных и 50 платёжных поручений, потеря даже одного дня критична. Если небольшая юрфирма вносит данные раз в неделю — совсем другой разговор.

Для большинства клиентов из торговли, бухгалтерии и производства мы рекомендуем такую схему: полный бэкап раз в сутки — ночью, когда база свободна. Если 1С работает в серверном режиме на SQL — дополнительно настраиваем резервные копии журнала транзакций каждые 2–4 часа в рабочее время. Это позволяет откатиться почти до любого момента дня, а не только до вчерашней ночи.

Хранить бэкапы вечно незачем. Достаточно классической схемы ротации GFS — Grandfather-Father-Son: ежедневные копии за последние 14 дней, еженедельные — за 2 месяца, ежемесячные — за год. Настраивается один раз и потом работает сама. Занимает разумный объём дискового пространства и покрывает все типичные сценарии восстановления.

Как настроить автоматический бэкап 1С

Три инструмента, которые реально работают в малом бизнесе. Первый — встроенный Планировщик Windows и PowerShell-скрипт. Создаёте задание: ночью скрипт запускает выгрузку базы 1С в файл dt, затем копирует его на NAS и в облако. Бесплатно, работает. Минус один — выгрузка в dt временно блокирует базу, и для больших баз это может быть неудобно.

Второй инструмент — SQL Server Agent, если у вас Microsoft SQL Server. Заходите в SQL Server Management Studio, создаёте план обслуживания с заданием резервного копирования. Выбираете тип: полный бэкап, разностный или копия журнала транзакций. Настраиваете расписание. Отдельным заданием копируете файлы .bak на NAS или в облако. Стандартный промышленный подход — надёжный и гибкий.

Третий вариант — Veeam Agent for Windows. Работает прямо с живой машины через VSS-снапшоты, SQL-базы понимает без остановки. Лицензия — от 8000 рублей в год за сервер. Для небольших компаний это мой первый выбор. Интерфейс понятный, восстановление надёжное, умеет сам гнать копии в облако или на NAS. Acronis тоже рабочий, но у них с ценообразованием в последнее время стало что-то совсем непрозрачное.

Проверка восстановления: самое важное, что все пропускают

Бэкап, который никто не проверял — это не бэкап. Это иллюзия. Говорю это на каждой встрече с клиентами — и всё равно каждый год кто-нибудь приходит с одной и той же историей: файлы бэкапа есть, восстановить из них ничего не получается. Битые файлы. Переполненный диск. Слетевшие права доступа. Причин хватает.

Проверка бэкапа — это не «посмотрел, файл есть, размер не ноль». Нет. Берёте последний бэкап, разворачиваете базу на тестовой виртуальной машине, запускаете 1С. Открылась? Данные на месте? Дата последней операции совпадает с ожидаемой? Только тогда у вас реально работающий бэкап, а не надежда на него. Раз в месяц — минимум, без исключений.

У нас для клиентов на абонентском обслуживании это прописано в регламенте. Каждые 30 дней — тестовое восстановление базы, отчёт на почту. 40-60 минут работы инженера, уже включено в стоимость. Поначалу некоторые клиенты морщатся: зачем платить за то, что и так работает? Но стоит нам один раз поймать проблему с бэкапом до того, как грянул гром, — и этот вопрос больше не возникает.

Сколько стоит нормальный бэкап и нужен ли подрядчик

Посчитаем по-честному. NAS Synology с двумя дисками по 2 ТБ — 30-35 тысяч рублей, один раз. Лицензия Veeam Agent — 8-12 тысяч в год. Облачное хранилище S3 при нормальных объёмах — 2-3 тысячи в год. Итого: первый год обходится в 40-50 тысяч, каждый следующий — 10-15 тысяч. Теперь вопрос: сколько стоит один день простоя бухгалтерии? Один день. Ответ, как правило, всё ставит на место.

Настроить всё своими силами — реально, если в компании есть толковый технический человек. Уйдёт 2-4 рабочих дня. Нет такого человека или просто некогда — зовите подрядчика. Разовая настройка бэкапной инфраструктуры у нас стоит 15-25 тысяч рублей: зависит от количества баз, их типа, куда копировать и нужен ли мониторинг.

Разовая настройка — это половина дела. Главное — постоянное наблюдение. Бэкап умеет тихо ломаться спустя три месяца: диск переполнился, права доступа изменились, задача в Планировщике Windows слетела после очередного обновления. Если никто за этим не следит — о проблеме вы узнаете в самый неподходящий момент. А он, как показывает наша практика, всегда наступает внезапно.

Частые вопросы

Можно ли делать бэкап 1С на флешку или внешний диск?
Можно, и это лучше, чем ничего. Флешка — ненадёжный носитель: умирает без предупреждения, особенно дешёвая. Внешний диск надёжнее. Главное — хранить его отдельно от сервера, чтобы при пожаре или краже не потерять и машину, и бэкап одновременно. Идеальный вариант — комбинировать: внешний диск плюс облачное хранилище.

Что делать, если база 1С уже повреждена?
Первым делом — не паниковать и ничего не удалять самостоятельно. Запустите встроенное средство проверки в конфигураторе 1С: меню «Администрирование — Тестирование и исправление». Если не помогает — звоните специалистам, не пытайтесь самостоятельно переустанавливать или перемещать файлы базы. Во многих случаях данные можно частично или полностью восстановить даже из повреждённых файлов, если не усугубить ситуацию.

Нужно ли делать бэкап конфигурации 1С отдельно от базы?
Да, если конфигурация дорабатывалась под вашу компанию. Конфигурация — это структура и логика 1С, все кастомные доработки и настройки. Типовую конфигурацию можно скачать заново с сайта 1С, а вот доработки так не вернуть. Делайте выгрузку конфигурации в файл cf через конфигуратор хотя бы раз в месяц или после каждого обновления — файл маленький, а потеря может обойтись в стоимость повторной доработки.

Как часто нужно проверять, что бэкап работает?
Раз в месяц — проверяйте, что файлы бэкапа создаются и их дата актуальна. Раз в квартал — делайте полное тестовое восстановление: разворачивайте базу на отдельном компьютере или виртуальной машине и проверяйте, что 1С открывается и данные на месте. Без тестового восстановления вы не знаете, есть ли у вас реальная защита или только иллюзия.