Бэкап базы 1С есть, а файлов из томов в нём нет: как проверить заранее
Иван Недомолков · Жарияланды:
Симптом выглядит так. Базу восстановили из резервной копии, пользователи работают, карточки присоединённых файлов открываются, а при попытке открыть сам скан или картинку 1С сообщает, что файла нет. Второй вариант того же симптома: отчёт целостности тома показывает строки со статусом “Отсутствуют данные в томе на диске”.
Обычная причина в том, что файлы живут в томах на диске, а копируется только база. Копия СУБД уносит запись о файле, каталог тома в неё не входит. Вторая половина проблемы тише: даже когда каталог тома копируется, пропажу файла, который никто не открывает, замечают через недели, и к этому моменту нужной копии уже нет. Ниже проверка по шагам и разбор реального случая, где эти две половины сошлись.
Где лежат файлы вашей базы
Первый вопрос, от которого зависит всё остальное. В конфигурациях на Библиотеке стандартных подсистем (БСП) у справочника “Версии файлов” и у каждого справочника присоединённых файлов есть три реквизита: “Тип хранения файла”, “Том” и “Путь к файлу”. Мы проверяли на Управлении торговлей (УТ) с БСП 3.1.11: справочников присоединённых файлов там 142, реквизиты есть у всех 142.
| Как хранится файл | Что попадает в бэкап СУБД | Что копировать отдельно |
|---|---|---|
| В информационной базе | запись и сам файл | ничего |
| В томах на диске | только запись: ссылка на том и путь | каталог каждого тома |
Если у вас первый вариант, дальше можно не читать: файл уезжает в копию вместе со своей записью. Если второй, у вас две системы хранения, и согласованы они ровно настолько, насколько согласованы задания их копирования.
Посмотреть, сколько записей у вас в томах, можно одним запросом. Он выполнен на той же УТ без ошибок:
ВЫБРАТЬ
ВерсииФайлов.Том КАК Том,
КОЛИЧЕСТВО(*) КАК Записей
ИЗ
Справочник.ВерсииФайлов КАК ВерсииФайлов
ГДЕ
ВерсииФайлов.ТипХраненияФайла = ЗНАЧЕНИЕ(Перечисление.ТипыХраненияФайлов.ВТомахНаДиске)
СГРУППИРОВАТЬ ПО
ВерсииФайлов.ТомДля присоединённых файлов тот же запрос пишется к их справочникам. Ноль строк означает, что тома не используются.
Два сценария, в которых файлы теряются
| Сценарий | Когда проявится | Что видит пользователь | Чем ловится |
|---|---|---|---|
| Базу копируют каждую ночь, каталог тома в задание не включили | только после восстановления из копии | записи на месте, файлов нет | сверка на базе, поднятой из копии вместе с копией каталога |
| Том перенесли на другой диск или сетевую папку переподключили под другим именем, путь в карточке тома старый | в момент открытия уже загруженного файла | карточка открывается, файл нет | отчёт целостности и счётчик на рабочей базе |
Первый сценарий на рабочей базе не виден вообще. Всё сходится, пока сервер жив, и расходится ровно в тот день, когда копия понадобилась. Поэтому проверять его приходится на восстановленной копии, другого места нет.
Есть и третий вариант, более редкий: каталог хранения указан, приложение в него пишет, но физически каталог оказался не там, где его ждали и где его копируют. Разбор ниже как раз про него. Общий вывод из него для всех трёх: файлы надо считать там, где они обязаны лежать, а не по пути, который видит приложение.
Проверка по шагам
Шаг 1. Задание копирования. Откройте задание резервного копирования и найдите в нём каталог каждого тома. Не нашли, значит у вас копируется только половина данных. Каталог тома должен копироваться с той же частотой, что и база, и храниться столько же.
Шаг 2. Отчёт “Проверка целостности тома”. Он есть в БСП и открывается из списка томов хранения файлов и из карточки тома. Отчёт раскладывает файлы по статусам:
| Статус в отчёте | Что это значит |
|---|---|
| Целостные данные | запись есть, файл на месте |
| Отсутствуют данные в томе на диске | запись есть, файла нет: ваш случай потери |
| Лишние файлы (есть на диске, но сведения о них отсутствуют) | файл есть, записи о нём нет |
Шаг 3. Ежедневный счётчик. Отчёт запускают, когда подозрение уже есть. Чтобы подозрение появилось вовремя, хватает двух чисел раз в сутки: записей по тому (запрос выше) и файлов в каталоге тома. Файлы считаются на сервере под учётной записью, у которой есть доступ к каталогу. Подкаталоги надо отбросить: том раскладывает файлы по вложенным папкам. Код ниже - схема подсчёта: на базе мы его не прогоняли, поэтому перед тем как ставить в регламентное задание, запустите его на копии и сверьте число с тем, что показывает проводник.
// КаталогТома - путь из карточки тома, вызов на сервере
Найденные = НайтиФайлы(КаталогТома, "*", Истина);
ФайловВТоме = 0;
СамыйСтарый = Неопределено;
Для Каждого Элемент Из Найденные Цикл
Если Не Элемент.ЭтоФайл() Тогда
Продолжить;
КонецЕсли;
ФайловВТоме = ФайловВТоме + 1;
Изменен = Элемент.ПолучитьВремяИзменения();
Если СамыйСтарый = Неопределено Или Изменен < СамыйСтарый Тогда
СамыйСтарый = Изменен;
КонецЕсли;
КонецЦикла;Точного равенства записей и файлов не ждите: у счётчика другая работа. Разница не должна расти. Выросла за сутки, значит пора открывать отчёт целостности, пока в окне хранения ещё лежит копия каталога со вчерашними файлами.
Шаг 4. Дата самого старого файла. Самая дешёвая проверка из всех, она уже посчитана в коде выше. Если записи в томе идут с февраля, а старейший файл в каталоге датирован июлем, всё загруженное до июля потеряно, и никакой счётчик тут не нужен.
Шаг 5. Сверка на восстановленной копии. Единственный способ поймать первый сценарий. Поднимите базу из копии, рядом положите копию каталога тома и запустите на ней отчёт целостности. Если тестовая база у вас и так разворачивается из свежего бэкапа прода, отчёт достаточно гонять там. Для этого мы сделали обработку “Тестовая база из бэкапа рабочей” (карточка на Инфостарте): она собирает задание, которое каждую ночь поднимает тест из последней копии, и каждый такой прогон заодно доказывает, что копия восстанавливается. Про то, почему бэкап без проверки восстановления ничего не гарантирует и сколько такое восстановление длится на живом железе, есть отдельный разбор.
Разбор случая: копии были, но начались позже потери
Система в этой истории не на 1С, это корпоративная вики. Но устроена она как база 1С с томами: запись о вложении в базе, сам файл отдельно в хранилище на диске.
Приложение работало в контейнере, то есть в изолированной среде со своей файловой системой, которая живёт до пересоздания контейнера. Постоянное хранилище на хосте завели, в настройках стояло “хранить файлы локально” с путём, но само хранилище к контейнеру не подключили. Приложение писало по указанному пути внутрь контейнера, и каждое пересоздание стирало всё загруженное с прошлого раза.
| Дата | Событие |
|---|---|
| 4 февраля | заведено хранилище на хосте, к контейнеру не подключено |
| февраль - июль | записи о вложениях копятся, файлы исчезают при каждом пересоздании |
| 8 июля | последнее пересоздание, после него хранилище подключили |
| 23 июля | разбор жалобы на битые картинки |
| около 16 июля | начало недельного окна копий виртуальной машины на дату разбора |
Между концом потери и самой старой копией восемь дней. Все копии сделаны после того, как файлов не стало, и ни одного пропавшего файла в них нет.
Что показала сверка двух чисел, которые обязаны сходиться:
| Показатель | База | Хранилище |
|---|---|---|
| Вложений | 4 016 записей | 662 файла |
| Объём | 552 МБ | 89 МБ |
| Средний размер | 137 КБ | 134 КБ |
Записей без файлов 3 354, потерянный объём по средним около 463 МБ. Старейший уцелевший файл датирован 8 июля. Ровная граница по дате и есть главный признак: порча диска даёт дыры вразброс, а здесь исчезло всё, что было до определённого события.
Без картинок осталось 284 живых статьи. У живых неархивных документов 1 748 ключей вложений, и каждый искали в рабочем хранилище и в двух найденных каталогах, похожих на резервные копии (368 файлов в одном, 361 папка в другом). На месте оказалось 7, из обоих каталогов ноль совпадений, не найдено 1 741. Следов на хосте тоже не осталось: мёртвых контейнеров и остатков старых слоёв файловой системы с загрузками нет, второе хранилище от ранней попытки настройки пустое. Остался один путь: оригиналы у авторов, которые вставляли скриншоты прямо в редактор.
Для 1С отсюда два переноса. Картинка, вставленная прямо в редактор, часто существует в одном экземпляре, и этот экземпляр лежит в томе. А ежедневное сравнение числа записей с числом файлов, посчитанных на хосте, показало бы ноль файлов ещё в феврале.
Глубину хранения копий считают от срока обнаружения
Недельное окно копий в этой истории честно работало. Оно защищает от ошибки, которую заметили в течение недели. Эту заметили через две недели после конца потери и почти через полгода после начала.
Почему так поздно, понятно из устройства выдачи файла. Сервис отвечает, база целая, страницы открываются, запись о вложении на месте. Отказ приходит только на последнем шаге, при обращении к конкретному файлу. Проверка работоспособности его не видит, увидеть может только человек, открывший именно эту статью. У самой просматриваемой из пострадавших было 120 просмотров, и тревогу всё равно не подняли; почему, в разборе не записано.
С томами 1С то же самое: целая база создаёт полную иллюзию сохранности файлов. Поэтому вопрос к окну хранения звучит так: через сколько дней вы заметите пропажу файла, который никто не открывает? Если ответ длиннее окна, копии каталога тома у вас в том же положении, что у вики. Счётчик из шага 3 сокращает этот срок до суток. Без него честный ответ на вопрос выше - “когда кто-нибудь пожалуется”.
После переноса тома откройте несколько файлов руками
В той же истории уцелевшие 662 файла переносили в объектное хранилище, внешнее по отношению к приложению. Утилита копирования не проставила тип содержимого файлам без расширения в имени, хранилище начало отдавать их общим двоичным типом с запретом браузеру угадывать тип, и картинки перестали отображаться. Ссылка живая, файл на месте, изображения нет: со стороны пользователя это неотличимо от настоящей пропажи. Тип дописали из записи о вложении 657 объектам из 662.
При переносе тома 1С на другой диск или в другую папку правило то же. Код ответа “успешно” и совпавшее число файлов ещё не доказывают, что файл откроется. Откройте несколько штук из разных лет, а потом прогоните отчёт целостности.
Держать файлы в базе или в томах
Тома разгружают базу и её бэкап, и ради этого их обычно и включают: что даёт вынос вложений по сравнению со сверткой и обрезкой, сведено в сравнении методов уменьшения базы. Цена у выноса одна: вторая система хранения, которую надо копировать отдельно и сверять с первой. Понять, сколько места в базе вообще занимают файлы и стоит ли их выносить, помогает карта объёмов базы.
Если тома у вас уже есть, начните с двух вопросов. Входит ли каталог каждого тома в то же задание копирования, что и база? И когда отчёт проверки целостности тома запускали в последний раз? Если на оба ответа нет, это настраивается в рамках обслуживания базы 1С.
