Коллеги приветствую!
Недавно изобрел способ резервного копирования "отдельно взятого документа" через выгрузку/загрузку xml
Нескольким клиентам он реально помог восстановить из старых копий потерянные данные, еще несколько начали пользоваться в качестве инструмента сохранения документов
Процесс использования показан тут:
https://www.youtube.com/watch?v=bPkNGe3RSsM
Суть метода: выгружаешь подпиленной ВыгрузкойЗагрузкойДанных83 (дописаны отборы) по отбору нужный документ, справочник или их совокупность. Химичишь с этими доками в базе что хочешь, а когда все сломал - загружаешь назад в базу выгруженную в xml копию, в итоге в доках и справочниках все восстанавливается как было, в том числе и движения и проводки.

Нереально прикольно, чтобы не поднимать бекапы, а быстро все починить, никого не выгоняя и буквально за секунды

Так вот хотел спросить, а все ли корректно восстанавливается при такой операции? Не порушатся ли какие-то более базовые конструкции? Кто вообще знаком с нюансами поведения объектов при загрузки их данных из xml. При глобальных переносах у меня ни одна база, загруженная через xml, без допила руками или перепроведения нормально не взлетела.

Насколько можно рекомендовать использовать такой способ бекапов и где это вылезет боком?

блин, опять промазал со ссылкой
резервное копирование через xml способ тут: https://www.youtube.com/watch?v=DW4CLS2zYls

(0) ты уже весь инет загадил этмии роликами, реклама на мисте платная

парень из фузи, в 1с есть регистры

(2) где я что загадил? кого я рекламирую, Нуралиева?

(0) Мдя

(3) движения регистров тоже хорошо выгружаются и загружаются

(0) Сделай лучше инкрементный бэкап в xml, со всей историей изменений и возможностью частичного восстановления на любой момент времени.

(7) а как обеспечить по полному файлу xml частичное восстановление?

(7) можно запилить и загрузку с отбором? есть примеры?

А чем типовые средства не устраивает?

(8) А подумать?

(0) XML можно использовать только для относительно небольших выгрузок и загрузок - типа переноса остатков. Для того чтобы сделать полный бэкап сколько-то серьезной базы и потом восстановить его, вам никаких машинных ресурсов не хватит. Для этого используются низкоуровневые средства, которые работают с блоками данных.

(12) Скажи это БИТу с их RabbitMQ адаптером ))

(12) Ни в коем случае не предлагаю использовать такой вариант для полного бекапа, только для частичного и сиюминутного. Первые проблемы с которыми я столкнулся при его применении - при копировании справочника контрагентов и загрузки его в РИБ - там задвоились предопределенные виды контактной информации и хозяйственные операции. Но это при РИБе. При возврате данных в родную базу-все чисто.

(10) какие именно типовые? Типовых замен с таким же эффектом (за несколько секунд поправить данные в базе и никого не выгнать) - не нашел

(15) История изменений. Фиксирует изменения. Позволяет сравнить ДО и ПОСЛЕ, ну и перейти к сохраненой версии

(13) так там вроде речь про онлайн-передачу данных, а тут про бэкап. Немного разные вещи.

(17) Инкрементный бэкап а не все разом.
Любое изменение вызывает сохранение того что было изменено и всегда можно откатиться.
Решать через подписки при записи например.

(16) Вы имеете в виду версионирование? Хм, да, интересная идея. Включение правда добавляет требования производительности, и не у всех объектов она предусмотрена

конечно ты изобрел способ которому лет 20 уже

(18) ну а если мне надо все разом?

(20) я не претендую на открытие конечно, но расскажите, где и кем он раньше применялся? Именно как вариант массового частичного резервного копирования

(22) ну из бэкапа перекинуть документ - всегда применялся. как только появилось в 1с выгрузка в хмл

(23) а ничего, что в стандартной ИТС выгрузке загрузке xml на 8.3 не предусмотрены отборы?

(23) на 8.2 согласен, применялось. Ну по крайней мере, была возможность применять. Отборы были. на 8.3. при выгрузке возможности отборов нет

(25) делись обработкой чтоли

(26) https://yadi.sk/d/e-frdMdaSAy0pg

все таки основной вопрос по теме был - насколько резервное копирование через xml - соответствует духу резервного копирования? С какой стороны полезут тараканы?

(24) там есть даже отбор запросом

(28) рабочая схема. Тараканы только одни: может измениться что-то, что ты не забэкапил. И всё.

Ну и в зубах всяких куча регистров формируются фоново. Теоретически можно получить не согласующиеся данные

*(31) ЗУПах
Т9)

(29) нет там отборов по объектам метаданных. Только по периоду
https://its.1c.ru/db/metod8dev#content:4126:hdoc
Обработка поддерживает выгрузку данных с возможностью задания отбора по периоду. Также реализована проверка объектов на наличие недопустимых символов при обмене через XML.

(31) я пробовал выгрузить из УТ регистр "Себестоимость товаров" из копии базы с корректным закрытием месяца, и загрузить в рабочую, где себестоимость поплыла после экспериментов. Отчет валовая прибыль предприятия по загруженным периодам показал данные полностью как до экспериментов

еще классно обработала выгрузка xml когда надо было назначения и виды запасов поправить при интеркампани в Ут 11.4

(33) закладка "дополнительные объекты для выгрузки". Конечно не так удобно как в ОФ, но для ссылочных данных вполне достаточно. С регистрами - да, фиг отберешь.

(34) Понятно что с тем о чём ты знаешь и что переносишь - проблем нет. Но в ЗУПе есть, например, интервальные регистры, которые формируются подписками или фоновыми вне проведения и которые технически не являются движениями документа (независимые РС). Так вот не зная о таких вещах можно получить сюрпризы, причём отложенные.

(0) > Недавно изобрел способ резервного копирования "отдельно взятого документа" через выгрузку/загрузку xml

хоспидя, я эту хрень использую уже пару лет.
тоже мне ноу-хау...

(36) расскажете свой вариант использования? Пошагово?

(35) спасибо, только ради этого поста стоило открывать эту тему

(37) А какие варианты:
выгрузил - загрузил при необходимости,
(кто-то ;) ) накосячил - выгрузил из копии - загрузил.

Из регулярно используемого:
выгрузил - поправил текст - загрузил. Часто так замену ссылок делаю, когда лень обработки искать/писать.

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

(39) вы про предметную разработку под конкретный случай, а я про массовый общедоступный инструмент для людей без навыков программирования

(39) но то что вы так пользуетесь, это очнь круто

(0) Это хорошо работает, когда перенос между базами идентичными. К примеру, между рабочей и копией той же версии, с небольшой разницей. К примеру, современные конфы сейчас зачастую программно "создают" предопределенные элементы при первом старте. Естественно, в итоге у другой такой же конфы, независимо настроенной при первом запуске, идентификаторы предопределенных элементов другие. В итоге, перенос, сделанный этой обработкой, пройдет, но предопределенные элементы задвоятся, это может привести к неприятным моментам(к примеру, из-за задвоенных видов контактной информации будут проблемы с адресами и прочим). Так что пользоваться этой обработкой стоит очень осторожно, к примеру, переносить документы, но без справочников(только ссылками, галочки поснимать рекурсивной выгрузки).

(40) Этот случай не на ровном месте возник. Ребята делавшие проект умыли руки. А я сделал это стандартным инструментом, той самой ВыгрузкаЗагрузкаXML, используемой регулярно для (0) в том числе. Писалась только замена.

Насчет "инструмент для людей без навыков" я бы поостерегся. У меня была обработка, которая умела по журналу регистрации отбирать измененные объекты и затягивать их из копии, но пользователям в руки я ее не давал)

(42) +1, со всем согласен, спасибо

(43) такую как у Вас, я бы тоже пользователям не дал. А вот такую как в теме, наоборот, дал бы, чтобы потом вместе с ними не перегребать перепутанные назначения и резервы, а также не загружать из копии случайно удаленный документ (его версионированием кстати не восстановишь)

(6) Все движения? Вы таки в курсе, что документ может подбрасывать свои движения ДРУГИМ документам?

(27) Эта обработка не типовая что ли? Чем отличается от (33) ?

какой интересный и необычный велосипед однако

(24) ты нашел на просторах инета обработку с отборами? у меня тоже такая есть

Во Фреше используется резервное копирование области данных тоже через сериализацию объектов БД в файл. Для обеспечения согласованности данных во время такого резервного копирования блокируется вход пользователей в базу (в область данных).

+(50) Конечно же это все медленно и ни о каком восстановлении на любой момент времени речь не идет - только на тогда когда соломку подстелил

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

(52) А оно позволяет восстановить предыдущее состояние?

(53) разве нет?
https://hkar.ru/ZQdV

(54) а движения сохранятся? Или проведется заново?

(55) вместе с документом будут восстановлены его движения

(40) всё-таки это очень медленно получится. Отбор по периоду по идее для бухгалтерии надо ставить 4-5 месяцев, потому что бухи обычно работают в прошлых месяцах. А это десятки тысяч документов будет в вашем файле. А восстановить нужно один документ, все месяцы не надо восстанавливать. В итоге впустую будет всё лопатится. Ну и все последние изменения в справочниках слетят послеэтого обновления.

Ещё в 2006 году восстанавливал так кривое "Закрытие месяца" из копии.