Проблема с копированием большого файла. #600848

Ось 2003 сервер, файл полнай бекап скульной базы 82 гига. Уже второй день не копируется на другой комп (для надеги). Ручное копирование на USB-диск или на локальный диск этого же компа тоже ничего не дает. Сообщение после 32% (или около этого) копирования: "Невозможно завершить операцию из-за нехватки системных ресурсов." Что за хрынь и как ее побороть?

чем копируешь?

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

Проводником и Тотальником - одновинтово. Регламентно ночью nnBackup в районе 112гиг

FTP, не?

Windows Backup

Не пробовал. Сейчас проверю.

FTP не хочет - время ожидания истекло.

а архивнуть?

А на системном есть свободные 82Гб?

Свободно 258 гиг

Попробуй разбить винраром на 4 архива.

посмотри в сторону консольной команды Robocopy (она есть в 2008 сервере, а для предыдущих версий её можно поставить отдельно)

Да и при создании backup SQL умеет сразу сжимать файлы. Получаемый архив заметно меньше выходит. Не хочешь этим воспользоваться?

антивируса у тебя случаем не стоит?

uTorrent + AutoIt ?

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

2-ой комп система ФАТ, НТФС, ...? Странно вот что: при размере ИБ сейчас у меня 52Гб, полный архив из под постгреса = 1,2ГБ

+ время создания архива где то 5-15мин.

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

Получилось! Тотальником порезал на 5 файлов по 20гиг, скинул на другой комп и собрал без проблем. Но это решение "через Альпы" (так Суворов в Европу ходил). Буду искать более подходящее, поизящнее.

пока Вы не проверили работоспособность бекапа грош - цена Вашему "Получилось!"

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

значит это повод

А Shrink давно делался?

я тут как-то качал фильм под 50 ГБ - копировал нормально

до почти 81 гига тоже все нормально было

Та же фигня - проблема в сети или серверах у меня тоже никак с одного сервера не стащить архив около 80 гигов причем админ на свой комп нормально скопировал win2003 и ХР локально

антивиря случаем нет ?

Хотя последний раз пытался с NAS  скачать...

Может и антивирус

Угу... Есть такая фигня... Недавно пытался скопировать файлик в 93 гига - та же самая ошибка.

Юмор в том, что в пределах сервера в другую папку на том же диске тоже не копируется. Та же ошибка. Неужели NTFS тоже имеет ограничения на размеры файла? Кстати - винда 2033 стандарт 32 бита - может здесь србака порылась?

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

Тоже думаю, что проблема не в этом. Просто ума не приложу с каких яиц эта ошибка вылупилась... Блин... Надо разбираться в самой утилите копирования: раз места на диске с трехкратным запасом - остается оператива - может ее не хватает для каких-то целей. Сам в шоке - толькор размер бекапа перевалил за 81 гиг - копирование "сдохло".

Я говорил не про дополнительную архивацию, а про то, что у самого SQL есть возможность сжимать файлы при создании backup (параметр "сжимать файлы при архивации" или вроде того). В этом случае сжатие происходит ещё при формировании архива.

И в догонку, SQL может и архив создавать не на локальный диск, а сразу на сетевой ресурс

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

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

"Буду искать более подходящее, поизящнее." Файл резать на куски винраром из командной строки, в многотомный архив без сжатия - работает как правило ничуть не медленней чем тот же тотал. После чего опять же из батника собирать на месте.

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

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

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

+ 1000 Обязательно попробую. Как я сам до этого не допер.. Решение на поверхности лежало.

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

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

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

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

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

:-)))) Не - до этого я еще не скатился, просто есть небольшие опасения. Закон подлости, такое впечатление, только на мне срабатывает.