Много кто пишет, что не стоит делать архив базы выгрузкой в dt. Почему?

Потому что dt предназначен для конвертации БД.

И не всегда база из дт поднимается, кстати.

(0) Когда не сможешь развернуть базу из dt, то вопрос отпадёт.

Один-единственный раз была такая проблема - но там базе был капут.
Поддержу ТС - почему?

(0) Ну, это как про обезьян в клетке: http://wrttn.me/a2ce93/
Уже скоро будет 10 лет, как я делаю ежедневные бэкапы в *.dt и косяков не обнаруживал...
Сейчас тут начнется про размер базы, лезвие ножа и т.п...

(0) затем, что надо пользователей выгонять

Ну можно и в dt, Но нужен монопольный доступ, лучше уж средствами SQL.

если база северная, логичнее делать бекапы средствами СУБД.

(6) Вот с этим соглашусь. Но это актуально на базах, которые работают 24/7...

ТОже не понимаю истерии с dt. С 2006 году бекапы через dt делаю. Постоянно приходиться восстанавливать по разным причинам. Проблем нет.
Размер dt 3 Гига

(5) Тогда всё понятно (после обезьян) :))))

(9)  Так а с другими, вообще вопросов возникать не должно.

(0) Ну, например, потому, что сама 1С говорит, что dt не является средством резервного копирования. Если вендор сам рекомендует использовать другие способы, я не знаю, какие еще аргументы нужны  http://its.1c.ru/db/metod8dev/content/2922/hdoc/_top/%F0%E5%E7%E5%F0%E2%ED%EE%E5%20%EA%EE%EF%E8%F0%EE%E2%E0%ED%E8%E5

(0) потому-что сама 1С писала письмо, что dt нужно делать для переноса баз, а более правильно средствами БД или папку целиком (если файловая). Так больше вероятности, что бэкап не превратится в тыкву

(13) А теперь цитату где сказано, что " dt не является средством резервного копирования."

(13) Запретить и не рекомендовать - разные вещи. Бензин в авто льют и 92 - ездит же.

(14) "механизм предназначен, прежде всего, для получения образа информационной базы независимо от способа хранения данных." Точка.э

(17) запятая, э. читай внимательно. что dt нифига не гарантирует, а только является средством конвертации из файловой в серверную и наоборот

(17) Там дальше продолжение: "Использование этих способов [отличных от dt] дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных."

(15) Вот тут...

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

Они уже официально оговорили, что все на страх и риск пользователя :)

Я делал раньше бекапы файловой в dt. А потом они у меня совсем не захотели загружатся в тяжкий для меня момент. Больше я в dt не бэкаплю. Такая грустная история((

(19) С другой стороны, бывают ситуации, что эти нарушения можно лечатся только выгрузкой/загрузкой *.dt... Так что, тут бабушка надвое сказала...

(16) с авто неверная аналогия, если в феррари лить 92 то рано или поздно движок кирдыкнется...

(21) Может ты бэкапы в 8.0 делал, а загружать их пытался в 8.1... Откуда мы знаем?

(22) Лечить и бекап при крахе БД, немного разные вещи :)

Всем сторонникам дт - продолжайте делать бекапы в дт. Удачи.

(26) Спасибо, нам удача не нужна. У нас всё стабильно хорошо.

(23) Это снеговик = феррари?! Блин, я-то думала, что феррари хорошая машина, а оказывается...

(22) Есть такое. Но бэкап средствами СУБД (или копирование папки файловой базы) сохраняет исходное состояние базы, а загрузка/выгрузка это состояние меняет (как минимум, не сохраняются данные индексов). В случае сбоя всегда лучше изменять данные по минимуму -- так больше шансов что-то вытащить

+(26) и читайте "классику" в оригинале (13)

(29) Так смысл архивной копии в том, чтобы сжать по-максимуму. Какие индексы? Их просто под нож))))

Если в СУБД косяк с итогами, то выгрузка/загрузка изменит картину: восстановленная база из dt не будет точной копией, а иногда это необходимо (например, баланс уже сдан с "кривыми" итогами и надо сделать копию в том же виде для разборов)

(31) Да ладно!!!! о_О

(0) dt использую для загрузки в тестовую базу для разработки/доработки и пр.

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

(33) Чего ты заводишься? Скажи нормально - нельзя потому-то и поэтому. Мне тоже не понятно - почему?

(34) Франч? На повременке? У меня база 120 гигов. Выгрузить в дт/загрузить из дт сколько времени будет занимать?

(36) нет, я фикси в молодой строительной фирме. Мне пока можно делать dt :) Размер его пока что ~ 800 метров

(36) Ну вот и выяснили. Понятное дело, что 120 гигов выгружать в дт бессмысленно.

(35) Да не завожусь я :)
Например (32). Смысл архивной копии: В случае сбоя поднять базу в том же состоянии, в каком она была на момент бекапа. Так же важно время, за которое можно отресториться в случае сбоя.
(38) Ну, у меня не все базы такого большого размера. :)

(0) Все зависит от жизненной ситуации, я считаю.

(39) А из dt - не поднять?
Я понимаю, что выгрузка изменяет (те же индексы). Но в случае сбоя - так ли уж важны индексы?

На стройках кирпичи не каждый день на головы падают, и даже не каждый год. Но это не отменяет каски. Так и с dt - у кого-то может с 2000-го года всё быть в порядке, а у кого-то и через полгода может случиться косяк в базе, который не даст восстановить бэкап из dt. А вот обычный архив папки с базой (в файловом варианте) будет проще восстановить.

(41) dt может попросту взять - и не загрузиться.

(41) А из дт у тебя может, например, оборотка поплыть от оригинала.

(43) А может и загрузиться :)
(44) Может или должна?

(44) случаи были? пруф?

(46) При загрузке из дт, как минимум, пересчитываются итоги. Дальше, думаю можно не продолжать.
Пруфа нет.

Такие вещи в инет не выкидываю

(45) Ну нас ведь интересует именно форс-мажорные случаи:-)

(47) (48) ааа, извиняюсь! не так понял.
Я прочитал как "обрАботка может поплыть" )))
Думаю, нихренасе, внешние обработки может исказить)

(49) Выше писала: у был один раз форс-мажор - не загрузился dt. Но там и база была подыхающая. Один раз это какой процент?

(45) которая из букв в (13) непонятная?

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

(53) Что ж вы все дальше не читаете-то? Я еще раз могу повторить: "Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы". Еще проще -- если восстановиться из бэкапа скуля, его еще можно испортить загрузкой/выгрузкой. А вот обратное уже не работает.

А я считаю так: кто хочет делать бэкапы в dt, пусть делает. Ну если не учит чужой опыт людей и рекомендации производителя ПО им тоже ни о чём, то что тут поделаешь.

Да не загружается dt вот и всё! (в случае битых баз), а чтоб не битые были надо ТиИ а перед этим бекап. У меня один раз не развернулся. Опыту...

Для тех кто в танке (ну то есть на документацию) на Большой Партнёрке Нуралиев сказал (вольно к тексту): dt - для переноса из файлового в серверный и наоборот, бекап в файле (тока файл 1CD, в монопольном доступе) в сервере средствами СУБД. Всё!

(5) Не знаю что там с вашими обезьянками, а я лично сталкивался со случаями отказа восстановления БД из dt по меньшей мере дважды.

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

PS. Лезьте за своим бананом. Я вам мешать не стану.

(58) Аналогично. Работало, работало. А потом бац и перестало загружаться. Хорошо резервирование настроено другими средствами. Надо было рядом копию базы сделать, но не удалось. Всему виной было превышение размера внутреннего файла.

(0) Даже не принимая во внимание страшилки про незагружаемые dt, SQL быстрее же и выгонять никого не надо, не?

(60) увы... усе не готовы покупать SQL :-(

(61) ну если файловая, скопировал папку тупо. еще проще. еще быстрее.

(61) Постгри.

А вот интересно, для тех у кого файловая, архивный копии тоже через DT выкручивают или все-таки архиватором непосредственно каталог базы или файл базы архивируют?

Я лично делаю так, как доступно. Если прав админа на сервер у меня нет, а бакап нужно делать, то выгружаю в DT, чтоб можно было без сервера на локальной машине поднять. Но для очень больших баз или для тормозного сервера таким методом не получится. Не говоря уже о том, что "битые" данные DT не лечит, а окончательно убивает.

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

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

Насколько я понимаю, что видел у продвинутых людей, разностные бекапы делаются не только на уровне SQL, но и самим акронисом всего сервера СУБД. На тот случай, если совсем все плохо станет ;)

(0) 1.Если база файловая - быстрее скопировать, если серверная - быстрее сделаит бэкап средствами базовода.
2.с вероятностью до 1% база из DT не будет восстановлена.

(5) В отчете SQL размер временных таблиц превышает 4 Гига? У нас превышает и не грузится. Таблица регистра версионирования.

(0) Dt при выгрузке не контролирует целостность данных. При загрузке из-за нарушения целостности может не загрузить. Если перед выгрузкой делаете ТиИ, то и бэкапы делать можно.
В тоже время бэкап средствами СУБД полностью сохранит все баги и их можно будет после восстановления исправить.

всем спасибо, все очень подробно и понятно!

(69) я бы перед тии все же сделал бы бэкап любым из доступных способов ;)

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

Единственный плюс копирования всей файловой базы это журнал регистрации
А дт это по сути сначала чекдбф а потом зип

Ничего нежелательного нет.
Можно спокойно выгружать базу в dt.
Главное архивы с помощью такой  выгрузки не делайте.

(0) выгрузка в DT идёт существенно дольше, чем средствами SQL

(64)Архивные копии всегда делают средствами СУБД.
Если sql - значит средствами скуля.
Если файловая - значит средствами файловой системы.

У меня сделано так -
1)делается теневая копия диска содержащего файл 1с.
2)монтируется теневая копия и файл упаковывается архиватором.
3)файл отсылается в место хранения, и формируется отчет.

(51) Вы матстатистику и теорвер будете финику, гендиру и главбуху объяснять, когда бэкап базы не взлетит за день до сдачи отчетности и компания влетит на штраф в десяток-другой лямов :)

В вопросах бэкапов вопрос не в том, что МОЖЕТ НЕ произойти, а вот, что МОЖЕТ произойти. Если вы не понимаете эту азбучную истину, то рано или поздно поймете на своем опыте.

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

(0) Потому что зачем делать лишние преобразования данных, причем теоретически могут быть проблемы при восстановлении из dt. Упакуй *.cd в zip и получишь примерно то же.

(0) По сравнению с backup MS SQL во-первых дольше как ВЫгружать, так и ЗАгружать, во-вторых появляется необходимость выгонять пользователей, в-третьих нет преимущества в объеме хранимых данных (сжатый backup, насколько мне известно, весит примерно столько же сколько dt).

(54) Вы не понимаете прочитанного текста.

1cd включающий в себя косяки - уже не база данных. Это непрофессионализм.

(80) SQL - это не стандартно. Это не 1с. А dt - стандартно.И 1с гарантирует, что это всегда будет работать.

Я видел как просто переводят базу SQL в состояние "офлайн" и копирует куда-то там файл SQL-базы.

(83) Проснись и пой. Все наоборот.

(83) Опасно так думать..:)

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

(87) Еще один. Сегодня полнолуние что ли?

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

(89) Мда. Удачи :))

(90)Ну у каждого свой негативный опыт. Хорошо когда есть альтернатива.Поэтому не вижу причины, с упорством фанатика, заставлять всех переходить в свой лагерь и всех противников объявлять еретиками и призывать придать их анафеме

(91) Да, собственно, конечно есть.
Но в данном случае:
1. Делать копии файла 1CD рекомендует сама 1С.
2. Делать бекапы средствами скуля, а не выгрузкой в DT опять же рекомендует сама 1С. И более того, скулем можно делать выгрузку без выгона пользователей и автоматически. А вот в DT с выгоном и по праздникам.

(91) +1. Всё правильно сказал.

Я, например, не пытаюсь никого убедить в том, что архив в *.dt лучше/хуже других методов. Я просто говорю, что проблем с *.dt я ни разу не встречал.
Вообще, я считаю, что все эти проблемы с *.dt были на заре 1Cv8, но сейчас уже весь код платформы отлажен в этом сегменте и всё стабильно хорошо.

А переубеждать кого-то я не собираюсь - не вижу смысла. Каждый сам выбирает себе путь. Я себе уже выбрал.

Аналогично. Регулярно делаю дэтэшники, но естественно sql-сервер регулярно своими средствами бэкапит по плану.

(92) у скулевских бэкапов есть проблемка... не развернуть в файловом варианте на локальной машине для ковыряния :)

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

(96) примерно так, справедливо для MS SL2008 Express (не претендую на истину в последней инстанции):
1. делаем файлик, например BackSQL.sql со следующим содержимым:
BACKUP DATABASE [имя БД] TO  DISK = N'E:\BackUpSQL\имя Файла архива.bk' WITH NOFORMAT, NOINIT,  NAME = N'Понятное название латиницей', SKIP, NOREWIND, NOUNLOAD
GO
это же можно получить из SQL Server Management Studio, делай как больше нравится.
пишем bat файл:
start /wait osql -U <Юзер SQL> -P <его пароль> -i BackSQL.sql
можешь добавить сжатие полученной копии в rar или zip.
Ставим его в виндовый шедулер с запуском, например, через каждый час. Получаем ежечасную, автоматическую копию базы данных, но тут есть одна особенность: файл резервной копии дополняется(!!!) каждый раз, так что придётся выстроить механизм его перемещения вечером или сразу после создания, что-бы не вырос до безобразия.
  Для полной версии можешь задействовать план обслуживания. будет несколько проще.

Для получения полной резервной копии всей БД:
set hom=e:\BackUpSQL
set path1С=e:\Base1C

rem Разделение даты на составляющие исходя из формата 20.10.2006
for /F "TOKENS=1,2,3 DELIMS=." %%a in ('Date /T') do (set day=%%a)&&(set mon=%%b)&&(set year=%%c)
rem set year=%year:~0,4%
rem set day=%day:~3,2%  если есть ПТ 20.10.2006
set dt=%year:~0,4%-%mon%-%day%

del %hom%\3\Full\*.* /Q
move %hom%\2\Full\*.* %hom%\3\Full
move %hom%\1\Full\*.* %hom%\2\Full

rem стопим сервисы
net stop "Агент сервера 1С:Предприятия 8.2"
net stop MSSQLSERVER
net stop sqlbrowser
net stop sqlwriter

start /wait %hom%\rar a -y %hom%\1\Full\%dt%-SQL-Buh %path1С%\<Маска имени БД*.*> - забираем БД и файлы журнала

rem стартуем сервисы
net start MSSQLSERVER
net start sqlbrowser
net start sqlwriter
net start "Агент сервера 1С:Предприятия 8.2"

  В шедулер, например, на 23:50 и радуйся жизни.
Обрати внимание: копии создадутся на том же диске что и сама БД, поменяй пути и настрой копирование куда-нить кроме как локальная машина.
Для начала хватит, а дальше сам разберёшься.

Ошибка при загрузке dt

(98) и чо?

(99) И то. 1С не гарантирует, что загрузится

(0) см. параллельную ветку Ошибка при загрузке dt

(100) В ветке из (98) тема вообще-то звучит так "Перевожу базу из файлового режима в серверный."

А 1С между прочим как раз и говорит о том, что переходить из файлового варианта в клиент-серверный нужно через выгрузку в dt.
Так что ссылка на эту тему - мимо.

(102) Ну да, ну да. Конечно же мимо.

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

(98) (100) (101) Нифига, вы упоротые... :)
И как вы из файловой базы сделаете клиент-серверную, ежели не через *.dt? Через XML грузить будете?

И что теперь, если каждый студент будет пытаться битую базу завернуть в *.dt и сталкиваться с трудностями, то вы всенепременно будете поднимать эту ветку и тыкать пальцем?

Вообще, *.dt - это как индикатор: если у тебя с *.dt проблемы - пора лечить базу. Потому что в целой базе проблем не возникает.

а если сгорит офис вместе с серверами? хранить базу надо в облаке

(106)В дата центрах серверов нет и они не горят?

б о я н....

(106) Облако тоже может пропасть :)

(107), (108) Облако так же может накрыться, но поскольку оно географически удалено, то мало шансов, что оно накроется вместе с офисом.
Поэтому бэкапы не просто хранят в облаке, а дублируют в облако!