#4
by Масянька
Один-единственный раз была такая проблема - но там базе был капут. Поддержу ТС - почему?
#5
by Cube
Ну, это как про обезьян в клетке: Уже скоро будет 10 лет, как я делаю ежедневные бэкапы в *.dt и косяков не обнаруживал... Сейчас тут начнется про размер базы, лезвие ножа и т.п...
#10
by Aleksey
ТОже не понимаю истерии с dt. С 2006 году бекапы через dt делаю. Постоянно приходиться восстанавливать по разным причинам. Проблем нет. Размер dt 3 Гига
#13
by 0wl
Ну, например, потому, что сама 1С говорит, что dt не является средством резервного копирования. Если вендор сам рекомендует использовать другие способы, я не знаю, какие еще аргументы нужны
#14
by PLUT
потому-что сама 1С писала письмо, что dt нужно делать для переноса баз, а более правильно средствами БД или папку целиком (если файловая). Так больше вероятности, что бэкап не превратится в тыкву
#17
by Aleksey
"механизм предназначен, прежде всего, для получения образа информационной базы независимо от способа хранения данных." Точка.э
#18
by PLUT
запятая, э. читай внимательно. что dt нифига не гарантирует, а только является средством конвертации из файловой в серверную и наоборот
#19
by 0wl
Там дальше продолжение: "Использование этих способов [отличных от dt] дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных."
#20
by ЧеловекДуши
Вот тут... "Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных." Они уже официально оговорили, что все на страх и риск пользователя :)
#21
by ГдеСобакаЗарыта
Я делал раньше бекапы файловой в dt. А потом они у меня совсем не захотели загружатся в тяжкий для меня момент. Больше я в dt не бэкаплю. Такая грустная история((
#22
by Cube
С другой стороны, бывают ситуации, что эти нарушения можно лечатся только выгрузкой/загрузкой *.dt... Так что, тут бабушка надвое сказала...
#23
by Garikk
с авто неверная аналогия, если в феррари лить 92 то рано или поздно движок кирдыкнется...
#28
by Масянька
Это снеговик = феррари?! Блин, я-то думала, что феррари хорошая машина, а оказывается...
#29
by 0wl
Есть такое. Но бэкап средствами СУБД (или копирование папки файловой базы) сохраняет исходное состояние базы, а загрузка/выгрузка это состояние меняет (как минимум, не сохраняются данные индексов). В случае сбоя всегда лучше изменять данные по минимуму -- так больше шансов что-то вытащить
#31
by Cube
Так смысл архивной копии в том, чтобы сжать по-максимуму. Какие индексы? Их просто под нож))))
#32
by Зеленый пень
Если в СУБД косяк с итогами, то выгрузка/загрузка изменит картину: восстановленная база из dt не будет точной копией, а иногда это необходимо (например, баланс уже сдан с "кривыми" итогами и надо сделать копию в том же виде для разборов)
#34
by oslokot
dt использую для загрузки в тестовую базу для разработки/доработки и пр. Ну и для бэкапа, каждый день. Но главный бэкап это конечно же средствами скуля.
#35
by Масянька
Чего ты заводишься? Скажи нормально - нельзя потому-то и поэтому. Мне тоже не понятно - почему?
#36
by Heckfy
Франч? На повременке? У меня база 120 гигов. Выгрузить в дт/загрузить из дт сколько времени будет занимать?
#37
by oslokot
нет, я фикси в молодой строительной фирме. Мне пока можно делать dt :) Размер его пока что ~ 800 метров
#39
by Heckfy
Да не завожусь я :) Например . Смысл архивной копии: В случае сбоя поднять базу в том же состоянии, в каком она была на момент бекапа. Так же важно время, за которое можно отресториться в случае сбоя. Ну, у меня не все базы такого большого размера. :)
#41
by Масянька
А из dt - не поднять? Я понимаю, что выгрузка изменяет (те же индексы). Но в случае сбоя - так ли уж важны индексы?
#42
by snegovik
На стройках кирпичи не каждый день на головы падают, и даже не каждый год. Но это не отменяет каски. Так и с dt - у кого-то может с 2000-го года всё быть в порядке, а у кого-то и через полгода может случиться косяк в базе, который не даст восстановить бэкап из dt. А вот обычный архив папки с базой (в файловом варианте) будет проще восстановить.
#47
by Heckfy
При загрузке из дт, как минимум, пересчитываются итоги. Дальше, думаю можно не продолжать. Пруфа нет.
#50
by oslokot
ааа, извиняюсь! не так понял. Я прочитал как "обрАботка может поплыть" ))) Думаю, нихренасе, внешние обработки может исказить)
#51
by Масянька
Выше писала: у был один раз форс-мажор - не загрузился dt. Но там и база была подыхающая. Один раз это какой процент?
#53
by Масянька
"Основным недостатком такого способа создания резервной копии является необходимость использования однопользовательского режима для осуществления этой операции. При большом объеме информационной базы перерыв в работе пользователей может быть достаточно велик, что не всегда приемлемо." - для меня в этом проблемы нет.
#54
by 0wl
Что ж вы все дальше не читаете-то? Я еще раз могу повторить: "Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы". Еще проще -- если восстановиться из бэкапа скуля, его еще можно испортить загрузкой/выгрузкой. А вот обратное уже не работает.
#55
by Fish
А я считаю так: кто хочет делать бэкапы в dt, пусть делает. Ну если не учит чужой опыт людей и рекомендации производителя ПО им тоже ни о чём, то что тут поделаешь.
#56
by MSOliver
Да не загружается dt вот и всё! (в случае битых баз), а чтоб не битые были надо ТиИ а перед этим бекап. У меня один раз не развернулся. Опыту...
#57
by MSOliver
Для тех кто в танке (ну то есть на документацию) на Большой Партнёрке Нуралиев сказал (вольно к тексту): dt - для переноса из файлового в серверный и наоборот, бекап в файле (тока файл 1CD, в монопольном доступе) в сервере средствами СУБД. Всё!
#58
by Dmitrii
Не знаю что там с вашими обезьянками, а я лично сталкивался со случаями отказа восстановления БД из dt по меньшей мере дважды. А дальше можете хоть обделаться, рассказывая как 100500 миллионов раз вы выгружали и успешно восстанавливали базы через dt-шник. Никакие самые авторитетные мнения не смогут заменить личного печального опыта в таком вопросе. PS. Лезьте за своим бананом. Я вам мешать не стану.
#59
by kosts
Аналогично. Работало, работало. А потом бац и перестало загружаться. Хорошо резервирование настроено другими средствами. Надо было рядом копию базы сделать, но не удалось. Всему виной было превышение размера внутреннего файла.
#60
by Бубка Гоп
Даже не принимая во внимание страшилки про незагружаемые dt, SQL быстрее же и выгонять никого не надо, не?
#64
by Фрэнки
А вот интересно, для тех у кого файловая, архивный копии тоже через DT выкручивают или все-таки архиватором непосредственно каталог базы или файл базы архивируют?
#65
by Фрэнки
Я лично делаю так, как доступно. Если прав админа на сервер у меня нет, а бакап нужно делать, то выгружаю в DT, чтоб можно было без сервера на локальной машине поднять. Но для очень больших баз или для тормозного сервера таким методом не получится. Не говоря уже о том, что "битые" данные DT не лечит, а окончательно убивает.
#66
by Новиков
Сможет так случиться, что в файловой верии размер одной таблицы базы превысит 4 Гб. Соответственно, в этом случае, выгрузка пойдет болтом. Про скульные бекапы, гут да. Но нужно один раз поморочиться, если бекапы нужны ежечасные, покурить все эти транзакшн-логи и т.д. Насколько я понимаю, что видел у продвинутых людей, разностные бекапы делаются не только на уровне SQL, но и самим акронисом всего сервера СУБД. На тот случай, если совсем все плохо станет ;)
#67
by rphosts
1.Если база файловая - быстрее скопировать, если серверная - быстрее сделаит бэкап средствами базовода. 2.с вероятностью до 1% база из DT не будет восстановлена.
#68
by Одинесю
В отчете SQL размер временных таблиц превышает 4 Гига? У нас превышает и не грузится. Таблица регистра версионирования.
#69
by Lama12
Dt при выгрузке не контролирует целостность данных. При загрузке из-за нарушения целостности может не загрузить. Если перед выгрузкой делаете ТиИ, то и бэкапы делать можно. В тоже время бэкап средствами СУБД полностью сохранит все баги и их можно будет после восстановления исправить.
#72
by John83
у самого только раз дт не загружалась - конфа поставщика крякнулась, причем очень надо было
#73
by Сияющий в темноте
Единственный плюс копирования всей файловой базы это журнал регистрации А дт это по сути сначала чекдбф а потом зип
#74
by Jump
Ничего нежелательного нет. Можно спокойно выгружать базу в dt. Главное архивы с помощью такой выгрузки не делайте.
#76
by Jump
Архивные копии всегда делают средствами СУБД. Если sql - значит средствами скуля. Если файловая - значит средствами файловой системы. У меня сделано так - 1)делается теневая копия диска содержащего файл 1с. 2)монтируется теневая копия и файл упаковывается архиватором. 3)файл отсылается в место хранения, и формируется отчет.
#77
by Drac0
Вы матстатистику и теорвер будете финику, гендиру и главбуху объяснять, когда бэкап базы не взлетит за день до сдачи отчетности и компания влетит на штраф в десяток-другой лямов :) В вопросах бэкапов вопрос не в том, что МОЖЕТ НЕ произойти, а вот, что МОЖЕТ произойти. Если вы не понимаете эту азбучную истину, то рано или поздно поймете на своем опыте.
#78
by НП
Если из dt база не восстанавливается, то её уже нет. Возможно, давно. Поэтому и нужно выгружать в dt, чтобы база жила. Желательно её потом восстанавливать в файловую. Если очень большая, не получится.
#79
by su_mai
Потому что зачем делать лишние преобразования данных, причем теоретически могут быть проблемы при восстановлении из dt. Упакуй *.cd в zip и получишь примерно то же.
#80
by GANR
По сравнению с backup MS SQL во-первых дольше как ВЫгружать, так и ЗАгружать, во-вторых появляется необходимость выгонять пользователей, в-третьих нет преимущества в объеме хранимых данных (сжатый backup, насколько мне известно, весит примерно столько же сколько dt).
#83
by НП
SQL - это не стандартно. Это не 1с. А dt - стандартно.И 1с гарантирует, что это всегда будет работать.
#84
by Casey1984
Я видел как просто переводят базу SQL в состояние "офлайн" и копирует куда-то там файл SQL-базы.
#87
by Aleksey
и получишь нерабочую базу, так как выгрузка в dt гарантирует что в этот момент в базе никто не работает и не проводит документы или не сохраняет конфигурацию
#89
by Aleksey
нет, просто с 2006 выгружаю в dt и проблем не наблюдаю, в отличие от копирования cd файла, когда в этот момент юзверь проводит документ, или от копирования bak файла скуля, когда в нужный момент оказывается не та версия скуля, а какая там была никто не помнит
#91
by Aleksey
Ну у каждого свой негативный опыт. Хорошо когда есть альтернатива.Поэтому не вижу причины, с упорством фанатика, заставлять всех переходить в свой лагерь и всех противников объявлять еретиками и призывать придать их анафеме
#92
by PR2
Да, собственно, конечно есть. Но в данном случае: 1. Делать копии файла 1CD рекомендует сама 1С. 2. Делать бекапы средствами скуля, а не выгрузкой в DT опять же рекомендует сама 1С. И более того, скулем можно делать выгрузку без выгона пользователей и автоматически. А вот в DT с выгоном и по праздникам.
#93
by Cube
+1. Всё правильно сказал. Я, например, не пытаюсь никого убедить в том, что архив в *.dt лучше/хуже других методов. Я просто говорю, что проблем с *.dt я ни разу не встречал. Вообще, я считаю, что все эти проблемы с *.dt были на заре 1Cv8, но сейчас уже весь код платформы отлажен в этом сегменте и всё стабильно хорошо. А переубеждать кого-то я не собираюсь - не вижу смысла. Каждый сам выбирает себе путь. Я себе уже выбрал.
#94
by Wist
Аналогично. Регулярно делаю дэтэшники, но естественно sql-сервер регулярно своими средствами бэкапит по плану.
#95
by Wist
у скулевских бэкапов есть проблемка... не развернуть в файловом варианте на локальной машине для ковыряния :)
#96
by МимохожийОднако
У кого-нибудь есть инструкция для чайника резервного архивирования средствами SQL во внешний файл, чтобы можно было спокойно брать вчерашний день и загружать в другой SQL в другом месте?
#97
by Fedor-1971
примерно так, справедливо для 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. Ставим его в виндовый шедулер с запуском, например, через каждый час. Получаем ежечасную, автоматическую копию базы данных, но тут есть одна особенность: файл резервной копии дополняется(!!!) каждый раз, так что придётся выстроить механизм его перемещения вечером или сразу после создания, что-бы не вырос до безобразия. Для полной версии можешь задействовать план обслуживания. будет несколько проще. Для получения полной резервной копии всей БД: 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 rem стопим сервисы net stop "Агент сервера 1С:Предприятия 8.2" net stop MSSQLSERVER net stop sqlbrowser net stop sqlwriter start /wait %hom%
ar a -y %hom%1Full%dt%-SQL-Buh %path1С%<Маска имени БД*.*> - забираем БД и файлы журнала rem стартуем сервисы net start MSSQLSERVER net start sqlbrowser net start sqlwriter net start "Агент сервера 1С:Предприятия 8.2" В шедулер, например, на 23:50 и радуйся жизни. Обрати внимание: копии создадутся на том же диске что и сама БД, поменяй пути и настрой копирование куда-нить кроме как локальная машина. Для начала хватит, а дальше сам разберёшься.
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям
Похожие вопросы 1С
В этой группе 1С
- Внешние источники данных 1С, ошибка запроса
- Не восстанавливается база из полного бэкапа MS SQL
- штрихкодирование убрать цифры из штрихкода
- Сколько вопросов в профке ERP2.0?
- Внешняя печатная форма на СКД
- СКД, отображение параметров в пользовательских настройках
- Событие ПриПолученииДанных. Ступор...
- Ошибка "в этой транзакции уже происходили ошибки".
- 1с конвертация данных индекс находится за границами массива
- Китайская СУБД. Не могу найти. [нашел южно-корейскую Tibero]
- Всплывающая подсказка динамического списка
- Неверно указан реквизит в 8.3
- ЗУП Алименты 50% исполнительный 50%
- Как определить из какого документа открыта форма?
- расшифровка в ячейке макета
- УПП. 1,3. Распределение косвенных затрат на не выпускающие подразделения.
- Тормоза 1С после обновления с 8.3.5 на 8.3.6
- Формирование штоихкода EAN8
- Поменять ставки ндс в рознице 2.1
- Метод ПолучитьОбъект() выдает ошибку через ком соединение