Does anyone know how to label uninitialized LTO-7 (6 GB native) tapes under
Linux as LTO-M8 (9 GB native) for use in an LTO-8 drive?
Many thanks,
Andreas Koch
signature.asc
Description: OpenPGP digital signature
collecting
the data!
Best,
Andreas Koch
signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
ntial backup actually worked, I do not know yet
(see other thread titled `More Bacula 7.4.4 differential Backup
strangeness'), that will take more investigation.
Best,
Andreas
On 10/14/2016 01:50 PM, Andreas Koch wrote:
> Hello all,
>
> we have observed strange behavior in our rece
rdmounted the file systems (which does not hurt us on that specific
server) and will see how the next Differential on Sunday morning fares.
Best,
Andreas
>
> -Jonathan Hankins
>
> On Fri, Oct 14, 2016 at 7:34 AM Andreas Koch
> <mailto:k...@esa.informatik.tu-darmstad
Hi again,
I looked at some of the files in our mystery differential backup (see last
post) again. I am pretty sure that some of the backed-up files are really old
and have not been modified since the last full backup (last Thursday,
2016-10-06).
Here is one of these ancient files on disk:
[root
Hello all,
we have observed strange behavior in our recent backups. We have a number of
filesystems, and explicitly list those to be backed up in the fileset
One of these file systems is
/home/stud
which has subdirectories for each user. Backing these up has worked perfectly
for the las
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hallo all,
many thanks for the extremely interesting discussions!
I think that for our use case, the ``SD Calls Client'' directive would
probably work best. Many thanks to the Bacula devs for adding it!
As for Josh's comment on potential security we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
while we have been extremely happy over the years using Bacula to handle our
internal systems, we are a bit stumped now on how to backup a machine
outside of a rather restrictive firewall.
Said firewall is basically configured to deny all
Hello all,
is there a way to change this back to a saner scheme (exponential back-off,
maybe)? When I am out of the office (or asleep) flooding my mailbox every five
minutes won't help Bacula in getting its desired tape any sooner ...
Best,
Andreas
signature.asc
Description: OpenPGP digital
volumes?
Many thanks,
Andreas Koch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlL04P8ACgkQk5ta2EV7DowEBACfZ13GKpz9txS5JxCokM0sosdg
nSQAoI/RWyIAEU8cbt6QoLTq6UepQeYT
=KAWZ
-END PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/20/2013 03:43 PM, Alan Brown wrote:
> On 20/09/13 13:22, Andreas Koch wrote:
>>
>> Many thanks for the data point! When we use Bacula (not just btape)
>> with larger block sizes (512 KB), our backups abort when bacula
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/20/2013 10:21 AM, Thomas wrote:
> Hi Andreas,
>
> we are using also LTO-5 with 2M Blocksize and without any Problems.
>
> Drives and Kernel are:
>
> Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux Medium
> ChangerOVERLAN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2013 01:01 PM, Alan Brown wrote:
>
> Weighing in late on this thread
Welcome!
> We are using 2Mb blocks with no problems.
We have been using 512KB without problems on our older IBM LTO-4 drives (in
a Tandberg StorageLoader). It's just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Does the splitting problem occur if you write to the tape with dd and
> then read it back?
>
> e.g. something like
>
> dd if=/dev/urandom of=/tmp/largefile bs=512k count=1 mt -f /dev/nst0
> rewind dd if=/tmp/largefile of=/dev/nst0 bs=512k dd if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/2013 06:42 PM, Kern Sibbald wrote:
> What version of Bacula (btape) are you using?
Version: 5.2.12 (12 September 2012)
Best regards,
Andreas
PS: Will run Martin's requested tape tests tomorrow.
-BEGIN PGP SIGNATURE-
Version: GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> btape: btape.c:1157 Wrote 1 blocks of 524188 bytes. btape:
> btape.c:609 Wrote 1 EOF to "LTO-4" (/dev/nst0) btape: btape.c:1173 Wrote
> 1 blocks of 524188 bytes. btape: btape.c:609 Wrote 1 EOF to "LTO-4"
> (/dev/nst0) btape: btape.c:1215 Rewi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Kern,
the problem is not so much the risk of errors, but that btape (and
correspondingly, Bacula) fails even the simplest of readback tests with
block sizes above 128KB. dd works perfectly well with multi-megabyte blocks,
both reading and writin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/11/2013 04:47 PM, Brian Debelius wrote:
> Hi,
>
> If so what OS, Kernel, SCSI adapter, and LTO drive are you using?
Scientific Linux 6.4
Kernel 2.6.32-358.14.1.el6.x86_64
SAS Adapter IBM 6GB SAS HBA 90Y4579 (using the LSI mpt2 driver 16.00.01.0
dumps), so I really would like to move back up to larger block sizes.
Many thanks in advance,
Andreas Koch
gundabad ~ # btape -c /etc/bacula/bacula-sd.conf /dev/nst0
Tape block granularity is 1024 bytes.
btape: butil.c:290 Using device: "/dev/nst0" for writing.
btape: btape.c:477 open
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
after an involuntary drive upgrade (old one died) from LTO-4 to LTO-5, I
wonder what the best way is to softly migrate our backup media to LTO-5.
I don't want to ditch all of our existing LTO-4 media and keep it in the
backup rotation, but I
On 12/08/2011 09:23 PM, Martin Simmons wrote:
>>>>>> On Thu, 08 Dec 2011 13:29:29 +0100, Andreas Koch said:
>>
>> Hi all,
>>
>> I noticed lines such as
>>
>>...
>>FD Files Written: 965
>>SD Files Written: 9
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I noticed lines such as
...
FD Files Written: 965
SD Files Written: 965
FD Bytes Written: 1,251,958,893 (1.251 GB)
SD Bytes Written: 1,252,111,781 (1.252 GB)
Rate: 1638.7 KB/s
- ->Software
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Running the FD with debug level 400 might help to see if it generates the SHA1
> at all.
Here's the data for the broken file:
gundabad-fd: find_one.c:357-32 File :
/usr/share/postgresql-8.4/man/man7/table.7.bz2
gundabad-fd: backup.c:326-32 FT_L
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/05/2010 09:19 PM, Martin Simmons wrote:
>>>>>> On Mon, 05 Jul 2010 17:54:29 +0200, Andreas Koch said:
>>
>> I used the wrong JobID, those were indeed the rows for the differential
>> backup. The data for the u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/05/2010 03:50 PM, Martin Simmons wrote:
>>>>>> On Mon, 05 Jul 2010 13:10:17 +0200, Andreas Koch said:
> Are those definitely the rows for the Full backup? I'm a little surprised to
> see I_AM_FAKE_AHK_3.
I use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/05/2010 03:50 PM, Martin Simmons wrote:
>>>>>> On Mon, 05 Jul 2010 13:10:17 +0200, Andreas Koch said:
>>
>> On 07/02/2010 04:52 PM, Martin Simmons wrote:
>>> It would be interesting to check the MD5 col
On 07/02/2010 04:52 PM, Martin Simmons wrote:
> It would be interesting to check the MD5 column in the output of the SQL query
>
> SELECT Path.Path,Filename.Name,File.MD5 FROM File,Filename,Path WHERE
> File.JobId=
> AND Filename.FilenameId=File.FilenameId
> AND Path.PathId=File.PathId ORD
On 07/01/2010 02:37 PM, Martin Simmons wrote:
> Does the FileSet have just one Include section and one Options section? If
> it is more complicated than that, please post it.
The complete FileSet is:
# List of files to be backed up
FileSet {
Name = "FullSet"
Include {
Options {
30/2010 12:55 PM, Martin Simmons wrote:
>>>>>>>> On Tue, 29 Jun 2010 18:06:41 +0200, Andreas Koch said:
>>>>
>>>> Can no one help with this? I'm somewhat worried that the many lines of
>>>>
>>>> Warning: Can't ve
On 06/30/2010 12:55 PM, Martin Simmons wrote:
>>>>>> On Tue, 29 Jun 2010 18:06:41 +0200, Andreas Koch said:
>>
>> Can no one help with this? I'm somewhat worried that the many lines of
>>
>> Warning: Can't verify checksum for (filename...)
Can no one help with this? I'm somewhat worried that the many lines of
Warning: Can't verify checksum for (filename...)
during backup indicate a configuration problem and I fear for the consistency
of our data.
Any hints would be appreciated,
Andreas Koch
On 06/21/201
r any hints.
For reference, I am using Accurate = yes with
FileSet {
Name = "FullSet"
Include {
Options {
signature = SHA1;
verify=pins1;
accurate=pins1;
}
...
Many thanks,
Any help appreciated,
Andreas Koch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG9548k5ta2EV7DowRAtFZAJ4zTiaaCcUt7RnzX5gXD6gqBOVpkQCdE6tP
U24K8Q0vrXmeNDolbempgnc=
=GBYo
-END PGP SIGN
these details out by now :-)
Andreas
- --
Prof. Dr. Andreas Koch[EMAIL PROTECTED]
Technische Universität Darmstadt, FB20Phone : x49-6151-16-4378
Embedded Systems and Applications Group (ESA) FAX: x49-6151-16-5472
Hochschulstr. 10, D-64289 Darmstadt, Germany
re.
Andreas
>
> on 07/03/07 11:55 Andreas Koch wrote:
>> Hi all,
>>
>> we've been relying on Bacula for quite a while now and are very
>> satisfied users. However, I just noticed a strangeness with regard to
>> Job Retention on 1.38.9:
>>
>> It
r Full backups in
the meantime (which were definitely written to the tapes)?
At a glance, it appears that the Job Retention time appeared to ``take''
only for the Differentials, and that the Full backups use the default of
180 days.
Any ideas on what I might be doing wrong here?
Many thanks,
a
1 Pool
69 Job
4982796 File
There are at least two aspects to all this. First, how can we continue to use
this tape (backups to it still run) and actually _restore_ data from it?
Second, if the data base has gotten so wedged that restores are no longer
possible, Bacula should refrain from indicating successful backups to the
volume, and instead mark it as `Error'.
Any ideas how to resolve this?
Andreas Koch
pgp1iBC5ZAf0p.pgp
Description: PGP signature
't have lost any data, right?
2) What do I do with the Sunday-0001 volume, now that it is marked with an
Error status? Should I remove it from the Sunday pool, and add a fresh volume
instead? Should I test the volume outside of Bacula (dd write/read?)
3) In general, how common are such me
... now that I have actually switched on DMA for the IDE spool disk,
the tape is streaming along nicely :-)
Andreas Koch
On Wed, Sep 07, 2005 at 03:29:27PM +0200, Andreas Koch wrote:
> all' statistics, Bacula 1.36.3 achieves roughly 1.5MB/s, and is
> shoe-shining the tape during despo
is a dedicated 80GB IDE disk holding only the spool data.
I'd be grateful for any help diagnosing this slow-down. If you need
further info, please let me know.
Andreas Koch
pgpj11tkXZ1oF.pgp
Description: PGP signature
40 matches
Mail list logo
