Добрый день!
У нас сервер (Windows 2008 r2) + MSSql server.
На данном серве база.
как лучше делать бэкап: На сервере или через конфигуратор(файл- выгрузить информационную базу)?

подключи МС Азуре, они сами будут бэкапить

(0) Сам решай.
Я всегда в *.dt делаю - ни разу не подводило.

(0) dt не является бэкапом

(3) Сам придумал?

(4) А ты про dt сам придумал?
http://its.1c.ru/db/metod8dev#content:2922:hdoc

(3) ИТС читай, это средство переноса данных

(6) -> (4)

Только средствами mssql

Вы что-то не то даете читать товарищу из (4)
Разве фирма 1С авторитет в этом вопросе?
Вот авторитетный источник:
http://yandex.ru/yandsearch?text=не%20загружается%20база%20из%20dt%20&lr=213&suggest_reqid=994671708140913035390455741888974&safety=1&site=forum.mista.ru&csg=221%2C6853%2C26%2C42%2C0%2C0%2C0

(9) пять баллов)

(10) http://yandex.ru/yandsearch?text=александр_тверь%20и%20greatone%20поженились&lr=51&suggest_reqid=17731155138935171729584784626197&safety=1&site=forum.mista.ru&csg=0%2C0%2C0%2C2%2C1%2C0%2C0

585 ответов

(5) (6) (7) Ни о чем... Есть рекомендации, но это не требования. Ты когда код в конфигураторе пишешь, все рекомендации 1С соблюдаешь?

(9) Я тебе тоже могу ссылку дать... И что?

(12) фак зе систем!

+(12) с другой стороны, есть механизм (*.dt), который достаточно надежен и экономичен. Почему им пользоваться нельзя - совершенно не понятно.
Допускаю возможность, что когда-нибудь налечу на ошибку при восстановлении из *.dt, но за более чем 8 лет еще не напоролся...

(0) на сервере.
(2) всегда делаю средствами sql - ни разу не подводило.

(14) потому что нужен монопольный доступ может?

(12) простите, ссылку на что?

Я тебе привел реальные истории людей, которые "более чем 8 лет еще не напоролся", "всегда так делал", "5 лет работало " и т.д.
Хочешь рисковать оказаться в их числе - это твое право. Есть у тебя доводы делать через dt - делай. Лучше тебя никто из здесь присутствующих не знает что тебе надо и в каких условиях ты находишся.

Но! dt - это не backup.

Этот механизм предназначен, ПРЕЖДЕ ВСЕГО, для получения образа информационной базы независимо от способа хранения данных.

а backup средствами MS SQL предназначен ПРЕЖДЕ ВСЕГО для того, что бы делать backup. в этом разница.
Для dt - бэкап - это побочный вариант. Но с таким же успехом ты можешь останавливать sql и копировать файл базы данных. Чем не бэкап?

Александр_Тверь смысл слюной тут брызгать?
Любое копирование данных является бэкапом, хочешь ты этого или нет.
Прежде, не прежде... Как в детском саду, прямо... Работает - это главное.
А на счет реальных историй людей - это нормально. Негативных отзывов по смартфонам Samsung намного больше, чем по смартфонам ViewSonic, но это абсолютно не означает, что ViewSonic лучше Samsung. Просто Samsung намного популярнее.

Так что, механизм есть, он имеет свои неоспоримые плюсы (размер файла, независимость от режима работы БД) и недостатки (требуется монопольный режим). Бывали случаи, что люди не могли восстановить из него. Всё. Пользоваться им или нет, каждый решает сам и давай на этом закроем эту тему.

Ну и лично от себя добавлю: все недостатки бэкапа в *.dt меня устраивают и я им пользуюсь постоянно. Бэкапом другими способами пользуюсь очень редко.

К слову, восстанавливать базы локально приходится часто.

(0) Проще на скуле 1 раз в пару кликов настроить бэкапы, чем создавать батники для выгрузки в .dt

(0) Хороший вопрос для собеседования. Вот товарищ в (2) не прошел.

(23) Опять началось... Высер из серии, что 1000 рублей не деньги, а Лада не машина...

(21)Несколько вопросов:
1. как же рекомендация не делать бэкапов в dt? Который запросто может сохраниться, но не развернуться обратно?
2. Зачем при наличии sql сервера лочить базу, когда все может работать само и достаточно проозрачно?
3. ms sql позволяет настроить архивирование так. что можно откатиться вообще на любой момент в течении дня с заданной погрешностью. Причем такая архивация не будет создавать слишком много накладных расходов. С какой целью отказываться от этих возможностей?

(35)*когда все может работать незаметно для пользователя

(25) Ответы:

1.1. Ты рекомендации написания кода соблюдаешь? Вот и я не всегда...

1.2. Вероятность есть и она не нулевая, но так как я очень часто пользуюсь бэкапами для разработки, то проблема будет выявлена быстро. Поэтому, это совсем не критично для меня. К тому же, бэкапы у меня восстанавливаются всегда уже более 8 лет - я везунчик?

2. Ночью никто не работает, как ни странно.

3. Никто от них не отказывается, просто не всем они нужны. Зачастую хватает просто ночного бэкапа.

Я не говорю, что бэкап средствами SQL хуже или не нужен.
Я говорю, что бэкап средствами 1С тоже имеет право на жизнь.

(27) Я не соблюдаю их по каким то причинам, например это может увеличить объем кода. Здесь вообще нет никаких причин не использовать sql
1.2. Зачем нужен бэкап который не развернется? Если есть возможность их не делать, может так и имеет смысл делать?
>> К тому же, бэкапы у меня восстанавливаются всегда уже более 8 лет - я везунчик?
Все когда то бывает в первый раз, не зарекайся. К тому же этот первый раз, почти всегда бывает очень не кстати.
2. Если я хочу к примеру делать бэкап два-три раза в сутки?
3. У меня к примеру есть клиент с розничными продажами, упала база и никто не может сказать что было продано в точности. Потому что продано было очень много.
(28) Это даже не вопрос, пользоваться можно и штатной выгрузкой, но ты не ответил - зачем? Почему не использовать более простой 100% работающий механизм при его наличии?

(29) "Здесь вообще нет никаких причин не использовать sql"
Причины: размер бэкапов и простота разворачивания локально.

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

"2. Если я хочу к примеру делать бэкап два-три раза в сутки?
3. У меня к примеру есть клиент с розничными продажами, упала база и никто не может сказать что было продано в точности. Потому что продано было очень много."
Тогда делай средствами SQL. Я не утверждал, что бэкап средствами SQL не имеет права на жизнь.

"но ты не ответил - зачем?"
Повторяю: у бэкапа средствами 1С есть плюсы.
1). Размер. Можно хранить больше архивов. К тому же, можно их хранить на флешке или даже в почте... Чем меньше архив, тем проще его сохранить.
2). Разворачивается локально без доп. манипуляций.

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

(30) Допустим ситуацию: подходит бухгалтер и говорит, на прошлой неделе при выполнении такой-то операции ошибки не было, а сейчас есть. Как ты это проверишь? А я восстановлю архив от той даты и сравню как есть и как было...

(32) Скулом хоть каждые пять секунд можно копировать. По поводу того, что база не развернется - это происходит из-за того, что размер внутренней таблицы переваливает за 4 Гб и ее всегда можно почистить.

Скулем. Если скуль старше 2008, то в скуле сделать архивацию бэкапов, тогда размер будет существенно ниже (почти сравним с dt)

Dt в случае необходимости.

(30) Локально можно развернуть только довольно маленькую базу. Мне лично мешает совсем другое свойство выгрузки в dt, а именно - монопольный доступ. SQL Server умеет бэкапиться прямо во время работы. Мешает размер - делай дифференциальные бэкапы и сжимай. Где я настраивал бэкапы - делается так - полный бэкап ночью + дифференциальные каждые 2 рабочих часа - в 9, в 11, в 13, в 15, в 17 и в 19 часов. Пока этого хватало, пару раз пользовался восстановлением. Rotate бэкапов - 4 дня + хранятся полные недельные(раз в несколько месяцев старые удаляю вручную). Работает как часы уже года 4.

А сохраняет ли Скульный бэкап конфигурацию баз данных?

Дэтэшник то конечно...

(36) Естественно. В 8, в отличие от 7.7. почти всё хранится в БД. Кроме логов, но это не очень критично.

+(38) Кстати, хз, почему до сих пор не реализовали возможность хранения журнала регистрации в БД, чтобы не писать лишнего на сервер приложения.

(32) Открою тебе тайну. Скулём можно восстановить данные не только на дату создания бэкапа, а на любую секунду.

Вот бы еще скульные бэкапы записывались друг на друга, чтоб вручную не удалять... (иногда забываешь)

(40) Сказочник. Такой детальный бэкап никто хранить неделю не будет...

(42) Эээээ... По бэкап журнала транзакций не слышали ни разу?

(43) То есть, восстановить полный бэкап и откатить транзакции?

Накатить

(41) ВНЕЗАПНО
https://yadi.sk/i/Nr4tfie7ehNts

+(46) Перевести?

(39) Плюсую.

(47) неплохо бы

(45) Ну и сколько, по-твоему, будет весить такой журнал транзакций через год?

(0) я делаю обоими способами. MSSQL делается ежедневно и сохраняется с именем, содержащим день (1-31). Такие бэкапы перезаписываются через месяц. Затем, тем же MSSQL делается еще оперативный бэкап раз в несколько часов. В имени час суток. Перезаписывается, соответственно, раз в сутки. И наконец, в нерабочее время, если база свободна, снимается dt. Получается не каждые сутки, но зато всегда при необходимости есть вариант для загрузки в файл/отладки.

(50) Речь шла о неделе, теперь уже за год? За год, конечно, хранить бэкап лога нет смысла. Обычно есть полный бэкап на какой-то момент + диф. бэкапы + бэкап лога. Если не страшно потерять час или два работы юзеров - можно переключиться на Recovery Mode - Simple и оставить только Полные и дифференциальные бэкапы, как я описал в (30).

(50) Немного. У нас, например, за 3 года бэкапы хранятся в оперативном хранилище. Более старые на ленту пишутся.

А зачем год, полная копия нужна раз в неделю хотя-бы. А там уже политика, как захочешь, так и храни.

ИМХО, спорить с религиозными фанатиками типа Cube бесполезно.
Ну хочет он в dt выгружать - пусть выгружает. Что вы к человеку пристали?

(55) Так неудобно же! При реально простой схеме, как в (35) эффективность бэкапов намного больше(меньше потенциальные потери, а при бэкапе лога - вообще могут отсутствовать), времени на создание и восстановление - меньше.

(55) А никто и не пристал, человек уважаем, многим помогает, непонятно просто зачем отстаивать заранее проигрывающее мнение.

+(56) А нелепые аргументы типа "места меньше занимают" - ну пля, люди, архиваторы не вчера придумали.

(55) При чем здесь религия? Мне домой лицензию на сервер прикупить, чтобы разработку дома вести?

(56) Удобно тем, что для разворачивания бэкапа нужна только платформа и одна клиентская лицензия...

(52) (53) Я не спорю, что у SQL возможностей больше. Я спорю с утверждением, что *.dt не имеет права на жизнь.

(60) Нет. Если база большая - ничего у тебя не выйдет. А маленькие базы по барабану, как бэкапить.

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

(52) обычно, если что-то не так в базе, и начинаются разборки с пользователями, кто чего накосячил, требуется поднять бекап, который был сделан несколько месяцев назад. Поэтому лучше иметь dt-шки, хотя бы понедельные, за несколько месяцев. Они меньше места занимают. А sql-ный бекап ежедневный последние две недели, ну или за месяц.

(62) Маленькая/большая... *.dt весит 1 ГБ, это маленькая база?

(65) У меня 900 Мб в 25 гигов разворачивается, и в файловой говорит "не шмагла".

Обычно базы домой не носишь, по удаленке обычно работаешь.

(64) Да, такой вариант вполне нормален, хотя и SQL бэкапы тут будут вести себя не хуже.

(66) Может ты не уверенно на мышку нажал при бэкапе и у тебя зацикливание где-то -> файлы растут при разворачивании -> не шмагла в итоге?

(67) Всякое бывает. Мне частенько присылают базу и ТЗ...

(66) У меня архив 1 Гб разворачивается в 7 Гб.

(69) Facepalm. Эта база в SQL весит 25 гигабайт. Бухгалтерия за 3 года, с кучей счетов и реализаций(опт+розница).

(71) Картинки в базе? :)

(73) Есть немного, но в основном - данные. Это УПП.

(74) Конфа плохо сжимается, а данные - хорошо.

+(75) У меня БП 2.0, т.е. метаданные явно меньше.

(61) "Я спорю с утверждением, что *.dt не имеет права на жизнь" - Имеет, конечно, но не в качестве бэкапа. Для этого они, к сожалению, не предназначены.

(59) Т.е. ведешь разработку на рабочих данных дома? Завидую твоим работодателям. Мне все как-то больше попадаются те, которые не готовы свои данные отдавать насторону.

Сейчас попробовал сжимать средствами скуля - получилось 2,5 гигабайта SQL-ный бэкап.

(59) > Мне домой лицензию на сервер прикупить, чтобы разработку дома вести?

Дома отдыхать надо.
Если есть необходимость вести разработку дома, то о покупке лицензии на сервера должен задуматься работодатель.
В конце концов минисервер 1С стоит копейки (14400). Можно и самому купить, если ты фрилансер.
MSSQL Developer ed. (если версии Express недостаточно) стоит еще дешевле.

Да и всерьез выгрузку в dt можно обсуждать только для микробаз. Хоть сколько-нибудь серьезного размера база тупо выгружаться и загружаться будет дольше любого приемлемого разумного времени.

(78) Всякие есть. Старые клиенты доверяют, новые, понятное дело, опасаются по-началу...

(80) "Хоть сколько-нибудь серьезного размера база тупо выгружаться и загружаться будет дольше любого приемлемого разумного времени."

Что ты мямлешь, ты же не дворник, говори в конкретных цифрах.

(79) У меня есть полный бэкап средствами скуля годовалой давности - 6.5 Гб.

(83) Это без сжатия. В 2008 и последующих версиях есть встроенное сжатие бэкапов. В 2005 - не помню.

Если уж пошла такая пьянка, то давайте реально обсосем этот вопрос и раз и навсегда определим, с какого момента *.dt перестает удовлетворять...

(84) Даже не знаю, на какой версии скуля это делалось...

(85) http://s.pikabu.ru/images/big_size_comm/2013-11_2/13838292001649.jpg

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

(85) Кого удовлетворяет, те пусть обсасывают

Каждые 10 гигов базы - это полчаса разворачивания из dt на HDD, особенно на ноутбучном. SQL где-то в 4-5 раз быстрее.

(85) Ровно с того момента, как только в нужный момент не сможешь развернуть dt. И тогда начнёшь делать наконец-то бэкапы.

(82) База БП 2.0 Размер на SQL 45 Гб.
Если мне приспичит взять её домой поработать, то я тупо не дождусь когда она выгрузится в dt.
Проще всё сделать на работе, не забирая базу домой.

Последний раз пытались выгружать базу в dt примерно полгода назад. Точного времени не помню - не засекали, т.к. стояла задача тупо проверить возможность выгрузки, а не скорость. Но речь шла точно не о 10 минутах. Загружать эти данные куда-либо даже не пробовали.

Та база, о которой я писал выше на SQL занимает 16 Гб. Базе 4 года. Архив из *.dt (1 Гб) разворачивается минут за 20.

(93) Врагу не сдается наш гордый "Варяг" ))

(85) Это происходит в тот момент, когда время на создание dt не приемлемо с т.з. требований к резервированию данных. Например руководство требует чтобы потеря данных была минимум за 5 минут работы пользователей, а dt уже далается 2 часа.

(95) IamAlexy подсказывал делать в таком случае моментальный снимок, а уже из него выгружать в dt.

dt бэкап для мелких баз, для остального sql. Упоминали про сжатие бэкапов ms sql. В 2005 этого нет, d 2008 c какого то сервис-пака, в 2012 сразу. Красота, бэкап делается быстро и размер гораздо меньше чем в 2005 было.

(97) Мелкие базы - это какие? Размер?
В базе (93) активно работают 15 пользователей.

Мне кажется, что это, не совсем мелкая база... Большой, конечно, её и язык назвать не поворачивается, но даже до таких объемов не дотянет среднестатистический магазин/предприятие...

(96) а что такого волшебного в моментальном снимке? dtшники начинают выгружаться за полминуты?

(98) SQL-ная копия весит 80Гб, выгружается-загружается за минуты, dt вообще не грузится.

(99) Подумай головой и не ищи волшебства там, где его нет.

(101) Да, подумал. Значит сценарий примерно следующий. Делаю моментальный снимок, выгружаю с него дтшник, сижу жду 2 часа когда выгрузиться, на 1 ч. 59 мин. рэйд падает и копия только с предыдущего дтшника 2 часа назад. Два часа работы всей компании потеряны. Компания считает убытки и благополучно вешает на меня.

Плохо подумал.

Думай еще.

Уже не думай. Читай. http://infostart.ru/public/22419/

(105) Ну кстати всё как я и предполагал изначально.
"Уже более трех месяцев в папке выгрузки лежат стандартные выгрузки базы данных с периодичностью 3 часа и уже месяц как это все продублировано на удаленном FTP сервере."

3 часа много. И это только в том случае когда дтшник успевает выгрузиться за 3 часа. Дальше интервал будет толькоо увеличиваться и нет никакой гарании что дтшник не сбойный.

Так никто не настаивает на том что это основной бэкап, так, в качестве дополнения к скульному.

(20) Не переходи на личности.

Да и не бэкап, а выгрузка.

Интересно, какое решение принял автор?

Автор что-то молчит... :(

(98) Все-таки это мелкая.
У нас дт-шник тупо не делается - говорит место кончилось(????). Надежен механизм, ага. База уже за 90 Гб

Cube похоже в жизни ни разу с крупными базами не сталкивался. Хотя с другой стороны это и хорошо. Не с такими познаниями допускать к серьезным ИБ.

(112) "Надежен механизм"
А ты предлагаешь в каждый ларек SQL + УПП, да?

(113) Да, с базами более нескольких десятков Гб не сталкивался и что, тебе это о чем-то говорит? При чем здесь это? Или ты, раз доказать превосходство SQL архивов над *.dt архивами не можешь, решил на личности перейти?