> From: "James Harper" <james.harper AT bendigoit.com DOT au>

>> > On 14. apr. 2011, at 13.57, James Harper wrote:
>> >
>>> > > It's not. MSSQL is "MicroSoft SQL", so guess which platforms it runs on
>>> > > :)
>>> > >
>>> > > I'm not sure if a Windows equivalent of 'touch' could work while the
>>> > > database files are open, and even if it did, I'd be reluctant to tinker
>>> > > with it.
>> >
>> > I have a large, dedicated MS SQL server with a couple dozen databases 
>> > ranging
>> > from a few MBs to several GBs. I dump them with ClientRunBeforeJob scripts 
>> > and
>> > back up the dumps. It's really no different than dumping mysql dbs on the 
>> > fly.
>> > I also have management tasks running which dumps transaction logs at 
>> > regular
>> > intervals throughout the day and back them up at night.
>> >
>> > Check out the SQLCMD.EXE program installed with SQL Server. If you want I
>> > could post some example scripts?
>> >
>> > Or did I misunderstand something?
>> >
> I don't have space on this particular server to dump out 40GB of database 
> (the database itself is about 80MB but there are lots of FILESTREAM images 
> that would be included in the backup stream).
>
> I have found that all I need to do is run a 'CHECKPOINT' to ensure all data 
> is written out to the database. Can you post an example Job with a 
> ClientRunBeforeJob? I just get errors every time I try to do it.
>
> Thanks
>
> James

If you run the SQL Server services under a domain account you should be 
able to script a backup to a windows share and then back that up elsewhere.

That being said... if you're running a db server that close to the limit 
(less than 40gb free, really?) you're asking for trouble, or at least 
making a lot more work for yourself.  Or did you really mean that you don't 
have the time/performance to dump a file that big?

You can probably just backup the db occasionally but backup the logs 
frequently.  My system has < 100GB of databases, but I have 800GB of 
database backup files on a separate drive inside the same server.  With 
SATA drives being so cheap it makes sense to keep your SQL Server backup 
files on the server for as long as possible because restores from a tape 
are a lot more work.

If you're running >= SQL 2005 you can set up a database maintenance plan 
that a) backs up all "user" databases automatically so you won't forget to 
add the backup script when you add a database and b) expires the backup 
files automatically for you based on whatever number of days you want.
I generally have 3 DB maintenance plans.  1 to do the system backups with a 
short retention period, 1 to do full backup of the user dbs, and 1 to do 
transaction log backups of the user dbs.  The backup files can even be 
compressed in SQL 2008.

Bacula backs up those db backup files quite well.  If you try to do your 
backups of closed systems like Microsoft products in ways specifically 
warned against don't expect it to go very well.  Even if it works today it 
might break tomorrow after a SQL Server or Windows update is installed, and 
you probably won't know it's not working until you have to do a restore 
from the backup that didn't get your data like you thought it did.

     Bob




------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users