Re: [Bacula-users] appending position
Am Donnerstag, 2. März 2006 23:11 schrieb Arno Lehmann: Hello, Thank you Arno. On 3/2/2006 2:03 PM, Thomas Franz wrote: Hello, I am very new to bacula. My question : Is it possible (e.g. with bconsole) to seek the append position of a tape after rewinding the tape because of a restore etc. No. The only way to position to EOD is by starting a job which uses the volume. In the case of a backup run it takes a long time ( up to hours ) until the storage daemon is finding the end-of-data position . ( Of course only if the tape is nearly full). Well, any other repositioning command Bacula could implement would probably use the same methods, so would be exactly as fast or slow as what you observe. ^^ Of course , but not at that time the backup should start. It would be a nice feature to do this before. We are using bacula 1.36.3 on a FreeBSD 4.11 machine. The backup hardware is an EXABYTE Changer with an IBM LTO-3 drive. It seems to work well after testing with btape and using the following parameters: ... Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no This setting might influence the positioning time a lot. Have you tried running btape with this set to on? ^^ Yes, but no success. Thomas TWO EOF = yes Thanks. The problem is that Bacula - or any other serious and hardware-independent tape solution can't rely on the relatively fast command to move to the EOD because it's not always possible to determine the correct tape position then. The tape position (in terms of file mark number) is needed to make sure the tape is correctly represented in the catalog. Arno Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] appending position
Hi, On 3/3/2006 9:32 AM, Thomas Franz wrote: Am Donnerstag, 2. März 2006 23:11 schrieb Arno Lehmann: On 3/2/2006 2:03 PM, Thomas Franz wrote: Hello, I am very new to bacula. My question : Is it possible (e.g. with bconsole) to seek the append position of a tape after rewinding the tape because of a restore etc. No. The only way to position to EOD is by starting a job which uses the volume. In the case of a backup run it takes a long time ( up to hours ) until the storage daemon is finding the end-of-data position . ( Of course only if the tape is nearly full). Well, any other repositioning command Bacula could implement would probably use the same methods, so would be exactly as fast or slow as what you observe. ^^ Of course , but not at that time the backup should start. It would be a nice feature to do this before. I see two possible solutions, or rather one solution consisting of two parts. First, start a small job - perhaps a dummy one which will never find any data - some time before your real backup jobs run. Then, make sure the device stays opened and is not rewound in-between, which should already be achived by the default strage device settings. I suppose you'd have to use the non-rewinding device file and set AlwaysOpen to Yes if it doesn't work. Concerning the FreeBSD settings, you might find re-reading the manual chapter Tape Modes on FreeBSD or perhaps asking again with FreeBSD in the subject line as that might alert some FreeBSD users with better knowledge of these things. We are using bacula 1.36.3 on a FreeBSD 4.11 machine. The backup hardware is an EXABYTE Changer with an IBM LTO-3 drive. It seems to work well after testing with btape and using the following parameters: ... Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no This setting might influence the positioning time a lot. Have you tried running btape with this set to on? ^^ Yes, but no success. Does btape report a different behaviour between runs with it set to of and to on? Also, you might try using mt to position a tape to EOD and to try the FSF commands to see if is as slow as Bacula - after all, it is possible that your tape drive or driver behaves differently than what Bacula expects. Arno -- IT-Service Lehmann[EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] appending position
On Thursday 02 March 2006 23:11, Arno Lehmann wrote: Hello, On 3/2/2006 2:03 PM, Thomas Franz wrote: Hello, I am very new to bacula. My question : Is it possible (e.g. with bconsole) to seek the append position of a tape after rewinding the tape because of a restore etc. No. The only way to position to EOD is by starting a job which uses the volume. In the case of a backup run it takes a long time ( up to hours ) until the storage daemon is finding the end-of-data position . ( Of course only if the tape is nearly full). Well, any other repositioning command Bacula could implement would probably use the same methods, so would be exactly as fast or slow as what you observe. We are using bacula 1.36.3 on a FreeBSD 4.11 machine. The backup hardware is an EXABYTE Changer with an IBM LTO-3 drive. It seems to work well after testing with btape and using the following parameters: ... Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no This setting might influence the positioning time a lot. Have you tried running btape with this set to on? TWO EOF = yes Thanks. The problem is that Bacula - or any other serious and hardware-independent tape solution can't rely on the relatively fast command to move to the EOD because it's not always possible to determine the correct tape position then. The tape position (in terms of file mark number) is needed to make sure the tape is correctly represented in the catalog. Actually, Linux and Solaris have a relatively fast EOD that will keep track of the correct tape position. It is much faster than what Bacula can do because it is implemented at a driver level. Unfortunately FreeBSD has no such function, so Bacula must go to the EOD doing all the work itself. I've tried to get the FreeBSD, but so far no luck. Perhaps a little user pressure would be effective. I must say that I have found the FreeBSD scsi guys very open and nice -- it is just a question of priorities ... Arno Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] appending position
Hello, I am very new to bacula. My question : Is it possible (e.g. with bconsole) to seek the append position of a tape after rewinding the tape because of a restore etc. In the case of a backup run it takes a long time ( up to hours ) until the storage daemon is finding the end-of-data position . ( Of course only if the tape is nearly full). We are using bacula 1.36.3 on a FreeBSD 4.11 machine. The backup hardware is an EXABYTE Changer with an IBM LTO-3 drive. It seems to work well after testing with btape and using the following parameters: ... Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no TWO EOF = yes Thanks. Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] appending position
Hello, On 3/2/2006 2:03 PM, Thomas Franz wrote: Hello, I am very new to bacula. My question : Is it possible (e.g. with bconsole) to seek the append position of a tape after rewinding the tape because of a restore etc. No. The only way to position to EOD is by starting a job which uses the volume. In the case of a backup run it takes a long time ( up to hours ) until the storage daemon is finding the end-of-data position . ( Of course only if the tape is nearly full). Well, any other repositioning command Bacula could implement would probably use the same methods, so would be exactly as fast or slow as what you observe. We are using bacula 1.36.3 on a FreeBSD 4.11 machine. The backup hardware is an EXABYTE Changer with an IBM LTO-3 drive. It seems to work well after testing with btape and using the following parameters: ... Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no This setting might influence the positioning time a lot. Have you tried running btape with this set to on? TWO EOF = yes Thanks. The problem is that Bacula - or any other serious and hardware-independent tape solution can't rely on the relatively fast command to move to the EOD because it's not always possible to determine the correct tape position then. The tape position (in terms of file mark number) is needed to make sure the tape is correctly represented in the catalog. Arno Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- IT-Service Lehmann[EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] appending position
On Thu, Mar 02, 2006 at 02:03:59PM +0100, Thomas Franz wrote: In the case of a backup run it takes a long time ( up to hours ) until the storage daemon is finding the end-of-data position . ( Of course only if the tape is nearly full). We are using bacula 1.36.3 on a FreeBSD 4.11 machine. The backup hardware is an EXABYTE Changer with an IBM LTO-3 drive. It doesn't seem right that you should be seeing those types of positioning delays. I'm also using an LTO-3 drive, and have never seen the drive spend more than a few minutes positioning the tape. I suspect that the problem is with the use of the Fast Forward Space File = no directive. With the type of delays that you're reporting, I can easily believe that the drive is positioning to the end of data by reading all the data written up to that point. What happens if you use fast forward space file = yes? It seems to work well after testing with btape and using the following parameters: ... Hardware End of Medium = no BSF at EOM = yes Backward Space Record = no Fast Forward Space File = no TWO EOF = yes Thanks. Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
