При восстановлении бекапа SQL 2008 недостаточно места на диске. #597542

Собственно прикол неприкольный: есть база, MDF гдето мегов 800 есть бекап - фулбекап средствами SQL  - тоже мегов гдето 800. восстанавливаю в новую базу - пишет заммечательную фразу про то что нехватает места на диске для восстановления. это при том что на диске свободных 150 гигов. сталкивались?

причем в настройках бекапа стоит флажок проверки..

у тебя лог пухнет, перенеси лог новой базы на пустой терабайтник и модель поставь семпл

а файло скульное точно на этом диске лежит, и на него востанавливается. для гиговой базы лог больше чем 150 гб? быть не может.

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

симпле

автоприращение "вкл"?

темпдб по умолчанию на диске ц, посмотри свободное место там а вообще лог должен пухнуть при востановлении

угу.. стандартные 10% неограниченные

>а вообще лог должен пухнуть при востановлении да, но не на 150 Гб.

глупый вопрос - а диск не на fat32?

да непухнет там ничего оно даже не начинает восстанавливаться - мгновенно вырубается с ошибкой причем самый прикол в том что я на виртуалке поднял СУБД - там тоже не грузится...ровно с такой же причиной

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

бгыы фат16 епта... ясное дело что нет :) причем оригинальный сервак x64 сервер 2003тий виртуалка - XP 32p

>друге дело что сразу после он шринкуется... это понятно - контрольная точка наступает... служба скуля от кого крутится?

вот чо пишет

гы...

под системной учеткой

может, бэкап битый?

220 гигов - многовато

прикол в том что бекапит без проблем.. в плане стоит проверка бекапов... и так восстанавливаются ВСЕ бекапы (они каждый день делаются полные) - вернее ВСЕ бекапы с такой ошибкой восстанавливаюстя - вернее невосстанавливаются.

угу.. это скрин с виртуалки где всего 10 гигов..  :)

что говорит тестирование бэкапа?

+ и базы?

а нагуя ты его на С: восстанавливаешь? попробуй восстанови на Д: и мдф и лдф

база рабочая.. без проблем все.. просто надо было восстановить на предмет "чо было до обновления" :) бекапы бекапятся.. флажок "верифи бекап интегрити" стоит и ошибок не выдает - все бекапится как положено...

это виртуалка - на ней нет Д. на рабочем серваке где Д 150 гигов - пробовал туда восстановить - та же херь...

а что за база? 1с? или чо?

1С, 1С... типовая бухня...

ну найди диск с 300 гигами и восстанови туда

если сделать выгрузку - сколько она занимает? и восстанавливается ли?

тааааак.... а у тебя бэкапится не транзакшн лог случаем???

+31 и может это только дельта на 200 мегов?

+32 и вообще. С: под ось, Д: под мдф, Е: под лдф

что говорит restore headeronly ? там точно просто фулбекап?

Глава корпорации Microsoft Билл Гейтс в 1981 г. считал, что "640 килобайт памяти должно быть достаточно для каждого компьютера"

о! попробуй восстановить бэкап не на точку "бэкапирования" а на секунду пораньше

>о! попробуй восстановить бэкап не на точку "бэкапирования" а на секунду пораньше это каким манером из фулбэкапа то?

указать дату и время в поле "To a point in time"

Ща домой приеду - скормлю ему террабацтник. Пусь подавиться сволоч.

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

и давно фулбэкап научился работать с "To a point in time"?

терзают меня сомнения что там как раз не фулл и не симпл

а спросил про это в

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

, отпишись по результатам, пожалуйста

расскажи это диску Це у которого 140 гигов свободно... угу.. поднимаю виртуалку на террабайт.. буду тестить седня

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

тупой вариант: выгрузить в dt создать новую базу на сиквеле загрузить из dt забэкапить попробовать восстановить и таким образом понять где локализована ошибка ?

я уже предлагал

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

ща ща ща.. террабайтная виртуалка поднимется - посмотрим чо оно скажет :)

скока весит?

? бак - весит 800 метров дт - 250 - но там конфа с разрешенными изменениями.. то есть 2 цфника... то есть нормальный размер

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

ты не въехал создай новую базу через dt и проверь для неё валидность скулевских бэкапов

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

я тупой.. как проверить валидность скулевских бекапов ?

бэкап - ресторе ясен пень но загрузив из dt ты исключишь наличие внутри какого-нибудь говна вроде не закрытой транзакции

на всякий случай, путь то к базе при ресторе ты менять пробовал

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

попробуй RESTORE FILELISTONLY  , чтобы зырнуть размеры файлов. и всё-же, сдавлю дайм на разбухшие логи

Это не скуль тупой. Это вы тупите на пустом месте. Если он вам написал что нету места - значит его нету. И нефиг железку мучить.

плять.. там места 140 гигов..  выгрузка 800 база в симпл режиме работает и занимает вместе с ldf порядка гига... ну реально  - гиг... 840 мегов мдв и 200 - лдф...

[я ресторе пытаюсь вообще в пустую базу восстановить - один хрен.] ещё раз что у тебя на второй закладке  в качестве пути указано ?

сделай , посмотри размеры файлов и где лежали... и вообще как восстановление происходит? через gui или скрипт?

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

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

он скорее всего пытается сделать move куда то... + хз что за размеры файлов базы (не путать с размерами базы) указаны в ней..

хз хз.. ща тестовый виртуальный сервак запустится.. там ща тупорылые фремворки ставятся... там террабайт места - посмотрим посмотрим..

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

блин, чё-то sql.ru лежит...

Для тех кто в танке - картинка показывает что на диске С свободно всего лишь 10 Гиг. На виртуалке поднимаете?

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

скриншот ошибки сделай

еще бы это проверить: может кто в свойства базы залез не удачно и сменил " initial size value"

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

и тогда любая база новая будет стремиться отожрать место сколько указано в свойствах...

+100

угу.. яж выше писал размеры файлов базы восстановленной из ДТ... 800+200

Тогда с определенной вероятностью виртуалка у вас с динамическим диском. Смотрите текущее занятое место, добавьте 40 Гиг и сделайте размер фиксированным. Все получится. Вот только мне так и непонятно - зачем все лепить на диск С ?.. Ну да ладно.

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

ну и когда ты посмотришь свойства базы?

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

скуль ставится... минут через 10 посмотрю :) я забрал все бекапы за неделю - ща буду смтреть чо там и как...

а ты при ресторе на второй вкладке имена файлов часом не забыл поменять?

и вообще при востановлении в непустую базу требуется место старая база + новая база + лог

да я пробовал пробовал... да дохрена места то было.. в том то и проблема.

там при рестроре есть 2 механизма, один льет прямо в файл, другой через скуль ты каким делаешь?

RESTORE FILELISTONLY FROM DISK = '<Путь_к_файлу>'

вот же наглая скотина.. 213 гигов LDF при восстановлении... шизануца

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

симпл, говоришь?

точно, симпл...

и ведь уже полтора часа  - восстанавливается...

Что б не ждать восстановления можно пойти другим путем. Шринкуешь базу, отключаешь ее, архиватором сжимаешь mdf и ldf, забираешь архивы с собой. Дома распаковываешь архив и присоединяешь базу. Будет немного быстрее. Еще быстрее если для этого воткнешь в сервак жесткий на который будешь лить сразу mdf и ldf, минуя архиватор, потом жесткий уносишь домой.