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

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

(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