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

0. Евгений Гордеев (konstanta online) 33 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) 33 04.10.17 10:13 Сейчас в теме
(1)
2) создал в ней представления (скриптом) на таблицы базы ,из которой нужно сделать дт

Интересно, как вы думаете зачем 1С тогда сделала возможность резервирования только в монопольном режиме?
Что будет с содержимым вашего архива, когда бекап делается минут 30, а за эти 30 минут пользователи активно вводят данные?
user821186; Brawler; +2 Ответить
2. Uladzimir - (nvv1970) 03.10.17 22:10 Сейчас в теме
Читаешь, читаешь... Виртуализация, скрипты, быстрый PG, бэкапы, все автоматизировано... Все как во сне... А потом бац!... выгрузка в ДТ. ((( Рука лицо.
Кому он вдруг понадобился при таком уровне автоматизации администрирования??
Anchoret; uri1978; Brawler; tsukanov; +4 Ответить
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) 33 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с сервер... беда...)
В конце концов администратор БД всегда придет на помощь и покажет как и что делается. Да и гугл кагбэ есть.
Разработка в файловом варианте тестовой базы (только если заказчик не пользует файловый) - нонсенс и дилетантство.
kotloff; GeRon; manlak; uri1978; wbazil; Brawler; Spacer; Saint13; gorakh; artempo; mickey.1cx; +11 1 Ответить
6. Евгений Гордеев (konstanta online) 33 04.10.17 10:01 Сейчас в теме
(5)
Никто ведь и не говорит, что бекап средствами sql делается медленно. Наше облако делает 4-х кратное резервирование и файловой системой и резервными хранилищами и бекапами целиком виртуальных машин с sql и средствами sql. Статья называется "Как делать бекапы в dt в онлайн режиме". О том и речь.
У нас в облаке есть и большие базы и по 50Гб и больше. В них, действительно программисты вынуждены вести разработку в режиме клиент-сервер, но большая часть баз - это средние организации с количеством рабочих мест 5-20 с базами по 2-5Гб со своими сторонними программистами, которые подключаются к нам в облако и быстро вносят какие-либо правки "по старинке" в свою файловую базу.
CyberCerber; frkbvfnjh; +2 Ответить
10. Антон Стеклов (asved.ru) 33 04.10.17 11:11 Сейчас в теме
(6) Таким заголовком статьи Вы укореняете мысль о том, что dt - это бэкап.
В то же время 1С не рекомендует использовать выгрузку в dt для целей резервного копирования.
kotloff; tiniji; grumagargler; Saint13; grfru; artempo; +6 Ответить
12. Роман Симаньков (Sprinter2000) 04.10.17 11:15 Сейчас в теме
(10) Плюс еще в зависимости от варианта клиент-сервера можно выловить различные проблемы. dt не всегда можно легко выгрузить в связке PostgreSQL+1C сервер х32
15. Uladzimir - (nvv1970) 04.10.17 13:26 Сейчас в теме
(6)
У нас в облаке есть и большие базы и по 50Гб и больше. В них, действительно программисты вынуждены вести разработку в режиме клиент-сервер, но большая часть баз - это средние организации с количеством рабочих мест 5-20 с базами по 2-5Гб со своими сторонними программистами

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

программисты вынуждены вести разработку в режиме клиент-сервер
правки "по старинке" в свою файловую базу
Неверная формулировка. Это не "по старинке" или "вынуждены", нет. Это правильное программирование и тестирование того функционала, который крутится у заказчика.
Думаю, что не нужно объяснять, что при "правильном" программировании конфа должна быть работоспособна и в к-с и в файловом варианте.
18. Андрей Лукин (frkbvfnjh) 207 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) 328 04.10.17 21:02 Сейчас в теме
(5) 300+ гиговая база у нас на кластере за 15 минут бэкапится со сжатием до 47 гигов средствами MS SQL.
Если выгружать в DT это будет дольше, да и потом этот DT можно засунуть себе куда подальше, так как из него не развернуть файловую базу...

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

Только для маленьких баз приведенный в статье материал.
24. Сан Саныч (herfis) 181 05.10.17 14:21 Сейчас в теме
(17) Если цифра "300+ гигов" взята из свойства "Размер", то это вообще ни о чем еще не говорит. Подозреваю, что реальных данных, которые и бэкапятся, там гиг на 50. Ну, может, 60. Можете убрать сжатие бэкапов и сравнить. Не так уж сильно оно и жмет.
25. Игорь Фелькер (Brawler) 328 05.10.17 16:19 Сейчас в теме
(24) это именно живые данные на 300 гигов
а как известно там сплошной текст и числа
а все это дело архиваторы любя и жмут довольно таки бодро
ну и не стоит забывать, что в базе есть и двоичные данные выраженные в изображениях
26. Сан Саныч (herfis) 181 05.10.17 17:00 Сейчас в теме
(25) О как. Неслабо. А какой же у вас тогда размер базы (mdf+ldf, именно этот размер management studio показывает в свойствах базы как "размер базы")?
33. Александр Потапов (tiniji) 147 10.10.17 15:38 Сейчас в теме
(26) Нормально SQL жмет. 84 Гб реальных данных сжимает до 13-14 Гб архив. PostgreSQL еще сильнее сжимает, но и восстанавливает дольше.
42. Сан Саныч (herfis) 181 12.10.17 09:58 Сейчас в теме
(33) Каюсь, был неправ. А постгри, кстати, просто тупо индексы не бэкапирует и при восстановлении их полностью пересоздает. Поэтому и размер меньше / восстановление дольше.
8. Виктор Пинчуков (viptextil) 33 04.10.17 10:42 Сейчас в теме
Идея хороша, и действительно позволяет экономить ресурсы, но место
У нас процесс автоматизирован, поэтому время между CHECKPOINT и снапшотом составляет доли секунды. Таким образом мы получаем клон файловой системы PostgreSQL на момент времени.
Вызывает некоторое сомнение. Конечно, уменьшение времени позволяет минимизировать риски, но не устраняет их полностью. А так идея очень хороша.
13. Сан Саныч (herfis) 181 04.10.17 11:18 Сейчас в теме
(8) Думаю, риски пренебрежимо малы. Запас времени до очередного чекпоинта существенный, а снапшот сделается фактически мгновенно. Так что идея выглядит вполне себе рабочей.
11. Сан Саныч (herfis) 181 04.10.17 11:12 Сейчас в теме
Прикольно. С интересом почитал про zfs.
Плюс Лустин рассказывал, что использование zfs для 1С на postgres дает хорошие результаты в суровом продакшене...
Надо двигаться в эту сторону :)
14. Сан Саныч (herfis) 181 04.10.17 11:44 Сейчас в теме
Пользуясь случаем спрошу. А есть какие-то тонкости в настроках той же zfs? Ну типа "перед началом работы сразу нужно изменить такие-то и такие-то настройки по такому-то принципу"? А то спросил админов, говорят пробовали экспериментировать с zfs и остались вопросы. Типа память любит сильно и заметная деградация производительности наблюдалась...
31. Евгений Гордеев (konstanta online) 33 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) 33 09.10.17 11:16 Сейчас в теме
(19)
Именно )
И у нас не скрипты, а специально разработанная конфигурация для обслуживания Датацентра.
20. Максим Князев (mad_maksim) 82 05.10.17 10:12 Сейчас в теме
Тот случай, когда комментарии интереснее статьи )
21. Антон Грачев (Fragster) 722 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) 147 08.10.17 05:09 Сейчас в теме
Только линуксоид может сделать задачу за тонну времени и сил, которая настраивается на MS SQL за 5 минут (со всеми проверками)
DT самый ненадежный архив
32. Сан Саныч (herfis) 181 10.10.17 09:40 Сейчас в теме
34. Александр Потапов (tiniji) 147 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) 181 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) 147 12.10.17 14:55 Сейчас в теме
(43) С Вами бесмысленно спорить. Кто в теме, тот поймет что это 48 бэкапов журнала транзакций к полной копии.
45. nick perel (nickperel) 2 12.10.17 19:15 Сейчас в теме
44)Чета не понял, я начал с кем-то спорить что ли? Храни 48 журналов. Молодец.
Многие сисадмины с которыми имеют дела многие программисты 1с хранят только полные ночные копии. И что?
А задача топика выдать ВСЕ данные на СТОРОНУ. И что?
Оставьте свое сообщение