Logical Logs to Disk?

I'd like to revive an old argument and see if I'm missing any sides to this issue. I know that there are those that really don't like backing up their logical logs to disk, and I know that there are those who couldn't do without it. I am one of the latter. I thought I'd throw out my arguments to see if I'm missing anything, especially on the "pro tape" side. I'm putting this into a book, and would like to have a good argument from both sides. I think I've been spoiled too long to argue for the "pro tape" group. Would any "pro tapers" want to argue with my logic below? ------------ One of the most difficult things about Informix and ontape is that it is designed to back up the logical logs to a single tape. Once that tape fills up, the logical log backups stop, and the server hangs. This means that you must constantly be watching the tape drives to which were backing up logical logs, swapping tapes throughout the day as they fill out. It's important to note that you cannot monitor how close a tape drive is to being full. You can only watch your logs to see when Informix has told you that a tape is full. It can also become unmanageable because each Informix server requires a separate tape device. Since it is not uncommon to have four or five Informix servers on a single host, you would need four or five tape drives just to do your logical log backups. The alternative is to backup the logical logs to disk. The flexibility that this affords you cannot be underestimated. You no longer have to watch several log files on multiple servers to see if any of your logical log devices are full. All of the logical log backups on a single host can share a single /logical file system. You do not have to swap tapes all day long. For each Informix server, you'll need a script that: 1. Stops logical logging for a moment 2. Moves the current logical log backup file to a date time stamped file 3. Creates another logical log backup file 4. Starts logical logging again Once this has been done, the only management required is monitoring the available space in the file systems where you're sending your logical logs. Informix support has never officially sanctioned this method. Their answer is that ontape was designed to go to tape, not to disk. However, there are hundreds of companies around the world that backup their logical logs to disk. No one has ever pointed out any technical issues with backing up to disk. It seems to be a matter of preference. Some DBAs do not feel that backing up to disk is a wise choice . They feel that the logical logs are extremely important, and backing them up to disk places them at risk. Disks can fail. If the disk drive that contains your logical logs fails at the same time as the disk drives that contains your database fails, you are out of luck. They feel it is safer to get the backups out to tape. I, however, and a strong proponent of backing up logical logs to disk. I feel that the value that is added by backing up to disk far outweighs the added risk. I would also present that backing up to tape has risks as well. By reasoning is as follows: 1. Backing up to disk allows complete automation. No one has to remember to swap tapes. No one needs to be available to swap tapes. Continuous backups just happen. It's always a good thing to automate your backups. Why would you want operators, when a simple shell script will do the job for you -- day in and day out? 2. Oracle backs up its redo logs to disk. 3. The slowest portion of an Informix database restore is the reading of the logical logs. Placing the logical logs on disk significantly increases the speed of this critical path of a restore. 4. The "all your eggs in one basket" problem is solved by using remote devices. For example, you can backup elvis' logical logs to a file system on apollo. All that is necessary to do this is to specify apollo:/logical/servername/logfile as the logical tape device. This significantly reduces the chance that both the logical tape device and the database server will be damaged at the same time. 5. The proponents of logical log backups to tape would also state that the above would not protect you from a fire that destroys both systems. Don't forget that a fire would also destroy any tapes that are in the drives! 6. Tape is safer than disk, right? The quicker you can get your logical logs to tape, the safer they are. Performing logical log backups to disk actually makes this easier. Why is that? If you are backing up your logical logs to disk, you can stop and start logical logging throughout the day, creating multiple log files. These logs log files can be immediately backup using your favorite homegrown or commercial backup system. They can even be backup or copied multiple times! This is something that is impossible with backing up to tape. As long as the tape device is open by Informix, you cannot access it. That means you have put all your eggs in one tape basket. Instead, you could easily have multiple copies of the disk backup, as well as tape copies that can be sent off-site with out disturbing Informix. I remember managing five or six Informix instances, and having to run down the hall into the server room to swap tapes because a logical log tape was full, causing our production Informix server to hang. I remember having to open up five or six windows every time we rebooted a server, just so we could start continuous backups to tape. Then I remember the day that we wrote rclogs.sh. Suddenly, we had a program that would start logical logging for us. We could reboot a server, and continuous backups would just magically turn on! We went from five or six instances to well over 50, and never had to swap a tape again. (We also never had to explain to an angry manager why his Informix database was temporarily unavailable during the busiest time of his day.) I can't imagine going back to the old way.

In article <3695AB72.93447D86@colltech.com>, curtis <curtis@colltech.com> writes >I'd like to revive an old argument and see if I'm missing any sides to >this issue. I know that there are those that really don't like backing >up their logical logs to disk, and I know that there are those who >couldn't do without it. I am one of the latter. I thought I'd throw out >my arguments to see if I'm missing anything, especially on the "pro >tape" side. I'm putting this into a book, and would like to have a good >argument from both sides. I think I've been spoiled too long to argue >for the "pro tape" group. > >Would any "pro tapers" want to argue with my logic below? > Yep. We had recently had a failure on a Sun box of the part of the motherboard which handles disks/tapes. The tape drive was not affected but the disks were (we had 2 chunks go offline and Solaris report errors on 4 other disks). Had we been logging to disk the logs would not be salvageable. Disks tend to fail more than tape drive don't they? (CAN someone confirm this? >------------ > >One of the most difficult things about Informix and ontape is that it is >designed to back up the logical logs to a single tape. Once that tape >fills up, the logical log backups stop, and the server hangs. This >means that you must constantly be watching the tape drives to which were >backing up logical logs, swapping tapes throughout the day as they fill >out. It's important to note that you cannot monitor how close a tape >drive is to being full. You can only watch your logs to see when >Informix has told you that a tape is full. It can also become >unmanageable because each Informix server requires a separate tape >device. Since it is not uncommon to have four or five Informix servers >on a single host, you would need four or five tape drives just to do ??? You should only need one server per machine. Otherwise how do you allocate CPU VPs? If all the instances in total have more CPU VPs than physical CPUs you can get thrashing. If in total CPU VPS = number of physical CPUs than each instance can only use a small portion of the number of CPUs. Also do you have >1 instance accessing the same disk. Then disks heads will start trashing since each instance optimizes access to it's own part of the disk, not considering access to the rest of the disk. >your logical log backups. > >The alternative is to backup the logical logs to disk. The flexibility >that this affords you cannot be underestimated. You no longer have to >watch several log files on multiple servers to see if any of your >logical log devices are full. All of the logical log backups on a >single host can share a single /logical file system. You do not have to >swap tapes all day long. For each Informix server, you'll need a script In this age of 20GB tape devices, if you have a large enough server to consider 4/5 instances then you should be able to afford a 20Gb tape devices and that should last a day.. >that: > >1. Stops logical logging for a moment >2. Moves the current logical log backup file to a date time stamped file > >3. Creates another logical log backup file >4. Starts logical logging again > >Once this has been done, the only management required is monitoring the >available space in the file systems where you're sending your logical >logs. > >Informix support has never officially sanctioned this method. Their >answer is that ontape was designed to go to tape, not to disk. However, >there are hundreds of companies around the world that backup their >logical logs to disk. No one has ever pointed out any technical issues >with backing up to disk. It seems to be a matter of preference. > Disk failure. >Some DBAs do not feel that backing up to disk is a wise choice . They >feel that the logical logs are extremely important, and backing them up >to disk places them at risk. Disks can fail. If the disk drive that >contains your logical logs fails at the same time as the disk drives >that contains your database fails, you are out of luck. They feel it is >safer to get the backups out to tape. >I, however, and a strong proponent of backing up logical logs to disk. >I feel that the value that is added by backing up to disk far outweighs >the added risk. I would also present that backing up to tape has risks >as well. By reasoning is as follows: > >1. Backing up to disk allows complete automation. No one has to >remember to swap tapes. No one needs to be available to swap tapes. >Continuous backups just happen. It's always a good thing to automate >your backups. Why would you want operators, when a simple shell script >will do the job for you -- day in and day out? > What happens if you run out of disk space? >2. Oracle backs up its redo logs to disk. > Oracle Urrrg! >3. The slowest portion of an Informix database restore is the reading of >the logical logs. Placing the logical logs on disk significantly >increases the speed of this critical path of a restore. > 20GB tape drive = 50Mb per 14seconds!! >4. The "all your eggs in one basket" problem is solved by using remote >devices. For example, you can backup elvis' logical logs to a file >system on apollo. All that is necessary to do this is to specify >apollo:/logical/servername/logfile as the logical tape device. This >significantly reduces the chance that both the logical tape device and >the database server will be damaged at the same time. > ?? Device MTBF does not depend upon which machine the device is plugged into.. >5. The proponents of logical log backups to tape would also state that >the above would not protect you from a fire that destroys both systems. >Don't forget that a fire would also destroy any tapes that are in the >drives! > What about power supply/motherboard/CPU failure, disks are cached right? Unless you use raw disk??? You can restore to a new machine using tape easier than move disks to the new machine... Hello, SUN support...we opened the machine and move the disks to another machine...Hello??....Hello?.. Vs We moved the tape to another machine... >6. Tape is safer than disk, right? The quicker you can get your logical >logs to tape, the safer they are. Performing logical log backups to >disk actually makes this easier. Why is that? If you are backing up >your logical logs to disk, you can stop and start logical logging >throughout the day, creating multiple log files. These logs log files >can be immediately backup using your favorite homegrown or commercial >backup system. They can even be backup or copied multiple times! This >is something that is impossible with backing up to tape. As long as the >tape device is open by Informix, you cannot access it. That means you >have put all your eggs in one tape basket. Instead, you could easily >have multiple copies of the disk backup, as well as tape copies that can >be sent off-site with out disturbing Informix. > True.. >I remember managing five or six Informix instances, and having to run >d

In article <uy0FzFA1KKm2Ew3p@smooth1.demon.co.uk>, djw@smooth1.demon.co.uk (David Williams) wrote: [cutting] > > Disks tend to fail more than tape drive don't they? (CAN someone > confirm this? > [cutting] I would say this is definitely true. The site I'm on at the moment average 1 disk failure per week but there has only been 2 tape drive failures in the last month. One per week might sound high but there are 400 servers, with over 100 one them running some sort of Raid. Paul Watson # I don't suffer from WF Software Ltd. # stress, I'm just Tel. (+44) 1436 674729 # a carrier Fax. (+44) 1436 678693 # www.wfsoftware.co.uk

There are valid reasons for having multiple instances on one machine, which makes tape backup more difficult (but not impossible). And I also have experienced more disk failures then tape failures. I side with the tape backup folks. I'd much rather explain to a manager why their database will be unavailable for a short amount of time then that they have several hours or days worth of data that cannot be recovered. One last thing...Onbar is really what you should be talking about. I know many sites are still using ontape, but one of the things that onbar (with a robust storage manager) does very well is to automate the continuous backup of logical logs to tape. I couldn't imagine life without it now. WF Software wrote in message ... >In article <uy0FzFA1KKm2Ew3p@smooth1.demon.co.uk>, djw@smooth1.demon.co.uk >(David Williams) wrote: > >[cutting] >> >> Disks tend to fail more than tape drive don't they? (CAN someone >> confirm this? >> >[cutting] > >I would say this is definitely true. The site I'm on at the moment average >1 disk failure per week but there has only been 2 tape drive failures in >the last month. One per week might sound high but there are 400 servers, >with over 100 one them running some sort of Raid. > >Paul Watson # I don't suffer from >WF Software Ltd. # stress, I'm just >Tel. (+44) 1436 674729 # a carrier >Fax. (+44) 1436 678693 # >www.wfsoftware.co.uk

David Williams wrote in message ... > Yep. > > We had recently had a failure on a Sun box of the part of the > motherboard which handles disks/tapes. The tape drive was not affected > but the disks were (we had 2 chunks go offline and Solaris report > errors on 4 other disks). Had we been logging to disk the logs would > not be salvageable. > > Disks tend to fail more than tape drive don't they? (CAN someone > confirm this? Did you have some sort of problem that was actually corrupting the disks, rather than just reporting corruptions? If the latter, then the data would still have been retrievable by connecting the pack to another server. (Not ideal, I know!) FWIW. ever since I encountered Informix I've been surprised at the seeming unquestioning acceptance of log back-ups to tape. For instance, the first edition of Joe Lubmley's excellent "Informix Database Adminstrator's Survival Guide" mentions the possibility of it being possible to have disk saving "kludged together", but clearly doesn't really believe in it and spends the next six or seven pages describing tape strategies. And clearly, the very name of the utility suggests that tape is its spiritual medium (sorry!). I've worked on systems that deploy both methods and, provided that its underpinned by water-tight scripting and highly-resilient disk, I believe that backing up logs to disk can provide an equivalent level of safety for much less maintenance and intervention. Neil Truby aracnet Limited Weybridge, UK > > >>------------ >> >>One of the most difficult things about Informix and ontape is that it is >>designed to back up the logical logs to a single tape. Once that tape >>fills up, the logical log backups stop, and the server hangs. This >>means that you must constantly be watching the tape drives to which were >>backing up logical logs, swapping tapes throughout the day as they fill >>out. It's important to note that you cannot monitor how close a tape >>drive is to being full. You can only watch your logs to see when >>Informix has told you that a tape is full. It can also become >>unmanageable because each Informix server requires a separate tape >>device. Since it is not uncommon to have four or five Informix servers >>on a single host, you would need four or five tape drives just to do > > ??? You should only need one server per machine. Otherwise how do you > allocate CPU VPs? If all the instances in total have more CPU VPs than > physical CPUs you can get thrashing. If in total CPU VPS = number of > physical CPUs than each instance can only use a small portion of the > number of CPUs. > > Also do you have >1 instance accessing the same disk. Then disks heads > will start trashing since each instance optimizes access to it's own > part of the disk, not considering access to the rest of the disk. >>your logical log backups. >> >>The alternative is to backup the logical logs to disk. The flexibility >>that this affords you cannot be underestimated. You no longer have to >>watch several log files on multiple servers to see if any of your >>logical log devices are full. All of the logical log backups on a >>single host can share a single /logical file system. You do not have to >>swap tapes all day long. For each Informix server, you'll need a script > > In this age of 20GB tape devices, if you have a large enough server to > consider 4/5 instances then you should be able to afford a 20Gb tape > devices and that should last a day.. > >>that: >> >>1. Stops logical logging for a moment >>2. Moves the current logical log backup file to a date time stamped file >> >>3. Creates another logical log backup file >>4. Starts logical logging again >> >>Once this has been done, the only management required is monitoring the >>available space in the file systems where you're sending your logical >>logs. >> >>Informix support has never officially sanctioned this method. Their >>answer is that ontape was designed to go to tape, not to disk. However, >>there are hundreds of companies around the world that backup their >>logical logs to disk. No one has ever pointed out any technical issues >>with backing up to disk. It seems to be a matter of preference. >> > > Disk failure. >>Some DBAs do not feel that backing up to disk is a wise choice . They >>feel that the logical logs are extremely important, and backing them up >>to disk places them at risk. Disks can fail. If the disk drive that >>contains your logical logs fails at the same time as the disk drives >>that contains your database fails, you are out of luck. They feel it is >>safer to get the backups out to tape. >>I, however, and a strong proponent of backing up logical logs to disk. >>I feel that the value that is added by backing up to disk far outweighs >>the added risk. I would also present that backing up to tape has risks >>as well. By reasoning is as follows: >> >>1. Backing up to disk allows complete automation. No one has to >>remember to swap tapes. No one needs to be available to swap tapes. >>Continuous backups just happen. It's always a good thing to automate >>your backups. Why would you want operators, when a simple shell script >>will do the job for you -- day in and day out? >> > What happens if you run out of disk space? > >>2. Oracle backs up its redo logs to disk. >> > Oracle Urrrg! >>3. The slowest portion of an Informix database restore is the reading of >>the logical logs. Placing the logical logs on disk significantly >>increases the speed of this critical path of a restore. >> > > 20GB tape drive = 50Mb per 14seconds!! > >>4. The "all your eggs in one basket" problem is solved by using remote >>devices. For example, you can backup elvis' logical logs to a file >>system on apollo. All that is necessary to do this is to specify >>apollo:/logical/servername/logfile as the logical tape device. This >>significantly reduces the chance that both the logical tape device and >>the database server will be damaged at the same time. >> > ?? Device MTBF does not depend upon which machine the device is > plugged into.. > >>5. The proponents of logical log backups to tape would also state that >>the above would not protect you from a fire that destroys both systems. >>Don't forget that a fire would also destroy any tapes that are in the >>drives! >> > What about power supply/motherboard/CPU failure, disks are cached > right? Unless you use raw disk??? > > You can restore to a new machine using tape easier than move disks > to the new machine... > > Hello, SUN support...we opened the machine and move the disks to > another machine...Hello??....Hello?.. > > Vs > > We moved the tape to another machine... > >>6. Tape is safer than disk, right? The quicker you can get your logical >>logs to tape, the safer they are. Performing logical log backups to >>disk actually makes this easier. Why is that? If you are backing up >>your logical logs to disk, you can stop and start logical logging >>throughout the day, creating multiple log files. These logs log files >>can be immed

In article <77c5dp$6vt$1@news-2.news.gte.net>, Steve Wenzbauer <steve.wenzbauer@gte.net> writes >There are valid reasons for having multiple instances on one machine, which >makes tape backup more difficult (but not impossible). And I also have >experienced more disk failures then tape failures. I side with the tape >backup folks. I'd much rather explain to a manager why their database will >be unavailable for a short amount of time then that they have several hours >or days worth of data that cannot be recovered. > >One last thing...Onbar is really what you should be talking about. I know >many sites are still using ontape, but one of the things that onbar (with a >robust storage manager) does very well is to automate the continuous backup >of logical logs to tape. I couldn't imagine life without it now. > >> >>[cutting] >>> >>> Disks tend to fail more than tape drive don't they? (CAN someone >>> confirm this? >>> >>[cutting] Tapes are inherently less reliable than disks, always have been in my experience (19+ years now) - especially with DAT drives as HP and IBM engineers have informed that even a tape just sitting in the drive will cause head and tape wear due to constant friction. People may think they have more disk failures over tapes but this is probably because they have lots of disks (i.e. hundreds) and only a few tape drives. I'd recommend high-availability disk arrays to solve any disk issues, and backup to disk (you can then whip the disk files off to tape and have the best of both worlds!). Modern HA arrays units have very good performance (like HP Autoraid 12H) but should a disk fail (and I have had three do that in a year) all you do is pull out the failed disk and replace with a new one). I like the HP Autoraid it really is a fit-and- forget device, and the cost was not that much more than buying standalone disks (admittedly from HP). Alternatively, if sorting out your non-HA disks is prohibitively expensive, then as the previous post mentioned, get ONBAR to handle log backups et al.... TTFN -- Simon Barber

I wouldn't call myself a "pro-taper", having written the afore-mentioned Tech Info article #6125, but I have a few comments (of course ;-) curtis wrote: > One of the most difficult things about Informix and ontape is that it is > designed to back up the logical logs to a single tape. Once that tape > fills up, the logical log backups stop, and the server hangs. This > means that you must constantly be watching the tape drives to which were > backing up logical logs, swapping tapes throughout the day as they fill > out. It's important to note that you cannot monitor how close a tape > drive is to being full. You can only watch your logs to see when > Informix has told you that a tape is full. The server doesn't hang immediately -- from the time the log backups stop, you have until all your logical logs fill *again* before the server hangs. That is, it will overwrite every one of your backed-up logs, before it hangs. There are any number of ways you can automate the "watching of the tape" by checking onstat -l or the SMI tables, to alert you when the backup has stopped. Also, although you cannot tell "how close a tape is to being full", you can calculate how many logs will fit onto a tape, assuming that you always allow a log to fill before it is backed up (not using onmode -l to progress to a new log before the old one is full). Thus you can also have a program warn you when you have filled a certain number of logs since the last time you changed the tape. You don't have to be sitting there, watching onstat -lr roll by on your monitor. > The alternative is to backup the logical logs to disk. The flexibility > that this affords you cannot be underestimated. You no longer have to > watch several log files on multiple servers to see if any of your > logical log devices are full. All of the logical log backups on a > single host can share a single /logical file system. You do not have to > swap tapes all day long. For each Informix server, you'll need a script > that: > > 1. Stops logical logging for a moment Sorry? What does that mean? Why should you have to stop logical logging? > 2. Moves the current logical log backup file to a date time stamped file > 3. Creates another logical log backup file > 4. Starts logical logging again Or do you mean "stop ontape"? Ah, yes, that makes some sense, if you were running an ontape -c to disk. Yes, or simply a script that detects when the disk file "tape is full", moves the "full" file, touches a new one, and sends a <CR> to ontape. And then, I would have another script which sent these files to tape. Multiple times. And then FTP'ed them to another machine. And then deleted them to prevent them from filling up the file system. (Yes, I am paranoid, but that doesn't mean they aren't out to get me.) > Informix support has never officially sanctioned this method. Their > answer is that ontape was designed to go to tape, not to disk. Aaaaauuuugggghhhhhhhh!!!! Someone shoot me now. > Some DBAs do not feel that backing up to disk is a wise choice . They > feel that the logical logs are extremely important, and backing them up > to disk places them at risk. Disks can fail. If the disk drive that > contains your logical logs fails at the same time as the disk drives > that contains your database fails, you are out of luck. And they are absolutely right. That's why as soon as you get it out to disk, you copy it off to something else that won't die when the machine that your instance is running on crashes. > 1. Backing up to disk allows complete automation. No one has to > remember to swap tapes. No one needs to be available to swap tapes. > Continuous backups just happen. It's always a good thing to automate > your backups. Why would you want operators, when a simple shell script > will do the job for you -- day in and day out? Yup, and then you can automate the backup to another device. > 2. Oracle backs up its redo logs to disk. Hmmm, well that is not a convincing argument to me. > 3. The slowest portion of an Informix database restore is the reading of > the logical logs. Placing the logical logs on disk significantly > increases the speed of this critical path of a restore. > > 4. The "all your eggs in one basket" problem is solved by using remote > devices. For example, you can backup elvis' logical logs to a file > system on apollo. All that is necessary to do this is to specify > apollo:/logical/servername/logfile as the logical tape device. This > significantly reduces the chance that both the logical tape device and > the database server will be damaged at the same time. > > 5. The proponents of logical log backups to tape would also state that > the above would not protect you from a fire that destroys both systems. > Don't forget that a fire would also destroy any tapes that are in the > drives! > > 6. Tape is safer than disk, right? The quicker you can get your logical > logs to tape, the safer they are. Performing logical log backups to > disk actually makes this easier. Why is that? If you are backing up > your logical logs to disk, you can stop and start logical logging > throughout the day, creating multiple log files. These logs log files > can be immediately backup using your favorite homegrown or commercial > backup system. They can even be backup or copied multiple times! This > is something that is impossible with backing up to tape. As long as the > tape device is open by Informix, you cannot access it. That means you > have put all your eggs in one tape basket. Instead, you could easily > have multiple copies of the disk backup, as well as tape copies that can > be sent off-site with out disturbing Informix. While I agree with the rest of this, it mostly applies only to ontape/tbtape, not to onarchive or onbar, as has already been pointed out. June -- june_t@hotmail.com Grounded in Palo Alto, living on KitKat bars

I have been watching this discussion with great interest as I have recently been in a discussion with my clients over the pro's and cons of disk/tape log archiving. ( I've also avoided getting involved until now - I could't help myself ! ) To me its 6 of one and half a dozen of the other ! ( sorry, english manerisms coming out ). Curtis wrote a lengthy, detailed description of his dilema, tailoring it around his prefered method of using disks for the archving. Personally, I have room for both ( what a cop out !! ) but prefer tape (decisions, decisions) using onbar rather than ontape. I have to admit that if I were stuck with just using ontape, I would write myself a series of scripts and perform disk archiving then archive the disk logs to tape of an evening. Using onbar can also archive multiple instances to the same tape device - eliminating the argument of using a single tape device per instance. I think the phrase with the words 'cat' & 'skin' immediately springs to mind here ! In any archiving strategy, the importance has got to be on the security of the data - not necessarily the speed in which it can be recovered. ( The ideal would obviously be to get the best of both ). If you follow the argument through that Curtis was putting forward, why do you not archive the full database to disk as well ?? Why use tape at all ?? Yes, the logical logs are important but they aren't worth diddley if the database can't be recovered ?? Simply, whatever your chosen method of archiving, you MUST ensure that you can recover the database given all failure circumstances. If you can do this, then regardless of what method you choose, you've succeeded !! Personally, I prefer tape ( cleaning on a regular basis !! ) Sean

I started the discussion to learn something, and I have learned a FEW things. June Tong wrote: > The server doesn't hang immediately -- from the time the log backups stop, > you have until all your logical logs fill *again* before the server hangs. > That is, it will overwrite every one of your backed-up logs, before it > hangs. There are any number of ways you can automate the "watching of the > tape" by checking onstat -l or the SMI tables, to alert you when the backup > has stopped. Also, although you cannot tell "how close a tape is to being > full", you can calculate how many logs will fit onto a tape, assuming that > you always allow a log to fill before it is backed up (not using onmode -l > to progress to a new log before the old one is full). Thus you can also > have a program warn you when you have filled a certain number of logs since > the last time you changed the tape. You don't have to be sitting there, > watching onstat -lr roll by on your monitor. That's a VERY good point. Perhaps you should have a script that does this no matter WHAT your log backup method is. Do you know of such a script? > Or do you mean "stop ontape"? Ah, yes, that makes some sense, if you were > running an ontape -c to disk. Yes, or simply a script that detects when the > disk file "tape is full", moves the "full" file, touches a new one, and > sends a <CR> to ontape. Yes, I meant stop ontape. Bad choice of words. What you say is entirely possible, but difficult to do without using something like "expect." I've written a script to automate all this, and tried to do so without using expect or any compiled tools. (A simple here document can't be told to pass another <CR> to ontape, so the simplest thing to do is to stop the session, move the file, and restart the session.) > And then, I would have another script which sent these files to tape. > Multiple times. And then FTP'ed them to another machine. And then deleted > them to prevent them from filling up the file system. (Yes, I am paranoid, > but that doesn't mean they aren't out to get me.) I'm with you THERE! > > Informix support has never officially sanctioned this method. Their > > answer is that ontape was designed to go to tape, not to disk. > > Aaaaauuuugggghhhhhhhh!!!! Someone shoot me now. Turns out I was completely wrong. I remember Informix support giving me this answer, but I guess they've change it now. I'm so glad to hear that answer's changed. It's similar to the "we dont' support backing up logical logs to compression tape drives." > > 2. Oracle backs up its redo logs to disk. > > Hmmm, well that is not a convincing argument to me. Yeah, I know, it was a dumb one. I thought I'd just throw it in in case anyone's interested. > While I agree with the rest of this, it mostly applies only to > ontape/tbtape, not to onarchive or onbar, as has already been pointed out. Yes, this entire discussion is mainly about ontape. I would consider myself an ontape advocate for those that can use it. It's old and proven. Its limitations are known. Informix is dropping onarchive. The only reason it's still in the product is that it met a niche that nothing else did. With ISM and onbar, that niche is now gone. As for onbar, some folks are still uneasy about relinquishing control to a 3rd party storage manager -- especially DBAs. Both of these mean that ontape still serves a very valid function for a good portion of the Informix community. If you need multi-threaded backup and restore, you've got to check out onbar. (I just hope that the next version of Informix documentation presents onarchive as a utility that is only there to read old backups. If you have to move off of ontape, you need to move to onbar, NOT onarchive.) Thanx for your comments!