На локальный диск резервное копирование проходит нормально. На сетевой диск \\share\doc не получается. Выходит ошибка,хотя под этой учеткой по сети заходил на указанный сетевой ресурс и создавал там папки и документы. Т.е. все права, включая запись есть.
Журнал ошибок: не удалось выполнить create. Ошибка операционной системы 5 (отказано в доступе).

уже второй раз при создании темы указываю IT, а попадаю со своей темой сюда

(1) перенёс

(2) спасибо

(0) пользователь под которым запускается скуль (в службах) должен иметь права на папку.

(4) можно чуть подробнее. как это в службах?

не даёт копировать с итса...

http://pics.rsh.ru/img/its_1ckgges0.jpg

(7) служба MSSQL запускается под какой-то учеткой.

(9) + эта учетка должна иметь права на папку

(7) я тебя понял. Все права на папку есть. Писал об этом в первом своем сообщении.

Свойства задания - Общие - Владелец
У этого товарища должны быть права на папку

права на папку есть

права на папку есть, а на сетевой доступ есть?

есть

неужели никто все делают копии бд на локальные диски сервера?

(16) Я для кого картинку кинул?

(16) Если права есть - делается без проблем. Может быть проблема в запросе?

(16) Вообще начинать надо не с этого. По порядку:
1. Домен есть?
2. Служба MS SQL Server запущена от имени доменной учетки, или от имени NT Authority/System?
3. У доменной учетки есть права на запись в шару?(если запущено от системной ученой записи - работать это не будет никогда).
Вариант, если ответ на 1 - "нет" - а у локальной учетной записи пользователя есть права на запись в удаленную папку?

Добавь на папку полные права для компа на котором скуль.

DomenName\CopmName$ как то так вроде будет выглядеть юзер.

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

(21) А CompName здесь причем? вообще-то бдует Domain\UserName, и кстати без $.
(22) Сколько ж у вас дисков в севере БД, если есть свободное зеркало для бэкапов? Да еще и свободные ресурсы самого сервера... Исключительно в сеть, или на стример.

(23) Дисков должно быть столько, чтоб хватало места для хранения текущего бекапа локально. Это снижает время бекапирования и увеличивает скорость его оперативного восстановления в случае необходимости.

(24) При нормальной гигабитной сети время резервного копирования на сетевой диск и на локальный же не различается. У меня база в 170 гигабайт ложится на локальный диск за 12 минут, на сетевой - за 13-14. Массив для БД - 6 дисков в RAID10, массив для лога - 4 диска в RAID10, массив для tempdb - 4 диска в RAID0. Все диски SAS 15k. пробовал ставить еще 2 SATA 10к в зеркало для бэкапов - значимой разницы с копированием в сеть не увидел.

(23) Имя компа, это если скуль под local system запущен.

(0)эффектор сэйвер что не позволяет использовать?

(0)права на запись в  папку сделай для учетной записи под котороый работает сервис.

Только не надо говорить что они есть, ибо в (0)четко сказано что их нет.

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

(27)Нафига левые приблуды, когда есть встроенные?

(23)>колько ж у вас дисков в севере БД, если есть свободное зеркало для бэкапов?
Не знаю как у других, а у меня всегда есть диск (не зеркало) для локальных бэкапов.

>Да еще и свободные ресурсы самого сервера.
С чего ты решил, что при копировании в сеть тратится меньше ресурсов?

ИМХО нормальный бэкап делается так - создается бэкап на диск в этом же сервере, после создания отрабатывает скрипт, который переносит его куда надо.
В итоге на сервере всегда есть под рукой два, три свежих бэкапа, а на удаленном сервере в сети хранится архив за приличный период.

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

(30) блин, вперед меня успел :)

(29) использую его 4 года и не заморачиваюсь

Сеть отвалится - останетесь без бекапа. Делайте локально и потом шедулером виндовса копируйте в сеть.

О, мнение членов консилиума совпадает.

(30),(34) Хватит уже оффтопить.
(35) мысль вслух "миллион мух не может ошибаться..." Сеть не падала ни разу, а диски меняю регулярно. Бэкап на отдельный незеркальный диск - опрометчиво, по меньшей мере.

(30) И тогда в случае выхода сервера из строя вы останетесь и без БД, и без свежего бэкапа...

(30),(34)+100

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

(39) Все правильно.

(39) Элементарно, дорогой Ватсон. Бэкап делается ночью. Локально. А к утру блок питания сервера с тихим шипением отбывает в лучший мир. Итог - бэкап есть, но, как говорится, видит око, да зуб неимёт". А что будет, если в процессе создания бэкапа диск ведет себя нормально, а при попытке прочитать только что записанное - CRC Error? Кстати, MS SQL Server не проверяет бэкапы на корректность после создания :) Это к тому, что бэкап кладется на незеркальный диск...
Но что-то я уже и сам ударился в оффтоп, где наш ТС, спит еще?

(30) + 1000
сеть может упасть в самый неподходящий момент, а ты об этом можешь даже и не узнать

(41) А ничего, что сливается оно у меня тоже ночью? Сразу по готовности файла. И что будет утром меня уже не так беспокоит (ибо у меня уже к тому времени ТРИ файла в РАЗНЫХ местах). А вот если ночью диверсионная мышка перегрызет шнурок сети (а такое бывает) и файла не будет, то кому-то пригодится ведро вазелина.
PS и эта. У меня первичный бэкап как раз зеркалится на рабочем сервере, так, что мистер Холмс, тут Вы не правы в корне.

(41) "MS SQL Server не проверяет бэкапы на корректность после создания"

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

(39,43): +100500.

(41): http://saveimg.ru/pictures/01-08-13/0cd5b3ea48dd721bd39f7d2336cfc6ec.jpg

(41)а это "cheksum" не то?

(45) Я этому верил до первого посыпавшегося диска...

(47)Поясню - когда делаешь бэкап локально, успешность создания бэкапа зависит от исправности диска на который бэкап пишется.
А когда бэкап делается сразу по сети, успешность создания зависит как от исправности диска на который бэкап пишется, так и от исправности сети.
Т.е во втором случае больше точек отказа.

воблин я тут развел... :) Давайте уже закрывать этот холивар и помогать ТСу... Хотя ему-то как раз уже чем могли помогли...

(47) А сейчас бэкап не на дисках лежит, а в шнурке сети прячется? Сеть - только транспорт для передачи файла. Если хочешь надежности, то сливай по локалу на зеркало, а потом еще на пару РАЗНЫХ машин\устройств. Получишь на выходе четыре файла, которые одновременно могут пострадать наверное только в случае бомбежки, и то не факт.

Падение сети редкое и краткосрочное явление.

(51) Падение метеорита на город тоже, но легче от осознания этого не станет.

(51)А не надо чтобы сеть падала полностью и надолго.
Достаточно перегрузки сети, чтобы бэкап создавался очень долго.
Или кратковременного падения чтобы он перестал создаваться вообще.

OFF:Backup SQL2000 Ent на сетевой диск

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

(55) Точно так. Только в моем случае наркоманы очень врядли, но пожар (или еще какое чп) никто не отменял.

(55),(56)ребята а от извержения супервулкана как страхуетесь?

(57) Две дополнительные копии хранится в другом населенном пункте (вполне серьезно, у меня дома и у админа) :)

(58)это не поможет даже от извержения обычного вулкана, конечно если он рядом ... а от супервулкана и подавно

(59) Если жахнет так, что в радиусе 200 км ничего не останется, то архивы уже не нужны будут :)

аха

(200)говорят, что у касперского серверная защинена даже от прямого попадания ядерным оружием

(62) у касперского есть серверная? ахренеть..

(62) чтобы никто не мог узнать, что сперва они выпускают вирус, потом страшную статью о нем, а потом лекарство. Иногда первые два пункта даже путают местами.. )))

(0) не выпендривайся, делай как опытные люди советуют. Локальный бекап без зеркала и шедулером копия в хранилище. Я еще и на стример пишу из хранилища для надежности.

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

+ да, вторая копия должна быть в другой локации

(0) По сети.. Бэкап..? Объем базы, видать, позволяет по сети бэкапиться. Везде, где видел бэкапы - всегда идет локальный бэкап, потом шедулером архивирование плюс копирование..