On Mon, 1 May 2006 11:48:55 +1000 "James Harper" <[EMAIL PROTECTED]> wrote:
> > > Not sure where you're coming from here so my answer may not match > the > > > intent of your question. > > > > I guess my point was simply that backing up transaction logs is an > > important part of MSSQL, and generally involves dumping them to ASCII > (?) > > files as well, then doing a second step to get them off to archival > > media. > > I would always use MSSQL backups (eg 'BACKUP LOG xyzzy TO > backupdevice'), which stores things in a binary file. I'm not sure that > there is a way to get an ASCII (I assume you mean plain text) > representation of the transaction logs, or why you would want to. ASCII ... binary ... whatever. I _thought_ those files were ASCII, but it's not terribly important. What _is_ important is that the files represent a consistent view of the data in the database that can be backed up by normal file backup tools. > > And I guess my point to that was if you want to make a plugin to > backup > > MSSQL, it's got to get the transaction logs as well. > > I've been toying with this, and I'm almost to the point where the > director can query my agent and ask for an estimate of data to be backed > up. > > The way this works is that when you issue the SQL command "BACKUP LOG > xyzzy TO PIPE = '\\.\pipe\bacula6789'", MSSQL creates the named pipe and > waits for the agent to connect to it. Once connected, MSSQL just pumps > the data down until finished. This works for "BACKUP DATABASE" and > "BACKUP LOG" commands in just the same way, so there is little need to > differentiate. Cool. I have a client I'm liable to migrate to Bacula some time this year. I may come looking for your work when that happens. > > > I always do full backups where possible, but in the case of an > > > incremental backup, you would do the full database backup at the > start > > > of the backup cycle (eg Monday), and then only the transaction logs > for > > > the remainder of the backup cycle. My mistrust of tapes (bordering > on > > > superstitious :) leads me to believe that a full nightly backup is > the > > > only way to go, otherwise you are pinning the ability to do a useful > > > restore on more than one tape. > > > > Agreed. I have a few clients where the amount of data they have to > back > > up is small enough that (IMHO) it's practical to do a full backup > every > > time. In such a case, I figure it's smarter than dealing with > > incrementals, where things can sometimes go wrong. > > The MSSQL databases of our clients wouldn't be larger than 10-20gb, > Exchange databases would be under 30gb, and total ordinary files would > be no larger than 200-300gb (often much less), so a 200/400gb LTO drive > is plenty big enough for most and still cheap enough to be used in > preference to incremental backups. Our recommendation (and most clients > follow it) is to have a set of 4 tapes for Monday to Thursday backups, 5 > tapes for Friday backups, and to take a tape out of the set and archive > it at significant dates (per quarter, each financial year, etc depending > on the client and their records keeping needs). This is using Seagate > Backup Exec though, > > Do you have a rule of thumb for the point at which you would say "this > is too much data, lets do it incrementally"? Nothing hard and fast. It's always been a matter of gauging the time and the space. I guess my rule is if the backup can be done in the time alloted, and fill a single tape, then it's worth doing a full every time. Time alloted changes for each client, most folks you can run the backup all night, but some people have second shift or other scheduled maintenance that I try to work around, thus reducing the time allotment. Another thing I take into account is that some folks don't have a full-time sysadmin. If a scheduled backup(s) fail for any reason, they may not notice it for some time, and the incrementals might become useless. That's another argument in favor of nightly full backups. -- Bill Moran Collaborative Fusion Inc. ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
