Загрузили информационную базу (.dt) не в ту базу #698459

Гуру 1С и Mysql, выручайте советом. Есть сервер 1с 8.2 + сервер Mysql 2012. Ошибочно загрузили дт-шку не в ту базу, через Конфигуратор. База была тестовая, но как оказалось, важная. Резервные копии, конечно, нигде не велись. Образ сервера с mysql не делался. Можно как-то откатить состояние базы до залития бэкапа?

а 1с уже с май скулем работает?

Это вопрос к SQL теперь больше, а не к 1С.

а если мсскуль и не велись бекапы - то думаю и не влеся бекап скулевыми средствами.. так что скорее всего никак

SQL, конечно. Просто немного шоковое состояние.

ты еще не вышел из шока, ибо ничего не уточнил )

точно майскуль?

предположу что нужно откатить транзакцию

Всё. Аминь.

Ничего не сделаешь, смирись.

Microsoft SQL Server 2012. Бэкап залили посредством 1С.

пипец базке dt загружается в булк режиме, откатить из лога нечего

Более надежный способ похоронить базу еще придумать надо. Так что - увы...

Если в MS SQL не настроено резервное копирование этой базы, то всё.

Спасибо

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

Рекомендуется применять вот это средство в большом количестве

Я не знаю, что можно в кеше посмотреть - если но не почистился.

Спроси у админа- все можно восстановить

+18 Покрайней мере мне мой админ так всегда говорил

вазелин не наш метод. У нас бизнес-гель)))

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

Он его не заслужил. Врут твои админы. Как сидоровы козы врут.

Ну, таких баек я не слыхал. Слыхал, что есть стенды, умеющие восстанавливать инфу по остаточным шлейфам (микронеточностям позиционирования головки при записи в рамках допусков). Именно поэтому стандарты программного уничтожения информации предусматривают многократную перезапись случайными последовательностями. Но даже на таком оборудовании восстановление сложных структур данных больших объемов типа затертой SQL-базы - нечто из области фантастики, ИМХО.

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

Только это к ГУРУ MS SQL - тут такие не появляются.

Восстанавливать информацию с магнитных дисков лазерным считывателем это нечто новое. Стенды есть и это не фантастика. Разумеется дорогие, точнее нереально дорогие, и разумеется не в свободной продаже. Но тут надо понимать что восстанавливают эти стенды - огромное счастье если с диска можно будет вытащить процентов 30 файлов. Причем естественно все эти файлы будут битыми. Но это уже лучше чем полный ноль. Отдаешь эти битые файлы команде аналитиков, те тратят сотни две, три человекочасов пытаясь собрать мозаику и в итоге выдают более менее достоверную гипотезу о содержимом нужного файла. Вот это и подразумевается под словом восстановить информацию. А все почему то думают что они работают по принципу - сунул диск в аппарат, через пять минут вытащил, и вуаля у тебя точная побайтовая копия того что было на диске три года назад.

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

[Если полная модель восстановления - то шансы должны быт] dt загружается в булк-режиме, если тебе этот термин не знаком - погугли

Ну, если транзакции не пакетами идут, а всё сразу (по-умолчанию, написано, что BULK-INSERT делает одну транзакцию), то что-то можно посмотреть. Если же разбили по пакетам, то - "уже всё".

если есть бэкап этой базы на любой момент времени перед заливкой, даже самый древний, то можно восстановить

В таких случаях утешает только одно: еще один админ начал делать бэкапы. Может быть.

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

а я делаю

ну дай тс тогда, че зажал то ))

Все, если нет бекапа, то каюк старой базе.

Голосовалку сделай

без фулбэкапа sql или dt никак. Только пользователей успокаивать. 1.Тестовая среда может рухнуть в любой момент или может быть перезалита, это нужно донести до тех кто в ней ковыряется. 2. Если нужно сделать что-то важное (например, снимок базы перед сдачей бух баланса, в котором еще потом что-то еще кто-то наковырял) - создается отдельная резервная  база  для группы или на каждого юзверя своя 3. Если сведения очень важные - нужен сиквельный бэкап 4. Если юзвер истерит  (у меня бывали похожие ситуации) - шли накер. Ибо: 5. Нужно предупреждать - не предупредили значит никому не нужно, поднимается база на точку отсчета и юзверь набивает руками все заново 6. Самое важное это рабочая база. 7. Истерику надо лечить и вообще, на работе должна быть рабочая атмосфера. Ну и в дополнение скажу еще вот что: если нет регламента (не расписаны процедуры, указы, инструкции) - значит ничего не было и не нужно никому.

Есть бэкап месячной давности. Базу перезатерли вчера

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

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

Вот в этом то и дело. Если информация в базе важна - делают бэкапы. Пофиг тестовая или рабочая она. Если в базе бардак, и проще сделать заново, ну действительно нафига бэкапы. Никто не огорчится если базу сотрут.

ТС, MS SQL умеет восстанавливать базы на нужный момент времени. Откатишь на время перед загрузкой. Кури команду RESTORE, ключ STOP AT. А лучше позови специалиста, пока в шоковом состоянии еще чего-нибудь не поломал.