Администрирование · 12 мин
Где хранить бэкапы 1С: варианты и правила безопасного хранения
Где хранить резервные копии баз 1С: локальные диски, NAS, облака, правило 3-2-1, автоматизация копирования, проверка восстановления и типичные ошибки.
Потеря базы 1С — это остановка учёта, невозможность сдать отчётность и, как минимум, несколько дней на ручное восстановление первички. При этом сама база бэкапится несложно: вопрос почти всегда упирается в то, где физически лежат копии. Копия на том же диске, что и рабочая база, не спасает ни от отказа диска, ни от шифровальщика, ни от пожара в серверной.
Правильное место хранения выбирается по трём критериям: копия должна быть физически отделена от рабочей базы, доступ к ней не должен совпадать с правами обычного пользователя, а сама процедура должна выполняться автоматически и регулярно проверяться восстановлением. Ниже разберём конкретные варианты хранения, их ограничения и рабочую схему для разных масштабов.
Почему нельзя хранить копию рядом с базой
Самая частая ситуация в небольших компаниях: скрипт складывает dt-файлы в папку на том же сервере, где крутится SQL-база или лежит файловая база. Такая схема защищает только от случайного удаления данных — и то не всегда. Отказ диска, сбой RAID-контроллера, шифровальщик, зашедший по сети, или банальная коммунальная авария уничтожат и базу, и копию одновременно.
Отдельно опасны сетевые папки, подключённые к серверу как диск с правами на запись для всех. Современные шифровальщики в первую очередь ищут именно такие ресурсы и шифруют бэкапы вместе с рабочими данными. Если папка с копиями доступна на запись учётной записи, от имени которой работают пользователи, она уязвима ровно настолько же, насколько уязвим рабочий компьютер.
Локальное хранение: отдельный диск, сервер и NAS
Минимально приемлемый уровень — копии на отдельном физическом устройстве внутри офиса. Вариантов три: второй диск в сервере (хуже всего), отдельный сервер или компьютер под бэкапы, сетевое хранилище NAS. Для файлового режима 1С и баз до нескольких десятков гигабайт NAS начального уровня — практичный и недорогой выбор: он работает круглосуточно, умеет забирать копии по расписанию и поддерживает снапшоты.
Ключевое требование к локальному хранилищу — изоляция прав. Папка, куда складываются копии, должна быть доступна на запись только служебной учётной записи, под которой выполняется копирование. Обычные пользователи и, в идеале, повседневная учётка администратора не должны иметь туда доступа на запись — только на чтение для восстановления. Это резко снижает риск шифрования или случайного удаления архива.
Полезно включить на хранилище версионирование или снапшоты файловой системы, если устройство это поддерживает. Тогда даже повреждённая или перезаписанная копия не станет проблемой: можно откатиться к состоянию папки на прошлую дату. Также настройте уведомления о сбоях задачи копирования — «тихо сломавшийся» бэкап обнаруживается обычно именно в тот день, когда он нужен.
Облачное хранение: что подходит для копий 1С
Облако закрывает главный недостаток локального хранения — копия физически находится вне офиса и переживёт пожар, кражу оборудования или затопление серверной. Для бэкапов 1С подходят объектные хранилища (S3-совместимые), облачные диски с клиентом синхронизации и специализированные сервисы резервного копирования. Выбор зависит от объёма базы и канала связи.
Практические ограничения, о которых часто забывают. Первое: начальная загрузка большой базы (десятки гигабайт) по обычному офисному каналу может занять сутки и больше, дальше уйдут только инкременты или ежедневные полные выгрузки — оцените канал заранее. Второе: dt-файл хорошо сжимается архиватором, перед отправкой в облако копию имеет смысл упаковать и зашифровать, особенно если база содержит персональные данные сотрудников и контрагентов.
Третий момент — неизменяемость (immutability). Если облачное хранилище поддерживает блокировку объектов от удаления и изменения на заданный срок, включите эту опцию для бэкапов. Это защита от сценария, когда злоумышленник с доступом к серверу пытается удалить облачные копии вслед за локальными.
Сравнение вариантов хранения
Быстро и бесплатно, но не защищает от отказа сервера и шифровальщика. Допустимо только как промежуточная площадка перед копированием наружу.
Хороший баланс цены и удобства для быстрого восстановления. Не защищает от пожара, кражи и заражения всей локальной сети.
Защищает от локальных катастроф, требует стабильного канала и шифрования. Стоимость растёт с объёмом и глубиной хранения.
Дешёвая offsite-копия, но зависит от дисциплины сотрудника, который возит носитель. Подходит как третий уровень, не как единственный.
Схема хранения по правилу 3-2-1 для 1С
Собрать рабочую схему несложно даже без выделенного системного администратора. Типовой вариант для небольшой компании: ежедневная выгрузка dt или бэкап СУБД по расписанию ночью, копия складывается сначала на NAS в офисе, затем оттуда автоматически реплицируется в облако. Итого — рабочая база плюс две независимые копии на разных носителях, одна из которых вне площадки.
Определите глубину хранения: сколько копий держать по времени. Разумный минимум — ежедневные копии за последнюю неделю, еженедельные за месяц и ежемесячные за квартал–год. Это позволяет откатиться не только на «вчера», но и на дату до обнаруженной поздно ошибки: например, если некорректная обработка испортила данные неделю назад, а заметили это только сейчас.
Автоматизация и контроль, что копии реально создаются
Бэкап, который делается «вручную, когда помним», рано или поздно перестаёт делаться. Для файлового режима задача решается планировщиком заданий и скриптом, который запускает конфигуратор в пакетном режиме с параметром /DumpIB. Для клиент-серверного варианта используются штатные планы обслуживания СУБД. В обоих случаях результат должен фиксироваться в журнале: успех, ошибка, размер файла.
Пример команды выгрузки файловой базы в dt через конфигуратор:
"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F "D:\Bases\Trade" /N backup /P *** /DumpIB "E:\Backups\trade_%date%.dt" /Out "E:\Backups\log.txt"Обращайте внимание на размер свежих копий: резкое уменьшение размера dt по сравнению с предыдущими — тревожный признак, возможно, выгрузка обрывается. Ещё один рабочий приём — мониторинг наличия свежего файла: если в папке бэкапов нет файла моложе суток, система мониторинга должна подать сигнал. Это простая проверка, которая ловит большинство отказов задачи копирования.
Как проверить, что бэкапы в порядке
Файл копии создан в последние сутки, размер сопоставим с предыдущими
Файла нет или размер резко упал — задача копирования сломана
Копия разворачивается в тестовую базу, конфигуратор открывается, данные на месте
Ошибка при загрузке dt или восстановлении бэкапа СУБД
Копии доступны для чтения, но не для записи обычным пользователям
Папка с бэкапами открыта всем на запись или недоступна вовсе
В облаке или на удалённой площадке лежит копия не старше суток
Репликация в облако не выполнялась несколько дней
Тестовое восстановление: единственный способ проверить бэкап
Копия, которая ни разу не восстанавливалась, — это предположение, а не гарантия. Практика показывает, что битые архивы, неполные выгрузки и несовместимые версии СУБД обнаруживаются именно при попытке восстановления. Поэтому тестовое восстановление должно быть регулярной процедурой, а не событием в день аварии.
Порядок проверки простой: разверните свежую копию в отдельную тестовую базу (для dt — загрузка через конфигуратор в пустую базу, для СУБД — restore в базу с другим именем), откройте её в режиме предприятия, проверьте несколько ключевых отчётов и журналы документов за последние дни. Делайте это минимум раз в месяц и обязательно после любых изменений в схеме резервного копирования.
Удобно завести короткий регламент в одну страницу: где лежат копии, кто отвечает за мониторинг, как часто делается тестовое восстановление и куда сообщать при сбое. В день аварии этот документ экономит часы — не придётся вспоминать, на каком сервере искать свежий бэкап и какой пароль у архива.
Типичные ошибки при организации хранения
Отдельно выделим ошибку с обновлением платформы и конфигурации: перед любым обновлением делайте внеплановую копию и убедитесь, что она успешно создана. Значительная часть обращений за восстановлением связана именно с неудачными обновлениями, когда рабочей копии «перед обновлением» не оказалось, а последняя регулярная — недельной давности.
Что важно запомнить
Храните копии 1С минимум в двух независимых местах: локально на отдельном устройстве и вне офиса. Изолируйте права на папку с бэкапами, автоматизируйте создание копий с уведомлениями об ошибках, держите глубину хранения и регулярно проверяйте восстановление. Копия рядом с базой — не бэкап.
Частые вопросы о хранении бэкапов 1С
Достаточно ли копии, которую делает 1С:Фреш или облачный сервис?
Если база работает в облачном сервисе, уточните у провайдера условия: периодичность копий, глубину хранения и порядок восстановления по запросу. Даже при надёжном сервисе полезно периодически выгружать dt самостоятельно — это страховка от ошибок в данных, которые сервисный бэкап не исправит, и гарантия доступа к данным при смене провайдера.
Что лучше для бэкапа: выгрузка dt или копия средствами СУБД?
Для клиент-серверного режима основным должен быть бэкап СУБД: он быстрее, надёжнее для больших баз и позволяет восстановиться на точку во времени. Выгрузка dt — дополнительный уровень: она независима от СУБД и удобна для переноса, но на больших базах выполняется долго и создаёт нагрузку. Для файлового режима dt остаётся основным вариантом.
Как часто нужно делать копии базы 1С?
Минимум — ежедневно, в нерабочее время. Если за день в базе проходит много операций и потеря дня работы недопустима, для клиент-серверного режима настраивают копии журнала транзакций с интервалом в несколько часов. Выбор частоты определяется допустимой потерей данных: сколько часов работы вы готовы вводить заново.
Можно ли хранить бэкапы только в облаке, без локальной копии?
Технически можно, но восстановление большой базы из облака займёт часы или дни в зависимости от канала, а при отказе интернет-связи копия окажется недоступна. Локальная копия нужна для быстрого восстановления в типовых ситуациях, облачная — для катастроф. Отказываться от одного из уровней стоит только осознанно.
Как защитить бэкапы от вирусов-шифровальщиков?
Три меры работают вместе: папка с копиями доступна на запись только служебной учётной записи, в облаке включена неизменяемость объектов или версионирование, а на локальном хранилище — снапшоты. Дополнительно помогает схема, где хранилище само забирает копии с сервера, а не сервер пишет на хранилище.
Что делать, если база большая и не помещается в облачный тариф?
Сначала сожмите копию архиватором — dt сжимается в несколько раз. Затем пересмотрите глубину хранения в облаке: держать там можно только последние копии и ежемесячные, а длинный архив оставить локально. Если и этого мало, рассмотрите инкрементальные бэкапы средствами СУБД — в облако уходят только изменения.