with this to enable me
to label tapes daily-1 or daily-1b, etc:
labelstr daily-[0-9][0-9]*[a-z]*
:)
Jon LaBadie wrote:
On Tue, Aug 08, 2006 at 08:51:32AM -0700, Joe Donner (sent by Nabble.com)
wrote:
The amanda configuration I'm planning to put live this week includes
these
entries
-0400, Jon LaBadie wrote:
On Mon, Aug 07, 2006 at 02:19:12AM -0700, Joe Donner (sent by Nabble.com)
wrote:
Does anyone know, please?
Will appreciate your thoughts a lot.
Thanks.
Joe Donner wrote:
Dear all,
my tapelist has become a bit confused, due to my own
The amanda configuration I'm planning to put live this week includes these
entries in amanda.conf:
dumpcycle 0 (to force a full backup on every run, because all our data fit
comfortably onto a single tape every night, and amdump only runs for 4.5
hours)
runspercycle 5 days (to do an amdump each
Does anyone know, please?
Will appreciate your thoughts a lot.
Thanks.
Joe Donner wrote:
Dear all,
my tapelist has become a bit confused, due to my own fault, by me adding
tapes in the middle of my numbered sequence. At the moment it looks
like this:
20060803 daily-5 reuse
20060802
:
--On August 3, 2006 9:05:03 AM -0700 Joe Donner (sent by Nabble.com)
[EMAIL PROTECTED] wrote:
Yes, it's the exact same tape drive I've been using extensively for
testing, and all that time it had been sitting in the same position on
the floor. I moved it on Monday, and then amanda
Dear all,
my tapelist has become a bit confused, due to my own fault, by me adding
tapes in the middle of my numbered sequence. At the moment it looks like
this:
20060803 daily-5 reuse
20060802 daily-1 reuse
20060801 daily-3 reuse
20060731 daily-4 reuse
20060731 daily-2 reuse
daily-5 was used
Dear all,
Something really strange has happened to my amanda setup. I'm inclined to
feel impressed, but don't know whether this in fact points to something
being wrong.
If you compare run times, dump times, tape times, average dump rate and
average tape write rate for the four different dates
That was definitely not the case. The holding disk has been empty all this
time, except on 31 July. And after I ran amflush it was empty again.
What I don't understand is the increase in dump time and tape time? They
both more than doubled in speed! How is that possible?
Olivier Nicole
the mail reports.
I'm a bit worried because it's looking too good to be true.
I also don't see how it can dump 130-odd gigabytes of data within a bit more
than 3 hours??
Thanks for your help on this.
Jon LaBadie wrote:
On Thu, Aug 03, 2006 at 02:46:06AM -0700, Joe Donner (sent by Nabble.com
was
impressed by the 9 hours it took to do backups, but now I'm speechless...
I've introduced a new tape for tonight's backup run. Will see what it tells
me tomorrow.
Thanks very much for your help!
Jon LaBadie wrote:
On Thu, Aug 03, 2006 at 08:25:43AM -0700, Joe Donner (sent by Nabble.com
Hi,
I'd appreciate some advice on what is regarded as the correct usage of
amflush and the tapes to use with amflush.
If the need to run amflush occurs, then amanda tells you which tape to use
next, or that you can use a new tape.
My question is simply this: Is it acceptable to use the next
amanda label it automatically?
Thanks!
Mitch Collinsworth wrote:
On Mon, 31 Jul 2006, Joe Donner (sent by Nabble.com) wrote:
E.g. I use daily-1 for a backup run, and the backup fails for some reason
and some data is on the holding disk. Amanda tells me that she expects
daily-2 or a new
The little bit of experience I have of amanda has showed me that dumpcycle
0 in amanda.conf will force a level 0 (full) dump. I've been running
amanda in a test lab with that setting before going production with
incremental backups.
Probably not the correct way of doing it in your case, but
Dear all,
say your amanda backup server itself dies, and you need to
reinstall/recreate it from scratch.
You want the new backup server to have available the information needed to
find and restore data from tapes, i.e. the info you get when running:
amadmin config find server_name disk
or like
Well, for what it's worth:
I ran a backup job with just the DLEs that failed to backup/flush, and it
all went well.
I then ran the exact same job I did on Friday, and it succeeded with no
errors this time. I'm beginning to think that maybe the tape used on Friday
may be damaged in some way.
I set up Amanda on Friday to do an almost real backup job. I thought this
would be the final test before putting it into operation.
When I arrived at work this morning, I was somewhat surprised to see that
the Amanda run doesn't seem to have finished. amstatus daily gives me some
information,
Good point - and that is why I need help unravelling what it all means. My
question now would be: 0.41% of what? What would 100% of that something
represent? Constant streaming of data to tape from holding disk?
I've just left it alone to see if I get different results when subsequently
Well, one thing I've noticed is that the DLEs in question are the ones with
largest overall size:
+/- 8GB
+/- 9GB
+/- 32GB
All the other DLEs (except for the two I mentioned, which are in fact hidden
files) have successfully been written to tape and are less than
approximately 2GB in size...
:19 dumper1 daily
amanda2154 2145 0 Jul14 ?00:00:00 dumper2 daily
amanda2155 2145 0 Jul14 ?00:00:00 dumper3 daily
Does this tell anyone anything?
Paul Bijnens wrote:
On 2006-07-17 11:36, Joe Donner (sent by Nabble.com) wrote:
Good point - and that is why I need
-17 13:32, Joe Donner (sent by Nabble.com) wrote:
and ps -fu amanda outputs:
UIDPID PPID C STIME TTY TIME CMD
amanda2136 2135 0 Jul14 ?00:00:00 /bin/sh /usr/sbin/amdump
daily
amanda2145 2136 0 Jul14 ?00:00:02 /usr/lib/amanda/driver
daily
amanda
13:32, Joe Donner (sent by Nabble.com) wrote:
and ps -fu amanda outputs:
UIDPID PPID C STIME TTY TIME CMD
amanda2136 2135 0 Jul14 ?00:00:00 /bin/sh /usr/sbin/amdump
daily
amanda2145 2136 0 Jul14 ?00:00:02 /usr/lib/amanda/driver
daily
amanda
Sorry, I've already went and deleted that file...
Alexander Jolk wrote:
Joe Donner (sent by Nabble.com) wrote:
FAILURE AND STRANGE DUMP SUMMARY:
minerva/usr/local/clients lev 0 FAILED [input: Can't read data: :
Input/output error]
And the holding disk still contains a folder
Thanks for your replies.
I could have phrased my question slightly better.
I want to know what the exclude list should look like to make sure I exclude
all files with these extensions in any directory/subdirectory contained
under the disklist entries:
.ora
.dbf
.dmp
.dmp.gz.xx
If I
Dear all,
I've now configured an exclusion list for use with Amanda. At first I used
these entries:
*.ora
*.dbf
*.dmp
*.dmp.gz*
but then I re-read the Amanda documentation, which states:
When AMANDA attempts to exclude a file or directory it does so relative to
the area being archived. For
When you run amstatus config while a dump is active, does it show you a
progress report (for want of a better term)?
Thanks.
--
View this message in context:
http://www.nabble.com/amstatus-during-active-dump-tf1930763.html#a5288402
Sent from the Amanda - Users forum at Nabble.com.
Dear all,
in my Amanda test lab, while trying to sort out my issues with hardware vs.
software compression, amdump didn't run on 5 July last week (I subsequently
put Amanda on hold to prevent amdump from running throughout the rest of the
week). So now I have a directory on the holding disk
I got these replies by email, which I think clear it up for me. Still not
sure about whether I can start from scratch by erasing the existing
hardware-compressed tapes, and then issuing mt -f /dev/nst0 defcompression 0
in crontab, but I'm going to try anyway:
Software compression is normally
Does anyone use or have knowledge of using LVM snapshots with Amanda backups?
I believe it to be the same concept as Shadow Volume Copies in Windows 2003,
and that is quite useful.
A little bit of info here:
http://arstechnica.com/articles/columns/linux/linux-20041013.ars
I'm just wondering
Sorry to be bothersome about this, but will the below work?
Joe Donner wrote:
Thanks for your reply.
do you mean that I will see the behaviour you're describing only if I'm
reusing tapes with hardware-compressed data? I only have 3 tapes so far,
so don't mind erasing them.
I find
Thanks to everyone for your replies.
Ok, so what I really wanted to do was to use software compression, and not
hardware compression.
Cyrille's suggestion sounds like what I need, but again I'm not sure whether
using this command will mean that compression is turned off permanently.
I'll look
Dear all,
I just want to clarify something about compression:
My understanding is that you can use either software or hardware
compression, or can switch between the two if needed.
What is generally, in your experience, the best of the two to use?
To switch off hardware compression, I believe
Dear all,
I think I may finally have cracked Amanda, but there are two things not
quite clear to me:
1. When you do an amrecover, do you HAVE to rewind the tape first? This
isn't a problem as such, I'm just wondering whether or not it should work
that way, i.e. in amanda.conf I've got
Thanks Jon!
Your reply was very helpful indeed, especially on point number 2!
I do appreciate it.
Regards,
Joe
Jon LaBadie wrote:
On Fri, Jun 30, 2006 at 03:40:50AM -0700, Joe Donner (sent by Nabble.com)
wrote:
Dear all,
I think I may finally have cracked Amanda, but there are two
Hi,
thanks for your explanation. But I think maybe I'll just crawl around for a
bit before trying to walk!
It does sound interesting though - I'll keep it in mind for when I'm more
comfortable with Amanda.
Best regards,
Joe
--
View this message in context:
Hi,
can anyone please help me understand this: Apparently, you have to
calculate how many tapes you need for your backup schedule as the number of
tapes needed for every day the backup will run in your dumpcycle + one extra
tape to avoid the risk of overwriting a full backup performed at the
Thanks very much for clarifying that to me.
Yes, I meant that (at least at present) all data will fit onto one tape for
every day of the week, i.e. if a full backup is done every day Monday to
Friday, then Monday's full backup will fit onto one tape, Tuesday's will fit
onto one tape, and so on.
Matt,
thank you very much for your advice - it has helped me out a great deal to
understand what to do.
Much appreciated!!
Regards,
Joe
--
View this message in context:
http://www.nabble.com/Appropriate-number-of-tapes-in-a-set-t1848286.html#a5046521
Sent from the Amanda - Users forum at
That's an interesting suggestion, but I don't really follow on how to do this
in practice.
Are you saying that you do daily backups just to disk, and only rely on
monthly backups on tape which are then kept off-site? Or do you mean do
backups to both disk and tape - to disk for fast recovery
Hi and thanks for your replies.
See below for the log file contents (21.06.06). It also shows the version
(which I used simply because Red Hat had those rpms available on their web
site - I didn't want to add the 'complexity' of having to compile the source
myself). In my stupidity I don't see
Hi,
I'm running Amanda in a test lab, and every several days or so the backup
job to virtual tape fails because a process called amandad becomes
unresponsive on the backup client. When doing an amcheck from the Amanda
server it tells me that amandad on the client is busy. When having a look
at
Hmmm blimey...I find it all a bit complicated (but I hope that's due to me
being rather new to Linux and Amanda and not me being stupid!).
I'll give it another try and some test runs and see how it goes.
Thank you very much for all your input and patience.
Best regards,
Joe
--
View this
Dear all,
I've just run amtapetype -f /dev/nst0 for Amanda to generate a tapetype
definition for an HP Storageworks SDLT 320 tape drive.
The results came back as:
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression on)
length 135040 mbytes
filemark
Firstly - thank you for the replies.
Secondly - I'm now more confused than before!
Is my understanding correct then that I can conceivably use this tapetype
definition, but that I probably shouldn't expect to be backing up more than
approximately 160GB to a tape? Or, more to the point,
Or does it work this way:
Amanda sends compressed data to the tape drive.
The tape drive also compresses the data, and therefore actually expands it.
Amanda doesn't know this.
After Amanda has sent 135GB to the tape drive, the tape drive has actually
written 160GB to the tape, and tells
44 matches
Mail list logo