Быстрый бэкап изменяемых данных

19.01.17

База данных - Архивирование (backup)

Хочу поделиться способом восстановления большого массива измененных данных, который мне удалось применить. Решение простое но не очень очевидное для меня.

Допустим, вам необходимо изменить элементы справочника Характеристика номенклатуры. Их очень много, вы их отбираете каким-нибудь запросом в консоли:

ВЫБРАТЬ
                ЦеныНоменклатурыСрезПоследних.Характеристика,
                ЦеныНоменклатурыСрезПоследних.Цена,
                ХарактеристикиНоменклатурыДополнительныеРеквизиты.Значение КАК ЦенаКакСвойство
ИЗ
                РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены = &Видцены) КАК ЦеныНоменклатурыСрезПоследних
                               ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ХарактеристикиНоменклатуры.ДополнительныеРеквизиты КАК ХарактеристикиНоменклатурыДополнительныеРеквизиты
                               ПО ЦеныНоменклатурыСрезПоследних.Характеристика = ХарактеристикиНоменклатурыДополнительныеРеквизиты.Ссылка
                                               И (ХарактеристикиНоменклатурыДополнительныеРеквизиты.Свойство = &Свойство)
ГДЕ
                ЦеныНоменклатурыСрезПоследних.Цена = (ВЫРАЗИТЬ(ХарактеристикиНоменклатурыДополнительныеРеквизиты.Значение КАК ЧИСЛО(15, 2)))

И пишете обработку, которая по этому запросу поменяет значения реквизитов в этих элементах. Как обеспечить откат в случае ошибки обработки?

Очень просто. В консоли запросов вы (предварительно!) сохраняете таблицу результата в формате mxl:

И спокойно выполняете свою обработку изменив и перезаписав 100500 характеристик номенклатуры.

Внезапно вы выясняете что изменили неправильно. Что делать?

Дело в том, что в mxl вы сохранили не только строковые значения, но и ссылки на объекты, которые хранятся в расшифровке. Поэтому пишем простой код получающий из mxl непосредственно объекты, сохраненные в расшировках полей mxl. В моем случае это выглядело так:

ТоСамоеСвойство = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("Старая цена (хар.)",ложь);
                ТабДок = Новый ТабличныйДокумент;
                ТабДок.Прочитать("C:\ бакуп.mxl");
                Для  ш = 2 по 2354 цикл
                               Область = табдок.Область(ш,1,ш,1);
                               сообщить(область.Расшифровка);
                               сообщить(ТипЗнч(область.Расшифровка));//убеждаемся, что там действительно ссылки
                               Цена = Число(стрзаменить(табдок.Область(ш,2,ш,2).Текст," ",""));
                               Сообщить(Цена);
                               Об = Область.Расшифровка.ПолучитьОбъект();
                               Для каждого о из об.ДополнительныеРеквизиты Цикл
                                               Если о.Свойство = ТоСамоеСвойство Тогда
                                                               о.Значение = Число(Цена);
                                                               Прервать;
                                               КонецЕсли;
                               КонецЦикла;
                               Об.записать();
                Конеццикла;

Может для кого-то это будет очевидно, но для меня это было новым и неожиданным решением. Надеюсь, поможет кому-то еще.

Да хранит вас Нуралиев!

бэкап расшифровка mxl

См. также

Журнал изменений с восстановлением состояния ссылочных объектов и архивацией по HTTP / COM (расширение + конфигурация, 8.3.14+, ЛЮБАЯ конфигурация)

Архивирование (backup) Журнал регистрации Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал изменений для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма "История изменений"! Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

19200 руб.

15.05.2017    42473    10    24    

38

BackUPv8 - система резервного копирования баз 1С

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Автоматическое создание копий файловых и серверных информационных баз 1С Предприятие 8 и размещение копий в облаке Яндекс.Диск, локальном или сетевом ресурсе.

1200 руб.

03.09.2014    14676    12    6    

17

Резервное копирование журнала транзакций, наконец-то!

Архивирование (backup) Администрирование СУБД Россия Бесплатно (free)

Постараюсь объяснить, зачем нужно резервное копирование именно журнала транзакций, а не только базы данных, и почему я словно сбросил груз, настроив его - как, покажу, естественно. Кстати, будут скрипты T-SQL (с подробными комментариями) - отличный способ сделать администрирование базы более уютным.

04.12.2023    5712    n_mezentsev    15    

23

Резервное копирование и восстановление 1С баз на PostgreSQL в Windows с помощью pgAdmin, bat-файлов и планировщика

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной инструкции будет описано, как с помощью pgAdmin, bat-файлов и планировщика заданий Windows организовать резервное копирование, восстановление и хранение копий баз данных.

07.10.2022    19498    sapervodichka    36    

140

Архивирование базы в dt и дамп postgres

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Захотелось клиентам выгрузку архива баз, и выгрузку в дт, готовые скрипты с сети не заработали. Может, кому-то поможет. Релиз 8.3.18.1741.

1 стартмани

25.08.2022    4680    2    Gnom-Gluck    6    

6

Утилита копирования баз данных 1С

Архивирование (backup) Платформа 1С v8.3 Абонемент ($m)

Небольшая утилита для копирования файловых баз данных 1С.

1 стартмани

02.06.2022    4216    3    Giblarium    12    

5
Отзывы
17. speshuric 1326 23.01.17 10:33 Сейчас в теме
(6) Что-то мне кажется, что это слишком оптимистично:
Проще по журналу транзакций откатить базу на 4 минуты назад.

Для восстановления на точку во времени по журналу транзакций нужно:
1. Чтобы БД была на SQL сервере и модель полная. Ситуация частая, но не 100%
2. Права на восставноление БД на SQL сервере (их может и не быть)
3. Нужно много времени. Для восстановления нужно: отрубить всех, восстановить предыдущий полный, восстановить предыдущий разностный (если есть), восстановить цепочку ЖТ.
4. Быть уверенным, что при этом не потеряются другие критичные данные, введенные/измененные за эти 4 минуты.

Понятно, что этой обработке не место на продакшене, но в качестве инструмента разработчика/тестировщика на своей среде - отличный пример.
alest; thevist; dark_wolf; JohnyDeath; pbazeliuk; ogroup; +6 Ответить
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. oleshko_alexey 2 20.01.17 14:15 Сейчас в теме
а скорость работы какая?
10000 позиций - транзакция нажна
8. ogroup 279 23.01.17 05:55 Сейчас в теме
(1) Алексей, не мерил, но для 2-5 тысяч позиций вполне приемлемая, секунд 12-15.
2. sokol_6630 3 21.01.17 17:33 Сейчас в теме
Лучше в excel сохранить и потом при загрузке при помощи метода Range сохранить все нужные данные в Таблицу значений и потом уже из нее восстанавливать нужные данные. А таким методом каждый раз приходится получать область с данными, это не слишком быстро.
3. Lem0n 420 22.01.17 01:09 Сейчас в теме
ВыгрузкаЗагрузка между идентичными конфигурациями на ИТС
ИНТЕГРА; SuhoffGV; mmch; baracuda; +4 Ответить
4. davdykin 25 22.01.17 23:55 Сейчас в теме
С выгрузкой/загрузкой все хорошо пока вы конфигурацию не поменяли, опять же фильтр писать надо, а это способ. По производительности думаю не особо, но так и делается он на всякие пожарный, а не как средство переноса.
alest; olbu; ogroup; +3 Ответить
5. PrinzOfMunchen 83 23.01.17 05:17 Сейчас в теме
Денис, а если просто таблицу значений сохранить в файл через "ЗначениеВСтрокуВнутр"? При восстановлении через "ЗначениеИзСтрокиВнутр" ссылки остаются.
А есть ещё и сериализация стандартных объектов...
Но да, можно и так, конечно ))
9. ogroup 279 23.01.17 05:59 Сейчас в теме
(5) Вся фишка этой штуки в том, что не нужно ничего писать предварительно. в 99% случаев вы пишите запрос в консоли, прежде чем запустить его в работу.
10. PrinzOfMunchen 83 23.01.17 06:04 Сейчас в теме
(9) Просто добавь в консольку кнопки сохранения/восстановления результатов запроса (таблицы значений). И всё будет работать намного быстрее, чем обход mxl в цикле.
6. collider 23.01.17 05:18 Сейчас в теме
Способ интересный, но мне кажется, что сложноват. Много надо держать в голове. Проще по журналу транзакций откатить базу на 4 минуты назад.
7. ogroup 279 23.01.17 05:54 Сейчас в теме
(6) В большинстве случаев, его нет (
11. webester 26 23.01.17 06:59 Сейчас в теме
(6)Вместе с со своими изменениями, откатить продажи, уже пробитые в ККМ чеки и созданные кем нибудь элементы справочников. Мои юзеры сразу убивают за такое .
CyberCerber; PrinzOfMunchen; ogroup; +3 Ответить
12. collider 23.01.17 07:45 Сейчас в теме
(11) Наверное полагается что то, что автор предложил, будет происходить в
1. Тестовой базе
2. Рабочей базе без пользователей (на случай необходимости отката)

А в рабочей базе и при этом с людьми в ней, я в любом случае не рискнул бы делать подобное. Выгружать в mxl и загружать обратно - это не такая уж и надёжная операция. Однажды что-то упустишь и будешь откатывать к ночному бэкапу продажи, уже пробитые в ККМ, чеки и созданные кем нибудь элементы справочников.
13. webester 26 23.01.17 08:50 Сейчас в теме
(12)Ну... как то упустил. У меня тестовая база в режиме восстановления "простая". В таком случае да, лог проще откатить.
17. speshuric 1326 23.01.17 10:33 Сейчас в теме
(6) Что-то мне кажется, что это слишком оптимистично:
Проще по журналу транзакций откатить базу на 4 минуты назад.

Для восстановления на точку во времени по журналу транзакций нужно:
1. Чтобы БД была на SQL сервере и модель полная. Ситуация частая, но не 100%
2. Права на восставноление БД на SQL сервере (их может и не быть)
3. Нужно много времени. Для восстановления нужно: отрубить всех, восстановить предыдущий полный, восстановить предыдущий разностный (если есть), восстановить цепочку ЖТ.
4. Быть уверенным, что при этом не потеряются другие критичные данные, введенные/измененные за эти 4 минуты.

Понятно, что этой обработке не место на продакшене, но в качестве инструмента разработчика/тестировщика на своей среде - отличный пример.
alest; thevist; dark_wolf; JohnyDeath; pbazeliuk; ogroup; +6 Ответить
19. ture 606 24.01.17 12:42 Сейчас в теме
(17)
Что-то мне кажется, что это слишком оптимистично:
Проще по журналу транзакций откатить базу на 4 минуты назад.


На заре юности и желторотости, я, к примеру, реально верил в это. Потом разок попробовал... получилось одного журнала почему-то мало. Долго не мог унять негодования. Но звучит то как красиво! - "на 4 минуты назад"

Жаль, что бакуп так "странно" устроен.
14. baracuda 2 23.01.17 08:56 Сейчас в теме
Один вопрос, а что если в запросе была допущена неочевидная ошибка, как часто бывает. Все данные в итоге коту под хвост.
Очень вредный совет. Как минимум я все равно перед операцией сделал бы бэкап данных.
alest; collider; +2 Ответить
15. ogroup 279 23.01.17 09:21 Сейчас в теме
(14) я здесь предполагаю, что запрос, выполняемый в запроснике, и запрос, выполняемый при изменении данных - один и тот же. Пусть даже и с ошибкой, но отработает он одинаково
16. Zhilyakovdr 142 23.01.17 10:29 Сейчас в теме
Превое. Изменение каких то больших массивов данных чаще всего делают ночью когда база свободна от пользователей.
Второе. В большинстве фирм которые дорожат своими данными кроме ночных бекапов делаются бекапы логов (у нас в организации каждые 5 минут)
Предположим вы сделали ошибку, сразу ее не заметили, прошло несколько дней.
Поднимается бекап на точку с корректными данными и как уже писали выше используется ВыгрузкаЗагрузка между идентичными конфигурациями.
Если структура изменилась то в том чтобы привести тестовую базу(из бекапа) в соответствие с боевой нет ничего сложного, особенно если вы используете хранилище.
Но самый лучший способ это не косячить на боевых серверах)))))
18. NN2P 414 24.01.17 11:59 Сейчас в теме
Бакуп сделал мой день!
Прикрепленные файлы:
ogroup; Светлый ум; DrAku1a; WellMaster; alevnev; JohnyDeath; +6 Ответить
20. МимохожийОднако 140 25.01.17 07:52 Сейчас в теме
Перед массовым изменениями в боевой базе. 1. Сделать архив. 2. Проверить на копии. 3. Внести изменения.
Хотя сама по себе идея интересная при тестировании.
SuhoffGV; +1 Ответить
21. didkovskij 44 25.01.17 10:08 Сейчас в теме
как вариант, с помощью обработки "Выгрузка и загрузка данных XML"
можно универсальной выгрузкой выгрузить данные в xml. Затем откатить простой загрузкой.
25. prog-1s 55 11.02.17 14:54 Сейчас в теме
(21) Самое простое решение, поддерживаю! Но вообще это актуально только при тестировании обработки. На рабочей базе лучше такие изменения делать в монопольном режиме.
22. Angealtor 32 25.01.17 10:17 Сейчас в теме
Автор скорее всего свое решение предлагает использовать в случаях, когда один из менеджеров компании меняет несколько реквизитов (100-10000) у определенной группы товаров,например, и допускает ошибку. Т.е. способ предназначен преимущественно для справочников.
23. DrAku1a 1678 26.01.17 02:31 Сейчас в теме
Примерно так:
1. ЗначениеВФайл / ЗначениеИзФайла
2. ЗначениеВСтрокуВнутр / ЗначениеИзСтрокиВнутр
3. XML-сериализация (обработка "Выгрузка-загрузка данных в формате XML", вроде есть на ИТС и для 8.2, и для 8.3)
Прикрепленные файлы:
24. Probot1c 04.02.17 06:00 Сейчас в теме
Способ интересный, но я пользуюсь утилитой ежедневного (недельного) копирования БД ..effector saver (если кому понадобится)
Оставьте свое сообщение