Резервное копирование "онлайн" клиент-серверных баз в dt (не отключая пользователей)

0. Евгений Гордеев (konstanta online) 66 03.10.17 14:48 Сейчас в теме
Как реализовать резервное копирование клиент-серверных баз 1с в формат dt, не отключая пользователей.
Рассматривается способ, делающий резервирование наименее заметным для пользователей и серверного оборудования.

Перейти к публикации

Комментарии
1. Михаил Максимов (МихаилМ) 03.10.17 21:35 Сейчас в теме
для ms sql я делал dt ,не выгоняя пользователей так
1) создал пустую базу в мс скл для выгрузки в дт
2) создал в ней представления (скриптом) на таблицы базы ,из которой нужно сделать дт
3) создал базу в кластере ручками (но сейчас можно скриптом)
4) выгрузил дт ручками (сейчас можно скриптом).

думаю такое можно сделать и в postgresql. ведь чудес не бывает - и за использование COW все равно расплачиваетесь падением производительности.
7. Евгений Гордеев (konstanta online) 66 04.10.17 10:13 Сейчас в теме
(1)
2) создал в ней представления (скриптом) на таблицы базы ,из которой нужно сделать дт

Интересно, как вы думаете зачем 1С тогда сделала возможность резервирования только в монопольном режиме?
Что будет с содержимым вашего архива, когда бекап делается минут 30, а за эти 30 минут пользователи активно вводят данные?
kadild; echo77; user747571; user852781; user821186; Brawler; +6 Ответить
2. Uladzimir - (nvv1970) 03.10.17 22:10 Сейчас в теме
Читаешь, читаешь... Виртуализация, скрипты, быстрый PG, бэкапы, все автоматизировано... Все как во сне... А потом бац!... выгрузка в ДТ. ((( Рука лицо.
Кому он вдруг понадобился при таком уровне автоматизации администрирования??
o.egorova.omsu; Liris; kadild; Anchoret; uri1978; Brawler; tsukanov; +7 Ответить
3. Михаил Максимов (МихаилМ) 03.10.17 22:39 Сейчас в теме
(2)
не все разработчики могут (могли) позволить себе для разработки купить 1с серверную.
поэтому им для работы в файловой базе нужна "урезанная" версия рабочей базы.
сейчас можно и не урезать.
9. Роман Симаньков (Sprinter2000) 04.10.17 11:06 Сейчас в теме
(3) Не особая проблема, если что-то не специфическое и привередливое. Linux+Postgresql+1C server x32. До 12 подключений лицензию на сервер не надо, пока-что
4. Евгений Гордеев (konstanta online) 66 04.10.17 00:06 Сейчас в теме
(2)
Читаешь, читаешь... Виртуализация, скрипты, быстрый PG, бэкапы, все автоматизировано... Все как во сне... А потом бац!... выгрузка в ДТ. ((( Рука лицо.
Кому он вдруг понадобился при таком уровне автоматизации администрирования??


Странный вопрос ) Именно программисты и спрашивают. У нас в облаке кроме пользователей крутятся и сторонние программисты. И на удивление, им зачем-то постоянно нужны именно свежие dt для доработок клиента. Часто еще сервер хранилища конфигураций просят настроить. Наверное, все-таки разработка на локальной файловой базе идет быстрее.
5. Uladzimir - (nvv1970) 04.10.17 08:51 Сейчас в теме
(4) Когда база переваливает за десятки гигов, то про какую выгрузку может идти речь? Тот же ms делает уже сжатый бэкап от силы пару минут... (на днях демонстрировал человеку: 17 Гб чистых данных (30Гб база) у меня на ноуте забэкапились за 20-30 сек.), а выгрузка в ДТ - это минут 10-20 может быть. А что делать с базами в 100, 500, 1000 Гб??
Программист должен владеть основными операциями СУБД. MS владеют все. PG отдельные. Если это не так - то это еще не программист. (недавно коллега спросила как установить себе на комп 1с сервер... беда...)
В конце концов администратор БД всегда придет на помощь и покажет как и что делается. Да и гугл кагбэ есть.
Разработка в файловом варианте тестовой базы (только если заказчик не пользует файловый) - нонсенс и дилетантство.
o.egorova.omsu; Liris; Danil.Potapov; user747571; kotloff; GeRon; manlak; uri1978; wbazil; Brawler; Spacer; Saint13; gorakh; artempo; mickey.1cx; +15 1 Ответить
6. Евгений Гордеев (konstanta online) 66 04.10.17 10:01 Сейчас в теме
(5)
Никто ведь и не говорит, что бекап средствами sql делается медленно. Наше облако делает 4-х кратное резервирование и файловой системой и резервными хранилищами и бекапами целиком виртуальных машин с sql и средствами sql. Статья называется "Как делать бекапы в dt в онлайн режиме". О том и речь.
У нас в облаке есть и большие базы и по 50Гб и больше. В них, действительно программисты вынуждены вести разработку в режиме клиент-сервер, но большая часть баз - это средние организации с количеством рабочих мест 5-20 с базами по 2-5Гб со своими сторонними программистами, которые подключаются к нам в облако и быстро вносят какие-либо правки "по старинке" в свою файловую базу.
user852781; CyberCerber; frkbvfnjh; +3 Ответить
10. Антон Стеклов (asved.ru) 33 04.10.17 11:11 Сейчас в теме
(6) Таким заголовком статьи Вы укореняете мысль о том, что dt - это бэкап.
В то же время 1С не рекомендует использовать выгрузку в dt для целей резервного копирования.
o.egorova.omsu; kadild; olgerd666; echo77; japopov; kotloff; tiniji; grumagargler; Saint13; grfru; artempo; +11 Ответить
12. Роман Симаньков (Sprinter2000) 04.10.17 11:15 Сейчас в теме
(10) Плюс еще в зависимости от варианта клиент-сервера можно выловить различные проблемы. dt не всегда можно легко выгрузить в связке PostgreSQL+1C сервер х32
56. Александр Крынецкий (echo77) 780 08.12.17 15:50 Сейчас в теме
(10) Поддержу - выгрузка дампа базы в dt - это не архивирование, хотя и выглядит, вроде кошерно, выполняется из конфигуратора.
Правильное архивирование файловой базы - это копирование содержимого каталога, когда в базе никого нет, серверной базы - бэкап средствами СУБД
olgerd666; +1 Ответить
15. Uladzimir - (nvv1970) 04.10.17 13:26 Сейчас в теме
(6)
У нас в облаке есть и большие базы и по 50Гб и больше. В них, действительно программисты вынуждены вести разработку в режиме клиент-сервер, но большая часть баз - это средние организации с количеством рабочих мест 5-20 с базами по 2-5Гб со своими сторонними программистами

Ключевое то что у вас облако и мелкие базы. И вы с программистами по разные стороны барикад. ))) Конечно это метод. Идея известная. За публикацию респект.
Я, например, работаю с клиентами >50Гб. Поэтому и другой взгляд на вещи.

программисты вынуждены вести разработку в режиме клиент-сервер
правки "по старинке" в свою файловую базу
Неверная формулировка. Это не "по старинке" или "вынуждены", нет. Это правильное программирование и тестирование того функционала, который крутится у заказчика.
Думаю, что не нужно объяснять, что при "правильном" программировании конфа должна быть работоспособна и в к-с и в файловом варианте.
18. Андрей Лукин (frkbvfnjh) 254 05.10.17 06:12 Сейчас в теме
(6)
Статья называется "Как делать бекапы в dt в онлайн режиме". О том и речь.
Полностью согласен. Кто там и чего рекомендует, это вопрос другой, а данная статья может многим быть полезной. Любой дурак может выгрузить бэкап правильно, только не всем дуракам удобно таким бэкапом пользоваться...
35. Kembrik (kembrik) 11.10.17 11:50 Сейчас в теме
(6)
В них, действительно программисты вынуждены вести разработку в режиме клиент-сервер, но большая часть баз - это средние организации с количеством рабочих мест 5-20 с базами по 2-5Гб со своими сторонними программистами, которые подключаются к нам в облако и быстро вносят какие-либо правки "по старинке" в свою файловую базу.


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

Я как раз из тех "сопровождающих", у которого свой аккаунт на облаке, а клиентов я туда привожу по партнерке. И в моём случае ТП облака пошли навстречу - одна и та же SQL база видна и у меня,и у сопровождаемых мною клиентов, и есть одна "собственная" SQL база "Текущий клиент" (на сервере с отладкой), куда мне ТП делает копию базы по моему запросу (средствами MS SQL конечно)

А у вас с точки зрения технаря вроде всё нормально сделано - "Задачу поставили - задачу решили", а вот с точки зрения бизнеса и бизнес-заказчиков - костыль, Я уж молчу про безопасность - ведь получается вы физически знаете логин/пароль пользователя ПП, раз сами выгрузку инициируете в dt? - значит возможностей для злоупотребления у сотрудников облака куда как больше
17. Игорь Фелькер (Brawler) 343 04.10.17 21:02 Сейчас в теме
(5) 300+ гиговая база у нас на кластере за 15 минут бэкапится со сжатием до 47 гигов средствами MS SQL.
Если выгружать в DT это будет дольше, да и потом этот DT можно засунуть себе куда подальше, так как из него не развернуть файловую базу...

Тогда зачем нужен этот DT спрашивается)))

Только для маленьких баз приведенный в статье материал.
24. Сан Саныч (herfis) 213 05.10.17 14:21 Сейчас в теме
(17) Если цифра "300+ гигов" взята из свойства "Размер", то это вообще ни о чем еще не говорит. Подозреваю, что реальных данных, которые и бэкапятся, там гиг на 50. Ну, может, 60. Можете убрать сжатие бэкапов и сравнить. Не так уж сильно оно и жмет.
25. Игорь Фелькер (Brawler) 343 05.10.17 16:19 Сейчас в теме
(24) это именно живые данные на 300 гигов
а как известно там сплошной текст и числа
а все это дело архиваторы любя и жмут довольно таки бодро
ну и не стоит забывать, что в базе есть и двоичные данные выраженные в изображениях
26. Сан Саныч (herfis) 213 05.10.17 17:00 Сейчас в теме
(25) О как. Неслабо. А какой же у вас тогда размер базы (mdf+ldf, именно этот размер management studio показывает в свойствах базы как "размер базы")?
33. Александр П. (tiniji) 148 10.10.17 15:38 Сейчас в теме
(26) Нормально SQL жмет. 84 Гб реальных данных сжимает до 13-14 Гб архив. PostgreSQL еще сильнее сжимает, но и восстанавливает дольше.
42. Сан Саныч (herfis) 213 12.10.17 09:58 Сейчас в теме
(33) Каюсь, был неправ. А постгри, кстати, просто тупо индексы не бэкапирует и при восстановлении их полностью пересоздает. Поэтому и размер меньше / восстановление дольше.
8. Виктор Пинчуков (viptextil) 33 04.10.17 10:42 Сейчас в теме
Идея хороша, и действительно позволяет экономить ресурсы, но место
У нас процесс автоматизирован, поэтому время между CHECKPOINT и снапшотом составляет доли секунды. Таким образом мы получаем клон файловой системы PostgreSQL на момент времени.
Вызывает некоторое сомнение. Конечно, уменьшение времени позволяет минимизировать риски, но не устраняет их полностью. А так идея очень хороша.
13. Сан Саныч (herfis) 213 04.10.17 11:18 Сейчас в теме
(8) Думаю, риски пренебрежимо малы. Запас времени до очередного чекпоинта существенный, а снапшот сделается фактически мгновенно. Так что идея выглядит вполне себе рабочей.
11. Сан Саныч (herfis) 213 04.10.17 11:12 Сейчас в теме
Прикольно. С интересом почитал про zfs.
Плюс Лустин рассказывал, что использование zfs для 1С на postgres дает хорошие результаты в суровом продакшене...
Надо двигаться в эту сторону :)
14. Сан Саныч (herfis) 213 04.10.17 11:44 Сейчас в теме
Пользуясь случаем спрошу. А есть какие-то тонкости в настроках той же zfs? Ну типа "перед началом работы сразу нужно изменить такие-то и такие-то настройки по такому-то принципу"? А то спросил админов, говорят пробовали экспериментировать с zfs и остались вопросы. Типа память любит сильно и заметная деградация производительности наблюдалась...
31. Евгений Гордеев (konstanta online) 66 09.10.17 11:20 Сейчас в теме
(14)
Для PostgreSQL желательно кластер статического размера.
Мы для датасета назначаем 4k
16. Роман Симаньков (Sprinter2000) 04.10.17 14:16 Сейчас в теме
Все что слышал это тоже, что память очень любит, особенно для дедупликации. А кроме этого только положительные отзывы. Но сам не пробовал. И в продакшене под того же слона тоже не гонял.
19. Vladimir K (KroVladS) 05.10.17 09:37 Сейчас в теме
Где готовые скрипты?
Или Вы похвастаться решили, какие Вы молодцы?
30. Евгений Гордеев (konstanta online) 66 09.10.17 11:16 Сейчас в теме
(19)
Именно )
И у нас не скрипты, а специально разработанная конфигурация для обслуживания Датацентра.
20. Максим Князев (mad_maksim) 84 05.10.17 10:12 Сейчас в теме
Тот случай, когда комментарии интереснее статьи )
21. Антон Грачев (Fragster) 767 05.10.17 12:07 Сейчас в теме
пгдамп > 7зип > неткат ....сеть... неткат > 7зип > пгрестор, и всё одним .sh файлом можно сделать с компа разработчика
22. Артем К. (Artemka20121) 5 05.10.17 12:12 Сейчас в теме
(0) создать базу для бэкап_дт ... сделать скульный бэкап + развернуть в бэкапдт ->сделать выгрузку в дт файл
все можно сделать командной строчкой
23. nick perel (nickperel) 2 05.10.17 13:08 Сейчас в теме
Клоны какие-то... Виртуализация... В одном месте на бакапе экономим, в другом 1сные dump заряжаем. Мрак..
Этот dt-шник программерам нужен не часто. Чаще им надо потестироваться на актуальных данных. И они могут делать это прямо на копии по vpn или http. И зачем вгонять СУБД и кластер 1С в виртуальные машины? От этого им сразу нехорошо.

pg_dump из рабочей
pg_restore в копию с --clean
и 1cv8.exe .... /DumpIB и все это ночью или раз в неделю

Сисадмины любят снэпшоты. А здесь мгновенный способ выкинуть насторону dtшник, не теребя дампом сервер платящих клиентов.
Правда сервер будет пережевывать всю эту виртуализацию, имея по тесту гилева 8-11 попугаев, ну а так у большинства т.н. "продакшенов" в рф . Часто ли платят за повышение количества попугаев?
Годный прием сисадминства - "откинь проблемы эффективно". К ней еще прилагается - "работает - не трожь"
27. opera opera (opera199) 26 06.10.17 13:39 Сейчас в теме
Зачастую перед выгрузкой в .dt необходимо почистить некоторые таблицы, чтобы они не превышали 4гб, иначе dt-шник не загрузится в файловую базу.
28. Валерий М (VmvLer) 06.10.17 14:00 Сейчас в теме
В предисловии темы автором указан аргумент против стандартных бекапов из СУБД:

В этом случае возникает только одно неудобство: Чтобы развернуть такую базу хотя бы в копию, нужен работающий SQL сервер, желательно не тот, где развернута рабочая база, также нужны навыки работы с SQL сервером.


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


зачем мне еще больше переменных при решении подобных задач?
36. nick perel (nickperel) 2 11.10.17 20:09 Сейчас в теме
(28)у него задача - выкинуть проблему суппорта актуальными данными внешних программеров вон из рабочего сервера, чтобы дампом в dt не тормозили рабочую среду.
Этот дамп - единственная многонитевая\многопроцессорная функция в платформе.
Поэтому все завиртуалено. Тонна компромиссов. Не нужно все это, когда мало данных.
29. Александр П. (tiniji) 148 08.10.17 05:09 Сейчас в теме
Только линуксоид может сделать задачу за тонну времени и сил, которая настраивается на MS SQL за 5 минут (со всеми проверками)
DT самый ненадежный архив
32. Сан Саныч (herfis) 213 10.10.17 09:40 Сейчас в теме
34. Александр П. (tiniji) 148 10.10.17 15:47 Сейчас в теме
(32) Читал, Вы можете назвать таких специалистов, которые по данной статье завтра смогут так-же все настроить ? И много таких админов в регионах ? Если тут пишут про то, что 1с-ник не может сделать бэкап и рестор средствами СУБД, я уже молчу тогда про сис. админов.

P.S. Статья узкоспециализированная под конкретную задачу, под конкретную СУБД, написанная скорее всего системным администратором.
38. nick perel (nickperel) 2 11.10.17 20:21 Сейчас в теме
(34)
Вы можете назвать таких специалистов, которые по данной статье завтра смогут так-же все настроить

А что тут сложного? Если 1Сник это не может, то не знаю для чего он нужен.
У 1сника работа - данные, а не игра в глупенькие разборки "сисадмин против 1сника".

Этот метод вполне рабочий, если перекидывается большими данными в 300, 500 Gb - 1 Tb.
41. Сан Саныч (herfis) 213 12.10.17 09:49 Сейчас в теме
(34) Если бы читали, то не было бы этого абсолютно неуместного выпада linux vs ms
Банальное бэкапирование (сюрприз!) и на линуксе делается не менее банально, чем на ms
Статья про другое. Как вы правильно заметили - она про решение конкретной узкой задачи. Про очень эффективное решение. Только вы ошиблись - суть предлагаемой технологии не является специфичной для конкретной СУБД, несмотря на то что описывается она в приложении к postgresql.
А если вам не нравится, что она выходит за рамки пресловутой "привычной области знаний рядовых одинэсников", то это каким-то луддизмом попахивает, извините.
37. nick perel (nickperel) 2 11.10.17 20:15 Сейчас в теме
(29)Теперь нет. dt проверяется в процессе.
1С имеет в виду что dt не заменит бакап SQL сервера. Речь не про надежность, речь про то что sql-ный бакап может быть сделан он-лайн и восстановиться на момент времени.
39. nick perel (nickperel) 2 11.10.17 20:29 Сейчас в теме
(29)а sqlный бакап может спокойно слить в архив базу, которая убита некорректным динамическим обновлением.
И затереть предыдущий архивчик в том же задании.
Такие дела с надежностью..
40. Валерий М (VmvLer) 12.10.17 08:24 Сейчас в теме
(39) если архивы нон-стоп и хранить последние скажем 48, то у вас будут архивы на каждый час, правда у нас период 20 минут.

таким образом, чтобы ни происходило в течение 2-х суток - риски минимизированы. Ну а если вы в течение 2-х суток не заметили проблем с базой, то это уже проблемы квалификации
43. nick perel (nickperel) 2 12.10.17 12:15 Сейчас в теме
(40)Попробуй хранить 48, если база гигабайт 700. эльфы
44. Александр П. (tiniji) 148 12.10.17 14:55 Сейчас в теме
(43) С Вами бесмысленно спорить. Кто в теме, тот поймет что это 48 бэкапов журнала транзакций к полной копии.
45. nick perel (nickperel) 2 12.10.17 19:15 Сейчас в теме
44)Чета не понял, я начал с кем-то спорить что ли? Храни 48 журналов. Молодец.
Многие сисадмины с которыми имеют дела многие программисты 1с хранят только полные ночные копии. И что?
А задача топика выдать ВСЕ данные на СТОРОНУ. И что?
46. sinops sinops (sinops) 27.10.17 17:20 Сейчас в теме
Очередной не очень понятный велосипед.
Как уже говорили dt файл не самый лучший вариант хранения, я один раз столкнулся что база из dt не грузиться и ни как было не поднять.
Зато видел на ms sql базу битую , она работала, но не тестировалась и не с сохранялась штатными средствами, зато бекапы sql работали на ура.
По поводу нужны разработчикам dt.... Если база более 4 гигов, то быстрее её разворачивать из бекапа sql чем из dt, и если разработчик в теме он знает как поставить себе на рабочем месте сервер 1С для личного использования.
47. Евгений Гордеев (konstanta online) 66 30.10.17 11:44 Сейчас в теме
В dt онлайн выгружаем по следующим причинам:
1. Мы это можем.
2. Это требования облачных договоров. Чтобы клиенты облака могли периодически забирать архивы своих баз. Все-таки в dt они имеют наименьший размер.
Для чего делались этот механизм и другие интересные решения благодаря возможностям платформы виртуализации на нашем вебинаре:
Вебинар: Облако 1С с ориентиром на разработчиков
48. Сан Саныч (herfis) 213 30.10.17 16:01 Сейчас в теме
(47) По сути, вы предоставляете выгрузки баз (для чего dt и нужен), а не делаете резервное копирование. Поэтому вы зря подставились, написав в статье про "резервное копирование". С другой стороны, каждый кто будет рад в это ткнуть, будет поднимать тему :)
50. Евгений Гордеев (konstanta online) 66 30.10.17 16:19 Сейчас в теме
(48)
Делаем и резервное копирование причем 2-х кратное, с дублированием на резервное хранилище архивов ). Резервные копии делаются целиком виртуальных машин. И я об этом писал выше. Так, что вы зря думаете, что у нас облако резервируется только выгрузками в dt.
Просто наши резервные копии виртуальных машин исключительно для внутреннего использования у нас и никак не интересны нашим партнерам и фрилансерам, которые располагаются у нас в облаке.
52. Сан Саныч (herfis) 213 30.10.17 18:03 Сейчас в теме
(50) Я хвалил вас за использование выгрузки в dt по назначению, а не обвинял в отсутствии бэкапов. Вы же не с целью резервирования данных осуществляете выгрузку в dt. А название статьи вводит в заблуждение.
49. Александр Семененко (al.semenenko88) 30.10.17 16:05 Сейчас в теме
Что-то у меня соменения, что таким образом можно много баз бекапить. Так все сервера лягут, если запустить бекап хотя-бы 5-и баз
51. Евгений Гордеев (konstanta online) 66 30.10.17 16:23 Сейчас в теме
(49)
У нас архивированием занимается управляющая база. В ней сейчас настроено ограничение на 15 параллельных бекапов. Конечно, когда они выполняются параллельно, то бекапы делаются несколько медленнее, но пользователям этого практически не видно. За бекапы отвечает специально предназначенный для этого хост.
53. Alexander Erastov (waterya) 31.10.17 16:25 Сейчас в теме
у меня давно сделано так:
вечером каждый раз снимается автоматом бэкап на MS SQL, далее он разворачивается также автоматом на копии базы, затем автоматом с этой копии выгружается dt - так на всякий случай, но это пока база в 8 гигов.
54. Сан Саныч (herfis) 213 31.10.17 16:51 Сейчас в теме
(53) Это самый надежный вариант.
Потому как если успешно выгружается dt, то это не просто верификация бэкапа, но и весомое подтверждение логической целостности данных в нем.
Но на больших данных такая схема проблематична из-за высокой ресурсоемкости.
ЗЫ. Хотя надежнее, наверное, запускать ТиИ в пакетном режиме. Там можно указать вывод результатов в лог и потом лог анализировать.
57. Антон Стеклов (asved.ru) 33 08.12.17 17:30 Сейчас в теме
(54)
Подтверждением целостности является успешная загрузка dt, а не выгрузка. Не путайте с pg_dump > /dev/null
55. Алексей Олешко (retif) 08.12.17 11:59 Сейчас в теме
Предлагаю изменить заголовок- указать что инструкция для Постгреса
Оставьте свое сообщение