стоить бекапирование  Full раз в сутки утром  и  Diff   каждый  час.  так вот если  у Diff не ставить признак дописывать хвост  то он создаёт каждый час новый файлик  больше предыдущего. т.е.  каждый следующий несёт в себе предыдущую инфу. но место на диске жрёт катастрофически. но работает правильно после FULL бекапа  первый Diff малеьнкий  и больше больше  до следующих суток. Сейчас  поставил   признак писать в хвост. всё хорошо файлик один  но!  он не чистится  после  Full бекапа :-(

http://clip2net.com/s/69cVy2

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

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

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

(1) а ты шринк логу не делаешь после бэкапа?

+(4) к (0) есс-но

оно?

http://clip2net.com/s/6chpg2

нет

+(7) это вроде журнал самого плана обслуживания.

должно быть что-то типа
выполнение инструкции T-SQL

а там что-то типа

USE [Buh_alta]
GO
DBCC SHRINKFILE (N'Buh_alta_log' , 0, TRUNCATEONLY) with NO_INFOMSGS
GO

т.е. штатной  задачи  кактаковой нет.  понял  вставлю из FAQ а  спасибо.

+(8) в планах обслуживания нет специальной задачи по шринку базы в целом или журнала транзакций, поэтому выполняешь инструкцию.

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

У меня так:
три задания.
1. Фулл. раз в сутки в 01:00
2. Лог в 01:30. Перезаписать.
3. Лог с 02:00 до 23:00 каждые полчаса , дозаписать.

+ всё это каждый раз пакуется и уезжает в другую точку геграфии.

(11) не совсем верно.
Можно не дать ему стремительно расти, сделав задание, на автобэкам, при наполнении журнала (размера файла), скажем на 70%, тогда файл не будет разрастаться, бэкапы будут чаще...

(12) начиная с версии 2008 sql сам отлично пожимает свои архивы, при этом сам процесс архивации проходит быстрее.

(14) однако у нас еще 2003-й.... Про 2008 слышал, сейчас начинаем разворачивать 2012 (в связи с лицензионными нюансами конторы)
вот и заюзаем ... :)

+(15) sql 2005 конечно же... на 2003 винде...