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
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! http://sdm.link
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 recent backups
ile 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
> <k...@esa.informatik.tu-darmstadt.de
> <mailto:k
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:
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
-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
-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
-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
ChangerOVERLAND NEO
-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 fails
to read the tape's header
-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
-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
-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 Rewind OK.
-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
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.00)
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 device LTO-4 (/dev/nst0
-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
-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
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: 965
FD Bytes Written: 1,251,958,893 (1.251 GB)
SD Bytes Written
-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
-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 underlying full is attached below. It does lack
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 ORDER BY
-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 column in the output of the SQL
query
SELECT Path.Path
-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 used the wrong JobID, those were indeed
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...)
during backup indicate a configuration problem and I fear
+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...)
during backup indicate a configuration problem and I fear for the
consistency
of our data.
The warning means that the checksum wasn't sent
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/2010 01:41 PM
hints.
For reference, I am using Accurate = yes with
FileSet {
Name = FullSet
Include {
Options {
signature = SHA1;
verify=pins1;
accurate=pins1;
}
...
Many thanks,
Andreas Koch
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 SIGNATURE
(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,
Andreas Koch
:-)
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 * PGP key available *
-BEGIN
mark it as `Error'.
Any ideas how to resolve this?
Andreas Koch
pgp1iBC5ZAf0p.pgp
Description: PGP signature
errors on LTO-2 tapes? This is the
first time we are using such a drive, so we don't have any experience with
it. In contrast, with our DLT drives, we never had a single media error over
the last 4 years.
Any help is appreciated,
Andreas Koch
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
... 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 despooling quite
37 matches
Mail list logo
