Коллеги, привет!
Короткий текст, но, возможно, самый полезный из всех, что я писал.
Вопрос простой: когда вы в последний раз разворачивали свой бэкап? Не делали, а именно разворачивали и проверяли, что база открывается и данные на месте.
Если ответ «не помню» или «никогда» — читайте дальше, тут на пятнадцать минут работы))
Три вопроса, на которые надо ответить честно
Первый: где лежит копия?
Если на том же диске или на том же сервере, что и база — это не резервная копия. Это вторая копия на том же носителе. Сгорит диск — сгорит и она.
Второй: когда сделана последняя?
Открываете папку с бэкапами и смотрите дату. Бывает, что автоматика отвалилась полгода назад, а никто не заметил, потому что никто не смотрел.
Третий: она вообще открывается?
Вот это и есть главный вопрос. Файл может лежать, весить положенное, иметь свежую дату — и не разворачиваться.
Три ответа — и вы уже понимаете, есть у вас бэкап или иллюзия бэкапа.
Плохая новость: выгрузка в .dt — это не бэкап
Вот этот пункт для многих будет неожиданным.
Самый популярный способ «сделать копию» в 1С — выгрузить базу в файл .dt через конфигуратор. Быстро, привычно, все так делают.
Проблема в том, что фирма 1С официально не считает выгрузку в .dt резервной копией. И на то есть причина.
Если в базе есть нарушения целостности — а они накапливаются незаметно — при выгрузке часть данных может просто не выгрузиться. Вы получите файл, который весит нормально, а внутри неполный. И узнаете об этом в момент восстановления, когда будет уже поздно.
Полный бэкап на уровне файлов или средствами СУБД копирует всё как есть, включая проблемные места. Восстановить и починить потом можно. Из битой .dt-выгрузки восстанавливать нечего.
Плюс практическое: для больших баз выгрузка требует монопольного режима и занимает много времени. Вы физически не сможете делать её каждый день, если база выросла.
Вывод: .dt хорош как способ перенести базу с места на место. Как основной бэкап — нет.
Как правильно: файловая база и клиент-серверная
Способ зависит от варианта базы, и это принципиально.
Файловая база. Копируется файл базы целиком. Важно: копировать надо, когда с базой никто не работает, иначе получите копию в неконсистентном состоянии. Отсюда — бэкап по ночам, а не в обед.
Клиент-серверная база. Только средствами СУБД — штатными механизмами PostgreSQL или MS SQL. Это принципиальный момент: СУБД делает согласованную копию, и пользователи при этом могут продолжать работать. Не надо никого выгонять и ждать ночи.
Если у вас клиент-серверная база, а бэкап делается выгрузкой в .dt по ночам с выгоном пользователей — вы делаете двойную работу и получаете худший результат. Это самая частая ошибка из всех.
Правило 3-2-1
Классика, которая работает и не устаревает:
- три копии данных;
- на двух разных носителях;
- одна — вне основной площадки.
Для небольшой компании это выглядит так: рабочая база на сервере, автоматическая копия на отдельный диск или NAS, и ещё одна — в облако или на диск, который увозят из офиса.
Звучит избыточно ровно до того дня, когда пригодится. А потом оказывается, что это был минимум.
Проверка за 15 минут
Собственно, ради чего всё затевалось. Порядок такой.
Минуты 1-3. Найдите последнюю копию. Посмотрите дату и размер. Сравните с предыдущей: если размер вдруг резко упал — копия битая, автоматика сломалась.
Минуты 3-5. Проверьте, где она лежит. Не на том же диске? Не на том же сервере? Есть копия вне офиса?
Минуты 5-12. Разверните её. Вот это обязательный пункт. Не на рабочую базу, а рядом — как отдельную тестовую. Файловую просто скопируйте в другую папку и подключите. Клиент-серверную восстановите средствами СУБД под другим именем.
Минуты 12-15. Откройте и посмотрите данные. Зайдите в базу. Проверьте последние документы, остатки, справочники. Данные на месте? Дата последнего документа соответствует дате бэкапа?
Всё. Пятнадцать минут — и вы либо спокойны, либо знаете о проблеме заранее, а не в день катастрофы.
Такую проверку разумно делать раз в месяц или хотя бы раз в квартал. И обязательно — после любого изменения в схеме резервного копирования.
Почему копия на том же сервере не спасёт
Отдельно про шифровальщиков, потому что это сейчас главная причина потери данных, а не сгоревшие диски.
Логика шифровальщика простая: он шифрует всё, до чего дотягивается. Все подключённые диски, все сетевые папки, все доступные хранилища. Копия базы, лежащая в соседней папке на том же сервере, шифруется вместе с базой.
Что реально помогает:
- копия на хранилище, которое не смонтировано постоянно — подключается только на время бэкапа;
- копия в облаке с версионированием, где старые версии нельзя перезаписать;
- копия на носителе, который физически лежит в другом месте.
И ещё: проверьте, под какой учётной записью работает ваша служба бэкапа. Если у неё полные права на всё — шифровальщик, попавший в систему, получит те же права.
Если проверять некогда
Как вы помните, я айти-специалист: собираю и настраиваю серверы, веду 1С для организаций.
Чем помогаем:
- проверяем существующие бэкапы — разворачиваем и смотрим, живые ли они на самом деле;
- настраиваем правильную схему — средствами СУБД для клиент-серверных, по расписанию, с хранением вне сервера;
- ставим контроль — чтобы вы узнавали о сломавшейся автоматике сразу, а не через полгода;
- сдаём в аренду серверы с поддержкой, где резервное копирование настроено и проверяется без вашего участия — это ИТ-поддержка организаций.
Подробнее про сопровождение 1С: 1c.akernel.ru/services/podderzhka-1s
Но лучше не откладывайте. Разверните бэкап прямо сегодня, это пятнадцать минут)
Читайте также: 1С тормозит: диагностика за 30 минут и Какой сервер нужен под 1С.
Комментарии
Комментариев пока нет. Будьте первым!