Search
Write a publication
Pull to refresh

Comments 12

А как теперь откатить какую-нибудь базу к бекапу, если ее "часть" (файлы сканов, штрихкоды документов) находится в общей для всех "1С Документооборот"?
На выходе получается довольно несогласованное состояние, когда часть данных откатывается, а часть нет.

А вы в продакшене часто откатываете к бэкапу? Я на своей памяти не припомню, да, восстанавливали данные частично перегрузкой, но чтоб целиком бэкап в продакшене...

Было пару раз. И когда это нужно - это было нужно чертовски быстро. А перегрузка это совсем не быстро, это не очень то надежно (ее результат обязательно проверять, а вот бекап отлично разворачивается и без последующей проверки) и уж точно ее не сделать одним только сисадмином.

Так пишите сервисы так, чтоб синхронизация в случае восстановления из бэкапа была с учетом этой ситуации и всё. Всё же восстановление это форсмажор и крайне редкая ситуация, вы её в разряд радовых пытаетесь записать

А это как? Делаю пример на основе статьи выше: была рабочая база, связанная с документооборотом - в ней что-то сделали неправильно и часть данных испорчена (вместе с куском, лежащим в документообороте). Восстановили рабочую базу по состоянию на ночь. Как надо писать сервис (документооборота?), чтобы в нем все вернулось в неиспорченное состояние?

У ДО бэкапы не делаются? Может и его тогда откатывать?

Откатили ДО, в нашей рабочей стало нормально, но т.к. эта ДО - общая база еще для десятка других - то теперь данные испорчены в них.

P.S. ну и отдельно стоит упомянуть, что общая ДО - это огромный объем. В статье вот 4 ТБ. Ее откат - это дело совсем не быстрое, наверняка измеряется несколькими часами и огромной нагрузкой на диски.

Сама база ДО крайне небольшая, измеряется может в сотнях Гб. Мы на этого карлика вообще не смотрим. Восстанавливается мигом.

Много места занимает файлохранилище, которое лежит на отдельной DFS шаре. Его целиком восстанавливать не надо.

Очень быстро надо развернуть бекап чтобы восстановить рабочие процессы - производство на станках, выдачу на складе и розничную торговлю. Ко всему этому налоговый мониторинг не имеет никакого отношения. В DRP этот процесс мы восстанавливаем после 3го дня от момента X. В реальности - когда восстановим все остальное и отоспимся/напьемся после этого.

Все документы налогового мониторинга имеет свой естественный ключ, регламентированный ФНС. Как правило, это номер + дата + контрагент. В DRP мы откатываемся предпочтительнее по синтетическому ключу (это надежнее), остальное - по естественному.

Например играем сценарий, когда в учетной системе утеряна часть документов. Часть документов пересоздаем с генерацией новых синтетических ключей - это прежде всего из бумажных документов и модулей ЭДО. В бесшовной интеграции с 1С Документооборот можно связать новые синтетические ключи с уже ранее созданными в 1С Документооборот объектами через естественные ключи. Это штатный механизм.

Если же документы в учетной системе созданы интеграцией с третьей системой (например WMS) с сохранением синтетического ключа WMS, то все еще проще. В учетную систему объекты будут дозагружены из WMS и все автоматически встанет на свои места.

Так смысл остался тем же. Бекапы перестали быть бекапами (как целостное непротиворечивое состояние на момент Х), пользоваться ими близко к невозможному. И теперь "восстановление" - это именно перегрузка откуда-то данных (не принципиально, копия ли это или с интеграций).
Перегрузка данных - значит сразу поднимаем квалификацию исполнителя: сисадмин не подойдет, нужен программист. Перегрузка всегда будет дольше восстановления из двоичных бекапов СУБД. И заодно к перегрузке добавляется проверка данных после загрузки (и, возможно, вторая итерация, если что-то не приехало не важно по какой причине).
Неслабо так операция усложнилась.

Целостный бекап и откат к нему - это из сферы фантастики. Применимо лишь там, где нет систем реального времени. Например, весовая грузовиков с зерном, нормировка материалов на производстве или списании баллов в розничной торговле. При повреждении данных в финансовой системе никто никогда не будет трогать систему с уникальными данными.

Восстанавливаем бекап поврежденной системы и в него вливаем все из соседних систем (либо перевыгрузкой, либо машиной времени на шине данных). Если повреждена система реального времени - ищем ее следы в остальных системах и из них восстанавливаем систему реального времени.

Sign up to leave a comment.

Articles