Добрый день, с наступающим!
подскажите программу (я так полагаю, есть стандартные) для архивирования баз 1с (вроде они под определенным пользователем заходят и делают выгрузку).

Администрирование - Выгрузить?

7zip

или /DumpIB

(1) хотелось бы, чтобы раз в сутки выгружалось вне зависимости от сторонних сил

(4) используй магию скриптов и планировщика :)

(5) смешно)

(4) поставь (3) в планировщик заданий

(6) Где, где смешное, ткни носом?))

А вообще, тема не раскрыта...
В скуле backup database и всё...

(9) можно подробнее?
а еще проблема такая: база на postgresql, иногда сеансы не прекращаются, и висят те, которые были начаты несколько дней назад. их можно удалить только через администрирование. как тогда быть?

(10) Может лучше замуж?)) Ну ее, эту 1С

(11) может лучше архиватор и новый год?

(12) Ну тогда бросай смеятся и делай как сказано в (7) ))

(13) ок

(14) а еще есть Effector saver 3, специально для этого сделан

(15) понять не могу, он архив делает или выгрузку?

(16)выгрузку

"C:\Program Files\1cv82\8.2.15.289\bin\1cv8.exe" DESIGNER/F"D:\InfoBase3"/N"admin"/P"123"/DumpIB"C:\1c_backup\test.dt"/DumpResult"C:\1c_backup\test1.txt"/OUT"C:\1c_backup\test.txt"

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

проблема решилась после того, как поставила пробел после DESIGNER
ВСЕХ С НАСТУПАЮЩИМ НОВЫМ ГОДОМ!

а я уж хотел предложить /DisableStartupMessages ;)

(6) >> смешно)

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

Собственно и архивирование и обновление делается там скриптами и с использованием планировщика.

SQL-м архивировать не айс. Во первых места больше, во вторых восстанавливать базы проблемно. Доп. софт ставить тоже не надо. Почему? На сервере лишняя программа = самоубийству. За такое надо ссылать сразу на необитаемый остров, где нет компов и из сисек только макаки. Автор, на инфостарте валяются готовые скрипты для ГРАМОТНОЙ архивации восьмерки. Там выгонение пользователей, архивация и контроль версий, т.е. старые архивы удаляются. Мне кажется такой скрипт+планировщик самый оптимальный вариант

(22) сама 1с говорит, что нужно бекапить средствами скуля...

(23)1С так говорит для того, чтобы в случае чего им не предъявляли обвинений.

(24)+ У меня на всякий случай настроено архивирование SQL, но делается еще выгрузка. Причем со временем SQL-ные архивы удаляются, а выгрузки сохраняю. Так удобнее и места меньше занимают.

(23) У нас и так и так архивируется. Так вот скульными архивами ни разу не пользовались, а 1С-вскими постоянно пользуемся, потому что сама платформа универсальная и пользователь-программист абстрагируется от СУБД
(25) +100500 Наверное со временем и опытом все к этому приходят

(26) Вы, видимо, работали только с небольшими базами, и никогда не испытывали с ними проблем. Иначе бы такое не написали.
Единственное, в чем Вы правы - так это в объемах файла рез. копии: SQL-backup занимает больше места, чем выгрузка. Но есть средства борьбы и с этим.

(25) А ничего, что *.dt-шка может и не загрузиться, если в базе, с к-рой она снята, были проблемы?
Или сжимать sql-backup религия не позволяет?

(27) 100-130 гигабайт маленькая база? Хм, наверное ты прав
(28) А тебе религия позволяет измерить размер дт-шки и архивированного бакапа скуля?
Когда на предприятии используются разные СУБД, самый оптимальный - ДТ-шка. Зачем мне ставить на рабочий комп СКЛ2008? ЗАЧЕМ? Или извращаться с загрузкой бакапа на сервер, потом перегрузка в ДТ-шку... согласись это удел извращенцев? К тому же если база битая, то надо не об архивировании думать, а о пересадки рук с задницы на нормальное место

(29) 130 ГБ в файловую? О_о

(30) Постгре

Есть и маленькие базы от маленьких контор.

(28)Именно на этот случай дополнительно делается выгрузка средствами SQL. Чтобы в случае форс-мажора гарантированно иметь рабочую копию.

Вот прямо сейчас готовлю 40-ка гигабайтную базу к конвертации. По многочисленным представлениям мне надо ставить СКЛ2003 32-х разрядный, 64-х разрядный 2008 и постгре разных версий. А потом во всем этом ковыряться. Проще надо быть и делать все грамотно, что бы и время не расходовать зря и деньги предприятия

(31) Так у Вас 130-Гб база - файловая или Postgres? Вы не путайтесь в показаниях ;)
(29) И зачем ставить СКЛ-сервер "на свой рабочий компьютер"? На сервере его не достаточно, что ли?

(35) У меня много баз. Большая на МС СКЛ2008. Которую сейчас курочу - на МС СКЛ2003. И т.д.
"И зачем ставить СКЛ-сервер "на свой рабочий компьютер"? " вот когда будет у тебя большая нагрузка на все сервера, поймешь зачем

(34) Действительно, будьте проще. Для начала скажите: зачем вам неск. версий MS SQL?

(37) Разные конторы, разное железо, разные эникеи. Лучше ты скажи, что выигрываешь, работая на рабочих серверах и что теряешь? Замеры по производительности делал? Оценку рисков проводил?

(34) Особенно в связи с двумя версиями скуля про "деньги предприятия" понравилось. О "грамотности" я промолчу. Или скуль у вас без лицензии?

(39) Разные версии СКЛ - запуск/остановка в разных случаях, а если надо одновременно разные базы, тогда сразу встает вопрос о железе. Доп. лицензии тоже немного стоят. Ну и возня с копированием с разными методиками работ и админства выливается во время, а это тоже деньги, при чем нормальные по меркам простолюдинов.
На (38) ответь. Какие оценки проводил, при выборе методики работы "на рабочем сервере"

(39) Кто сказал, что у нас без лицензий? Я этого не говорил

(38) Так Вы конвертируете 130-гб базу (со скуля-2008, к поимеру) одного клиента в базу того же размера на др.версии скуля для другого клиента? А зачем вообще переносить базы между клиентами? Да еще и на разных СУБД

(42) Что я делаю с базой - детали. Зачем это все делается - другая тема. Базу я не переношу между клиентами, а привожу в нормальный вид, после таких любителей оценок по личному опыту. Слоны, блин.
Ответь на (38)

(33)В случае форс-мажора у тебя и так есть гарантированная копия: бэкап от скуля. Сожми его архиватором, если места свободного мало, и он будет занимать еще меньше, чем *.dt.

(44) Издеваешься? Проверял размеры то? Ответь на (38). От ответа сразу всем станет ясно почему поддерживаешь идею "только СКЛ-м бэкапить"

(45) товарищ, не впадайте в истерику. Что Вы все про оценку рисков да о производительности? Если Ваша рабочая станция мощнее, чем Ваш сервер - работайте на ней. Я не против.

(46) Просто это показатель рассуждений и принятия решения. Что-то мне подсказывает, что в вашем случае решение было принято просто так. Захотел - сделал.
А теперь попробуй представить, что будет с производительностью, когда бух начисляет амортизацию и в это время 2-4 разработчика запускают мощные обработки чегототампровести. Скажешь надо мощнее сервера покупать? Тогда скажи ЗАЧЕМ????? Что ты выигрываешь в том, что работаешь на сервере?

Одна база у нас работает круглосуточно и с большрй нагрузкой. Так вот автомат делает СКЛ-ем выгрузку. Им же загрузку в другую базу. Потом делает средствами 1С архив и кладет на полку

+(47) Хотя нет, есть случаи, когда надо работать на сервере. Например, когда нет своего компа

Ладно, всех с наступающим праздников пьянок и подарков.

(47) обработки "чего-то там провести" запускаются ночью. Автоматом, естесс-но. Или бухи у вас и ночью амортизацию рассчитывают?  
Это - элементарно, и для принятия такого решения выполнять замер проищводительности, чтоб определиться, "проскочит" проведение "чего-то там" или " не проскочит" - лишняя трата времени. Ясно, что "не проскочит"

А для переноса данных между базами в МС СКЛ есть и др. ср-ва, кроме бэкапов. Возможно, они вам подойдут лучше.

Короче, учите матчасть. Не повредит...

(50) Разработчики ночью не работают. Чем лучше бэкап средствами СУБД? Может поищешь плюсы и минусы? Я много вариантов испробовал. Прежде чем подойти к такой схеме я перепробовал очень много вариантов, в том числе и софт различный. Вот попадешь в крупную и серьёзную контору вспомнишь наш диалог. Особенно когда будут насиловать мозг по работе с 1С. После парочки раз, когда получишь выговоры или даже увольнения, очень задумаешься. Матчасть, блин...

(51) "Вот попадешь в крупную и серьёзную контору вспомнишь наш диалог." - ну-ну... "Спасибо, поржал" (с)

"Особенно когда будут насиловать мозг по работе с 1С." -
Вы учите, учите матчасть-то. Говорю же: не повредит!

А по делу: ну так чем же бэкап ср-вами самой 1С лучше бэкапирования ср-вами СУБД? (Если Вы "много вариантов испробовали" ? )

Или болтать - не мешки ворочать?

(52) "А по делу: ну так чем же бэкап ср-вами самой 1С лучше бэкапирования ср-вами СУБД?" читай выше: отвязанность от СУБД, частичная нормализация базы, меньший размер, гораздо бОльшая степень надежности, что данные будут не повреждены, т.к. делается без пользователей. Это именно то, что есть лучше бакапа средствами СУБД. А теперь попробуй наоборот плюсы СУБД привести, я уже и так дал кучу подсказок как надо правильно задумываться при оценки плюсов, минусов и рисков

Хм... если можно ради бэкапа выгнать пользователей или днем запускать 3-4 экземпляра перепроведенияЧегототам - это прямо ПпцКакаяКрупнаяСурьезнаяКонтора :)))

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

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


Вывод надуманно и притянуто за уши

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

(55) Да делай, что хочешь. С чего соплями брызжешь?

(56) Для военных: какие плюсы у бэкапа средствами СУБД? Народ, ну чесслово, может я чего-то не знаю, просветите.
Теперь по пунктам с разъяснениями:
- "частичная нормализация базы (бред, что есть нормализация базы и каким образом она к архивам)" одинэска своими средствами выгружает объекты и не трогает битые ссылки. На НГ я конвертировал базу. Так вот первый вариант выгрузки СКЛ-средствами дал мне базу, которая запускалась только на постгре (второй раз нормально). Ведь тупой МС СКЛ не знает, что мне нужна целостная база
- "бред, а бекап средствами СУБД кто делает? точно так же без пользователей" если так, тогда какая польза от СКЛьного бакапа? ГДЕ ПЛЮСЫ??????????
(58) Ага, это крутой плюс бакапа средствами СУБД

Хы... спорим, что и бакапите то на МС СКЛе и не более. И в конторах только одна-две базы на одном сервере. Так рьяно защищать то чего невозможно объяснить можно только в патовых ситуациях или когда лень и возможности подыгрывают друг другу

(58) + то у него контора солидная, то зоопарк СУБД, то куча клиентов(не могущих предоставить норм железо для работы), то опять "вот попадешь в солидную контору"
Кто тебя телегой зацепил, что ты никак не уймешься??

(59) Ага то-то если битые ссылки или косяки с базой, рекомендуют выгрузку/загрузку средствами 1С, они наверное не знают что это не помогает

Ну а уж то что скуль знает что такое битые ссылки - спасибо поржал

Для скуля это просто строка, это для 1С это битая ссылка

(60) Это ты сейчас с кем разговариваешь?

Да он уже постов 40 как сам от себя тащится. Может намекнуть ему о времени восстановления?

(61) Уже не смешно. Если у тебя приличная контора, скажи КАКИЕ ПЛЮСЫ У БАКАПА средствами СУБД?????? Сколько можно? Я понять не могу вашу позицию??? Она звучит примерно так: "это круче, потому что... не важно, просто круче". При чем тут зацепил? Просто меня добивают собеседники, которые считают, что их мнение одно правильное и основанное только на непоколебимом слове

(65) У бекапов нет плюсы, только минусы. Занимают место на диски, опять таки сервер нагружают при выгрузки, плюс требуют зарплату мальчику для обслуживания (ведь нужно следить, чтобы они были всегда и место не кончилось). А толку от них никакого.

(65) Т.е. рекомендация производителя софта для тебя не указ?

(62) Контору передали в дочки перед НГ. До этого были "умные" франи, которые довели базу до абсурда. Работы много. Выгрузил средствами СУБД. 2 недели плясал над падением клиента без предупреждений, сообщений и прочих признаках. Перед самым НГ сделал вторую выгрузку и все нормально. Если бы средствами платформы делалось, то ни каких проблем не было бы.
(64) А тебе намекнуть о разницы времени восстановления? Особенно в процентном соотношении. Ну ка, наложи эти данные на работу разработчиков? У нас по 1Ске я один работаю, плюс помогают шеф и сишник. Первый на лотусе сидит, второй для амеров пишет, так вот ни у первого ни у второго нет МС СКЛя из-за ненадобности
(67) А для тебя причины возникновения рекомендации хоть о чем-то говорят? Мне нравится думать

(66) Блин, я убит)))) Про ЗП за повышенную квалификацию совсем забыл

(68) Т.е. тебе пофиг что рекомендует производитель, у тебя есть свое Очень Важное Мнение?


Для примера соседняя ветка v8: Восстановление базы данных, 8.1

в октябре люди работали с базой, но при этом восстановление из dt этой базы не происходит. А если был бы бекап скуля, то там таких бы проблем небыло

(65) Ну чего привязался? Для меня 20 минут потерянной работы юзеров - проблема гораздл большая, чем нехватка места на диске. И простой при восстановлении важен.
Еще раз: хватит гнать пургу о "разработчиках" - ими в рабочей базе пахнуть не должно.
Делай, что хочешь, тут никто не обязан тебя уму-разуму учить.

(71) Нееееееее, так не годится. Народ сначала трындит, что средствами платформы бакапы делают только неудачники и настоящие пацаны делают только СКЛем (скорее всего только одной версией платформы и только от мелкомягких). Если нет аргументов, тогда...
Теперь про пургу: если у тебя нет глобальных задач, то это не значит, что все работают с маленькими базами и нет проверок для больших изменений. Например, запуск бюджетного центра на сях написанного. Обкатка выгрузки-загрузки первый раз

(70) Вот поэтому у нас, как и всех взрослых контор, есть скульный бакап, который очищается через какое-то время и 1Свский, который пишется на диски и используется во всех разработках. А по ссылке, результат работ как раз таких вот мегаспецов. Эти траблы надо предусматривать заранее. Понимаешь? Заранее!!!!! а не по факту падения

Нееееееее, так не годится. Народ сначала трындит, что средствами платформы бакапы делают только неудачники и настоящие пацаны делают только СКЛем

Номер поста?

(70) "у тебя есть свое Очень Важное Мнение?" в отличии от некоторых, мнение не пустозвон, как у некоторых, а конкретно обоснованное, аргументированное и проверенное опытом. Разницу понимаешь? Ответ надо, почему в этом случае не прислушиваюсь?

(74) читай (27) все с него началось. Типа, чел работает с серьёзными базами и в этом случае каждый поймет, что надо работать с СКЛными архивами

Мимо
Нимер поста, откуда взята та хрень? Моего поста!

Так что это было в (72) ?

(77) Мимо???????? Я же не против тебя, а против бакапа средствами СУБД. Ты поддерживаешь обратную сторону, вот тебе и мотив. Внимательней читай (72)!!!! Там было сказано про народ, а не про тебя!!!

Пост обращен ко мне. Следи за базаром.
По существу.
При сбое базу нужно восстановить с потерей макс 20 последнх минут. Готов выслушать твои предложения.

(73) Ты же кричал бекап скуля не нужен?

(75) Пока что пустозвон, ибо ничем не подтверждено

(80) "Пост обращен ко мне." Ты не скрываешь того, что бэкап средствами СУБД круче. Как раз все посты ни к кому-то лично, а к противникам бэкапа платформы 1С. Читай внимательно
"При сбое базу нужно восстановить с потерей макс 20 последнх минут." Ха! Я то, в отличии от некоторых, пробовал восстанавливать и не раз. Хорошо, что только в образовательных ситуациях. А ты пробовал? На рабочей базе с 16 торговыми точками. Проблема в том, что для СКЛ завершение транзакции почти всегда (при большой нагрузке) для 1С только доля завершения. База часто восстанавливается, но почти всегда с незавершённой транзакцией. Вот после этого и появляются крики о помощи "все пропало..."
Теперь про степень отказоустойчивости: для информации она измеряется в процентах. 100%, это когда все будет работать при ядерном взрыве и потопе. 0% - когда система даже не сможет запуститься. Бесперебойники ставят как раз для повышения этой степени. Кластеры сооружают тоже. Там много методов, которые известны всем. Так вот если есть шанс, что надо базу восстановить с временем 20 минут до падения, тогда надо задуматься о прочтении книг, образовании админа и смены разработчика. Любой консультант собственника подтвердит мои слова.
Это я к тому, что тут решение точно не бакап средствами СУБД

(81) Смешно... даже и не знаю что ответить. Знаешь, я тоже котенку говорю, что жрать нету и надо идти в магазин, а он орет. Вот тоже молчу и не знаю как поступить. Я не говорил, что бэкап СКЛ не нужен, я говорил, что основным должен быть только 1Совский!!!! СКЛный только второстепенный!!!!!! Если почитаешь внимательней мои посты, то найдешь, что именно при помощи СКЛного архива я получаю 1С-вский для базы, которая работает без перерыва круглосуточно

(84) Т.е. это не ты писал

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

Свободен, теоретик) неубедительно - слишком мало восклицательных знаков и общих рассуждений.
Жизнь научит.)

(86) Чему? Восстановлению базы из кусочков? Так ты пробовал? Ну скажи)))))))) Блин, попробуй на перепроведении прямо сейчас и сделай тестирование базы. Что тебе стоит вместо слов попробовать?
(85) Ирония, означающая, что не основной. Или на мисте юридически рассматриваются предложения? Может еще про запятые глянешь? А про ударения? Я их вообще не расставляю, вот же досада.
СКЛ-ный не основной! Пусть будет для очистки совести админа, который знает МС СКЛ и совсем не соображает в остальном. Поэтому такой архив и чистится раз в месяц/неделю/год

(87) Так может все твои слова считать иронией?

(86) Про "теоретик": в отличии от некоторых, я многое пробую сам. Мне не трудно, т.к. цена ошибки высока. САМ!!!!!! Я даже книги читаю. Прежде чем что-то утверждать, готовлю аргументы
--------------------------
Хорошо. Можно (тока не обижайтесь) я повторюсь с вопросами? Кто-то из вас проводил оценки рисков работ ИБ? Чем СЛный бэкап лучше 1С-вского и наоборот? Ситуации моделировал по страшному падению? От куда такие утверждения то?

(88) Если честно, то на мисте я ни когда серьёзно не пишу ;) Но мне все таки интересно увидеть аргументы против моих утверждений. Я то знаю, чем СКЛный лучше 1С-вского бакап

(89) Ничем, это вопрос религии. Главное чтобы он был, а как ты его сделал - это вопрос из области нравится/не нравится. Ну и плюс еще пару факторов в пользу того или иного метода

Не бывает чудо совета который всем подходит, все зависит от ситуаций

(91) ура! наконец то! Хоть один сказал. Только добавлю, что в разных конторах надо моделировать ситуации средней сложности и сравнивать цену остановки. Сразу становится ясно что лучше

на все доводы что метод А лучше метода Б можно привести контрдоводы говорящие об обратном. Если бы один был бы на порядок лучше другого, то только им и пользовались

А так это холивар, что лучше windows или Linux, дбф или sql

(92) ye nfr ns ;t rhbxfk? xnj dct[ r vfrfrfv? rnj yt nfrjq rfr ns

Во! Вспомнил! В одной из контор был параллельный сервер с базой, которая постоянно дополнялась по распределенке. Чем не бакап?

* Ну так ты же кричал всех к макакам, кто нитакой как ты

при некоторых ошибках в базах бэк от 1с восстановить невозможно в отличии от скульного

(93) Так я и ждал, когда будут аргументы против 1Свского. Чесслово увидел только то, что "у нас так работает"

(97) Согласен. Но если это случилось, то там уже надо паниковать. Так же есть ситуации, когда и МС СКЛный бакап не работает (месяц назад у меня). Так вот зарабаотал только на постгре. Это что значит, постгре еще круче? Мне кажется данный аргумент наоборот против твоих утверждений. Доказать? Смотри, у тебя есть косяк в базе. Ты делаешь архивы СКЛем и не задумываешься о косяке. А он растет!!!!! Через год все накрывается медным тазом, а из архивов только косячные базы. Как думаешь, когда косяк быстрее выявится?

(98) А зачем?

Ты хотел еще что то услышать? Не услышишь, ибо аргумент один. "у нас так работает"

(100) Автоматом: а зачем утверждать обратное? Просто так?
(101) Бойтесь неверные!!!! Скоро я приду к вам!!!!!!

(99)скажи в каких случаях при работающей базе нельзя развернуть скульный бэкап данной базы ... одноэсовский, сделанный с рабочей базы, я тебе хоть завтра выложу ...

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

(103) Сделай. Запусти перепроведение доков и сделай. После этого восстанови и сделай тестирование. Что бы вкусить весь кайф, сделай кусочный бакап.
(104) У нас разные СУБД. В частности я себе на рабочую машину его поставил, что бы смотреть совместимость у самописок. А заикнулся из-за ситуации, когда МС СКЛьный бакап оказался незапускаемым, кроме конфигуратора и спас только постгре

(103) Опять же это только минус. Какой плюс у МС скльного бакапа?

(105)что т ы имел ввиду под кусочный бэкапом? ... все остальное делалось и не раз ...

(106)в чем минус то? ... в том что скул это не постгри ... и не надо ипаться ... а надо просто знать ... что зачем и куда?

(107) в (80) как раз про него и идет речь

(108) поверь, если будешь говорить собственнику как правильно строить бизнес, когда есть рядом куча советников... Скажи, как узнать при архивировании, что не попал в серединку одинэсовской транзакции? Я же писал, что одна база архивируется только через СКЛный бэкап и тоже все нормально. Но вот перед НГ выгрузка попалась кривая. И не помогло ни чего, кроме перегрузки в постгре. Даже если я тебе вышлю её, скажешь что сделал все сам руками, только не скажешь, что именно.

(110)мама дорагая ... ты что знаешь о скуле и его бэкапах?

хм ... где в даном хоть слове о бэкапе

"Пост обращен ко мне. Следи за базаром.
По существу.
При сбое базу нужно восстановить с потерей макс 20 последнх минут. Готов выслушать твои предложения."

(111) Подробнее можно? Что именно интересует? Только сразу проецируй свои знания на крупную контору, с кучей дочек и у которых исторически сложилось так, что были разные самодуры по админству баз

(112) "При сбое базу нужно восстановить с потерей макс 20 последнх минут." Только не говори, что СКЛную базу надо делать каждые 20 минут

(113)крупную на сколько? ... стоимость 49 млрд. долларов и имеющих дочки в казахстане, китае, россии и бразилии ... такая сойдет?

Хотя нет, давай по другому? Уважаемый skunk, ты считаешь, что бакап средствами СУБД во всех случаях эффективней, чем средствами 1С? Если нет, тогда в каких случаях и почему? Аргумент про "скорость быстрее на 20-50%" и "стоимость спеца выше" уже услышал. Кроме него есть плюсы?

(115) Более чем. Уверен, в таких крупных конторах очень тщательно подходят к оценке рисков и принимают решения на их основе. У вас большая нагрузка, много разработчиков и эникеев? Я правильно понимаю?

http://195.128.127.177/forum/actualthread.aspx?tid=12953&pg=1&mid=57337

там русским языком объясняется как делается бэк средствами скула

(116)я тебе уже сказал ... правда не понятно почему ты это записываешь в минус ...

(114)вприницпе можно ...

BACKUP DATABASE database_name
TO backup_device
WITH DIFFERENTIAL

хотя диффернецирования по 20 минут я не пробовал ... но по часовой работает без проблем

(118) первый пункт выполняется для точки СКЛной, а не 1Свской. Нет? Или крутой МС СКЛ знает, что он работает с 1С?
(121) Нет конечно, не дописка в бакап, а создание транзакционных кусочков лога. Честно не помню как правильно называется, но там хоть каждые 5 минут ставь и все инсерты и прочее элементарные команды будут записаны. Вот мы ни разу не смогли восстановить семерошную базу

И опять же, это не очень работает в недоконторах с разными версиями СУБД. Пардон, а у вас сколько разработчиков? Этот вопрос сразу влечет за собой другой: у каждого стоит МС СКЛ лицензионный?

(123)там впринципе фиолето кто работает ... ибо по факту делает все скул ... а эсина или что-то другое просто дает команду надо сделать то-то ...

(125) Хм, но ведь если 1Ска пишет в базу одну запись (с точки зрения платформы), тогда как для СУБД, это сотня записей. Нет? Я понимаю, что всегда прокатывает, т.к. 1Сина соблюдает свою транзакционность. Не спорю. Но вопрос: ЗАЧЕМ? У 1С-вскго бакапа только плюсы и почти нет минусов.
Не знаю, все видят в этом плюсы из-за переносимости (я про сторонних лиц: франи, копии разработчикам и копии в сейф)

(124)я знаю только о двух ... именно разработчиков и именно на 1с ... разные версии у нас тоже юзаються ... у одних скул 2005 у других 2008 ... даже файловые варианты есть ... и даже есть такой файловый ... который при работающей базе сделаный бэк средствами эсины не восстанавливается ... точнее был ... но думаю с имитировать не будет больших проблем

(126)ничего она не соблюдает ... отдается скулу как последняя женщина ... чего собственно делают и другие программы

(127) Ну! Ведь в этом случае проще же 1С-вский архив для переносимости? Я не говорю, что панацея, утверждаю, что хоть чуть-чуть но эффективней

(126)но как нет минусов ... описываю ...

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

а случись это в таблице каких-либо итогов по субконто что делать пришлось бы

(129)ну для переносимости не спорил ... я вообще не сильно спорил ... ты просил показать тебе плюс бэка скульного над эсовским ... я тебе сказал "гарантированое восстановление данных несмотря на косяки в самих данных"

(130) Пардон, т.е. если бы в этом случае делали бэкап средствами МС СКЛ, такого бы не случилось? Или я не правильно понял
(131) Да ладно, я же просто для себя инфу черпаю как обычно. Ведь в спорах много истины. Не обращай внимания))))))

(132)было анологичное только с датами документов ... бэк эсовский не восстановился ... скульный без проблем

(133) Если честно, мне кажется, что ситуация могла быть в разных СУБД с примерно одинаковыми шансами. Не думаю, что тут МС СКЛ единственное решение. В частности мой пример с постгре, там то вообще МС СКЛ ни как не справлялся

Про место:
в 2008 скуле появилась возможность ужимать бэк-апы средствами самого скуля. Очень нравится сия возможность...

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

(135) Круто конечно, только ДТ-шка немного меньше получается
(136) Я тоже не очень люблю сборники СУБД, но тут не поспоришь. Процесс приведения к единому достаточно длительный

(136) Гумилёва которого - поэта или историка? :-)

который тут все постгри пиарил

Мда... насчет PostgreSQL говорить не буду, однако преимущества бэкапа средствами MS SQL вполне очевидны:

а) скорость резервирования. В РАЗЫ быстрее;
б) пользователей выкидывать не надо. Вообще. Поэтому разностное резервирование можно хоть каждые 10 минут делать, что очень критично при больших базах и куче пользователей;
в) бэкап делается гарантированно, несмотря на ошибки в базе. Их можно исправить потом - главное, чтобы резервирование выполнялось полностью автоматически и без сбоев в любом случае;
г) сравните-ка скорость восстановления базы из .dt-шки и из скулевого бэкапа. При размере базы >10 Гб - очень удивитесь.

З.Ы. Средствами скуля ужимать бэкапы можно только в Enterprise версии. Но мне, наверное, не дано понять стремлений некоторых товарисчей к экономии дискового пространства, которое стоит копейки. В крайнем случае, можно тупо раз в день паковать архиватором.

(126) Самый большой и явный минус бэкапа средствами 1С - это необходимость выгонять пользователей. При базе порядка 30-40 Гб даже одноразовый бэкап днем - это потеря часа рабочего времени. Да и кто делает один-единственный дневной бэкап в ситуации с >50 пользователями и несколькими тысячами проводимых документов в день?

кстати да ... тоже не понимаю проблем из-за размеров

(140) (142) Класть архивы в сейф
(141) Средствами СУБД перегружаю в другую базу и там выгрузку средствами 1С

(140) а) Бакап - параллельная процедура. Так что это плюс, но гораздо меньший, нежели рассматривать струтуру с разными СУБД
б) Оно и плюс и минус. Можно попасть как раз на транзакцию 1С
в) А вот это минус. При чем жирный! Я описывал уже как может маленькая ошибка превратиться в огромный разгром
г) Сравни-ка скорость восстановления такого бэкапа для разработки, когда на рабочей станции СУБД отличная от серверной

И про размеры: не знаю, у нас одна СХД примерно в 7,5 тб, при этом постоянно забита под завязку. Мне кажется место всегда требуется больше, чем есть

цена стрима копейки

(144)то есть при перезагрузке из одной базы в другую шансов нарваться на транзакцию у тебя нет?

(145) Про цены не надо, это извечная проблема почти во всех конторах. У нас стоит кассетный магнитофон тер на 10, тоже забит. Но там долгие архивы лежат

(146) Конечно!!!!!!! Так вот при перезагрузке я сразу выявлю косяк и буду о нем знать! Т.е. сделаю перевыгрузку. Понимаешь о чем? Платформа 1С меня то и предупредит

(147)нет у нас такой проблемы ... записываем на стрим и в сейф ... что-то на пять лет

(148)какой косяк? ... ты все еще думаешь о каких-то внутренних транзакциях 1с ... поверь их нет ... как и высших сил

(150) Первая выгрузка средствами МС СКЛ была с ошибкой. Вторая нормальная. Это не просто слова. Я пока в отпуске был, шеф пытался все восстановить. Только перевыгрузка спасла.
В круглосуточной базе у нас перевыгрузка в тестовую средствами СУБД, потом тестирование с логом и выгрузка средствами 1С. Ошибок не было, но если появятся, то я тут-же узнаю о проблеме. Тут же, а не через год, когда уже можно и не паниковать

(144) Бэкап средствами 1С - параллельная процедура?

(152) СКЛьная. Ладно, не то ляпнул. Я просто хотел сказать, что время выгрузки вроде как не сильно большой плюс. Или есть ситуации, гже это именно плюс?

(151)а может шеф не так восстанавливал как надо ... тем более из ваших кусочных бэкапов про которые ни кто кроме вас не знает

(154) Все так, шеф спец. Бэкапы делал админ. Нам нужна была срезка, т.е. бэкап точно не кусочный.
С другой стороны, а что можно сделать не так? Я вот даже предположить не могу

(155)я вообще не понимаю, что вы сделали не так ... сам бэкап или его восстановление ... ну не ту у скула данных проблем ... он очень кошерно работает с бэком во время транзакций ... специально тестили ... как на 2000, так и на 2005 и 2008 ... сейчас выйдет 2012 будем на нем тестить

(156) "сейчас выйдет 2012 будем на нем тестить"
Зачем?

(156) Заметь, "не понимаю" и "сделали не так", разные вещи. Сделали все так: на рабочей базе выгрузку, перетащили на наш сервер, загрузили. Конфигуратор открывает нормально. Предприятие валится без сообщений

(157)пока много вкусного обещают ... ну и для развития кругозора

(158)я несколько раз на дню делаю такое ... все работает нормально ... что я делаю не так?

ты из-за одного случая ... который даже воспроизвести не можешь ... валишь все на скул

(153) В зависимости от размера базы. Террабайтную базу в dt довольно грустно выгружать/восстанавливать

(160) "Суслика видишь? А он есть!". Объясни, как МС СКЛ может отслеживать завершения одинэсвской транзакции? Если знаешь - расскажи, если нет, тогда опровергни утверждение "СКЛ-ная транзакция, может попасть в центр 1С-вской и так с обрубышем выгрузиться"
(162) Ну да, терабайтной базы у меня нет

(163) а ты пробовал смотрел в профайлер, что происходит при 1сной транзакции?

(163)тебе опять на мистику глаза открывать? ...

(164) Честно? Ни разу. Чесслово. Расскажи
(165) Блин, но со второго то раза все нормально. Тоже самое, ни чего лишнего

(163) Это не SQL отслеживает транзакции 1С. Это 1С блокирует таблицы, необходимые для корректного завершения транзакции. Бэкап ждет снятия блокировки. Матчасть, товарисч, матчасть... А что такое "СКЛ-ная транзакция, может попасть в центр 1С-вской и так с обрубышем выгрузиться"? Ви таки считаете, что 1С умеет, не используя транзакционную схему MS SQL, самостоятельно и напрямую работать с таблицами SQL?

(166) а вот загляни сначала

(163) Для начала рекомендую погуглить понятие "транзакция" применительно к базам данных.

(166)еще раз на пальцах ...

1. 1с сама в скул ничего не пишет ... пишет сам скул ... поэтому ему фиолетово кто делает программу
2. скул бэкапит базу и лог транзанкций до точки "а" ... то есть до псоледней закрытой транзакции на момент начало бэкапирования ...
3. после того как скул за бэкапил все ... он бэкапит от точки "а" до точки "б" ... точке "а" присваивается положение точки "б" ... в точку "б" помещается точка последней зафиксированой транзакции
4. цикл повторяется до тех пор пока "а" <> "б"

(170) упс... т.е. не может быть ситуации, когда 1С будет писать в базу данные быстрее приближения а к б? Это теоретически невозможно?

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

(171)нет не возможно ... приоритет у бэка

(173) Тогда про целостность сдаюсь. А нашу загрузку объяснить тогда вообще не могу

(173) С другой стороны, приоритет у СУБД. Где гарантия, что она не тормознет 1С на незаконченной записи объекта? Как СУБД узнает, что именно в этот момент весь документ сохранен, а не половина его?

(175) ААААААА!!! Да сколько ж можно! 1С работает с базой данных СРЕДСТВАМИ СУБД, блин. Она не может что-то делать в обход СУБД. Нет такого понятия "приоритет СУБД".

(176) Т.е. сохраняет объект одним запросом? Типа, СУБД пусть сама решает как его записать. Я правильно понял?
Хорошо, какой запрос будет у записываемого документа с подписками на события, регистрациями изменений и перезаписью десятка справочников? На целостности данных такой вариант может оказать влияние?

(177) Нет, не может. Запись документа ведется в режиме транзакции, это заложено на уровне платформы. Соответственно, все субзапросы проводятся также в рамках этой транзакции. Именно поэтому файловая база в клюшках так любила падать и гробить записи с индексами при перебоях питания - механизм работы с dBase не подразумевает транзакционной схемы.

Лучше SQL бэкапа для 1С нету, проверено.

+ Можно делать бэкапы не выгоняя пользователей
+ Можно не заморачиваться со скриптами, планировщиками и тд
+ Восстанавливается база примерно с той же скоростью как и с ДТешки

(175) Если мне память не изменяет - сначала от клиента помещается в буфер сервера 1с:Предприятия, потом передает на SQL, там записывается на temp.mdf, а потом уже на саму база.mdf

Если режим протоколирования базы Полный то ещё можно до каких-то транзакций восстанавливать, но это не уровень 1Ски, проще делать Простой режим.

Как-то так.

(180) ЕМНИП, все-таки не совсем так. Насчет буфера сервера 1С не в курсе, но вся последовательность запросов проводится в рамках транзакции SQL сервера. А как он там уже промежуточные данные сохраняет - дело десятое.

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

(182) Причин "кривой" выгрузки базы можно с ходу придумать с десяток. Начиная с ошибки дисковой подсистемы, например. За четыре года постоянных бэкапов огромных баз средствами MS SQL ни разу не возникло сбойной ситуации - думаю, это обстоятельство не перекрывает единичный случай повреждения данных по невыясненной толком причине.

+(183) "... не перекрывается единичным случаем...", конечно же.

(183) Может и так, а может и нет. Как минимум сам бэкап то восстановился, т.е. с точки зрения СУБД все нормально

темп.дб это чисто для чтения ... типа кэша

(186) Она задействуется во внутренних механизмах скуля :)

(187)на запись она никак не влияет

(185)да там сто пудово причина даже не в скуле ...

может надо было тупо помойку прочистить

(188) v8: База TempDB в SQl

Так что на запись она влияет, но для пользователя это совершенно прозрачно. Впрочем, создавая вручную запрос с таблицей типа #temptable - эта самая temptable создается именно в tempdb.

(190) Какую и зачем?

+(188) Тут вот более внятно расписано - http://msdn.microsoft.com/ru-ru/library/ms190768.aspx

(192)та что локал сетинге создается

(194) Если бы оно так было, то вторая выгрузка бы не загрузилась тоже. К тому же запускали на разных компах. К тому же заливали в новую базу. Так что наверное не в этом причина

гыыы.... ежедневный бекап базу в 130 гигов делать в dt
ладно 1-2 часа выгрузка займет..
загрузка зайемет часов 10
смысл такого бекапа
тогда как средствами sql все обернется минут за 15

(196) Я ее не дорабатываю, так что и не перегружаю. На неё нагрузка очень маленькая. Да и все СКЛи ставить на рабочую тачку, по моему мнению, не правильно

(196) Вовово! :) О чем и речь.
(197) Рабочая тачка - это что? Тачка разработчика? Дык етить-колотить, а для чего она нужна тогда? А вот если еще цомпутер настоящего тестировщика посмотреть...

(198) так расскажи схему с разными СУБД, базами и несколькими разработчиками

Забил 200