RE: Specify UID for amandabackup
I did it by creating the amandabackup user before I installed amanda. Don't forget to set the home directory correctly. -Sandro -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On Behalf Of Mike Driscoll Sent: Wednesday, June 14, 2017 3:48 PM To: amanda-users@amanda.org Subject: Specify UID for amandabackup How can I set a specific UID for the amandabackup user when installing the amanda client on Linux? Mike
RE: amflush
From my amanda.conf?
tapetype "LTO6"
define tapetype LTO6 {
comment "Created by amtapetype; compression disabled"
length 2459879424 kbytes
filemark 2684 kbytes
speed 154767 kps
blocksize 256 kbytes
}
define changer "tape_drive" {
tpchanger "chg-single:tape:/dev/nst0"
device-property "BLOCK_SIZE" "256 kbytes"
}
tpchanger "tape_drive"
What’s weird is this was working fine for nearly a month and a
half before it stopped.
Which log files should I look at to try and figure out why the
original backup failed?
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Tuesday, April 11, 2017 9:27 AM
To: Ochressandro Rettinger ; Nathan Stratton Treadway
; amanda-users@amanda.org
Subject: Re: amflush
Two thread in g_cond_wait is a bug.
Can you post your storage and changer section?
Jean-Louis
On 11/04/17 11:03 AM, Ochressandro Rettinger wrote:
Sorry, I’m definitely not a gdb power user. I had to google to
get that much. :)
Thread 3 (Thread 0x7fcbdea14700 (LWP 16608)):
#0 0x7fcbe718cbf9 in syscall () from /lib64/libc.so.6
#1 0x7fcbe5a9b94f in g_cond_wait () from /lib64/libglib-2.0.so.0
#2 0x7fcbe07427ba in device_thread () from
/usr/lib64/amanda/libamdevice-3.4.so
#3 0x7fcbe5a7e0f5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#4 0x7fcbe7463dc5 in start_thread () from /lib64/libpthread.so.0
#5 0x7fcbe719273d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7fcbde213700 (LWP 16609)):
#0 0x7fcbe718cbf9 in syscall () from /lib64/libc.so.6
#1 0x7fcbe5a9b94f in g_cond_wait () from /lib64/libglib-2.0.so.0
#2 0x7fcbe099e3da in holding_thread () from
/usr/lib64/amanda/libamserver-3.4.so
#3 0x7fcbe5a7e0f5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#4 0x7fcbe7463dc5 in start_thread () from /lib64/libpthread.so.0
#5 0x7fcbe719273d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7fcbe8984740 (LWP 16607)):
#0 0x7fcbe7187dfd in poll () from /lib64/libc.so.6
#1 0x7fcbe5a5904c in g_main_context_iterate.isra.24 () from
/lib64/libglib-2.0.so.0
#2 0x7fcbe5a5916c in g_main_context_iteration () from
/lib64/libglib-2.0.so.0
#3 0x7fcbe65dcb45 in event_loop_wait () from
/usr/lib64/amanda/libamanda-3.4.so
#4 0x7fcbdfc698b0 in _wrap_run_c () from
/usr/local/share/perl5/auto/Amanda/MainLoop/libMainLoop.so
#5 0x7fcbe84a742f in Perl_pp_entersub () from
/usr/lib64/perl5/CORE/libperl.so
#6 0x7fcbe849fba6 in Perl_runops_standard () from
/usr/lib64/perl5/CORE/libperl.so
#7 0x7fcbe843c9a5 in perl_run () from /usr/lib64/perl5/CORE/libperl.so
#8 0x00400d99 in main ()
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Tuesday, April 11, 2017 9:00 AM
To: Ochressandro Rettinger
<mailto:orettin...@salud.unm.edu>; Nathan Stratton
Treadway <mailto:natha...@ontko.com>;
amanda-users@amanda.org<mailto:amanda-users@amanda.org>
Subject: Re: amflush
I want the stack trace of all threads,not only the main thread.
in gdb for the taper process, do: thread apply all bt
Jean-Louis
Disclaimer
This message is the property of CARBONITE, INC.<http://www.carbonite.com> and
may contain confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or
deliver this message to anyone. Instead, destroy it and notify me by reply
e-mail.
Disclaimer
This message is the property of CARBONITE, INC.<http://www.carbonite.com> and
may contain confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or
deliver this message to anyone. Instead, destroy it and notify me by reply
e-mail.
RE: amflush
Sorry, I’m definitely not a gdb power user. I had to google to get that much. :) Thread 3 (Thread 0x7fcbdea14700 (LWP 16608)): #0 0x7fcbe718cbf9 in syscall () from /lib64/libc.so.6 #1 0x7fcbe5a9b94f in g_cond_wait () from /lib64/libglib-2.0.so.0 #2 0x7fcbe07427ba in device_thread () from /usr/lib64/amanda/libamdevice-3.4.so #3 0x7fcbe5a7e0f5 in g_thread_proxy () from /lib64/libglib-2.0.so.0 #4 0x7fcbe7463dc5 in start_thread () from /lib64/libpthread.so.0 #5 0x7fcbe719273d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7fcbde213700 (LWP 16609)): #0 0x7fcbe718cbf9 in syscall () from /lib64/libc.so.6 #1 0x7fcbe5a9b94f in g_cond_wait () from /lib64/libglib-2.0.so.0 #2 0x7fcbe099e3da in holding_thread () from /usr/lib64/amanda/libamserver-3.4.so #3 0x7fcbe5a7e0f5 in g_thread_proxy () from /lib64/libglib-2.0.so.0 #4 0x7fcbe7463dc5 in start_thread () from /lib64/libpthread.so.0 #5 0x7fcbe719273d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7fcbe8984740 (LWP 16607)): #0 0x7fcbe7187dfd in poll () from /lib64/libc.so.6 #1 0x7fcbe5a5904c in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 #2 0x7fcbe5a5916c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #3 0x7fcbe65dcb45 in event_loop_wait () from /usr/lib64/amanda/libamanda-3.4.so #4 0x7fcbdfc698b0 in _wrap_run_c () from /usr/local/share/perl5/auto/Amanda/MainLoop/libMainLoop.so #5 0x7fcbe84a742f in Perl_pp_entersub () from /usr/lib64/perl5/CORE/libperl.so #6 0x7fcbe849fba6 in Perl_runops_standard () from /usr/lib64/perl5/CORE/libperl.so #7 0x7fcbe843c9a5 in perl_run () from /usr/lib64/perl5/CORE/libperl.so #8 0x00400d99 in main () -Sandro From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com] Sent: Tuesday, April 11, 2017 9:00 AM To: Ochressandro Rettinger ; Nathan Stratton Treadway ; amanda-users@amanda.org Subject: Re: amflush I want the stack trace of all threads,not only the main thread. in gdb for the taper process, do: thread apply all bt Jean-Louis Disclaimer This message is the property of CARBONITE, INC.<http://www.carbonite.com> and may contain confidential or privileged information. If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone. Instead, destroy it and notify me by reply e-mail.
RE: amflush
Taper debug file: Mon Apr 10 15:21:13.388038789 2017: pid 16607: thd-0x1dcae00: taper: pid 16607 ruid 9000 euid 9000 version 3.4: start at Mon Apr 10 15:21:13 2017 Mon Apr 10 15:21:13.388111083 2017: pid 16607: thd-0x1dcae00: taper: Arguments: NMHPVPR --storage NMHPVPR --log-filename /var/lib/amanda/NMHPVPR/state/log/log.20170410152105.0 Mon Apr 10 15:21:13.388421435 2017: pid 16607: thd-0x1dcae00: taper: reading config file /etc/amanda/NMHPVPR/amanda.conf Mon Apr 10 15:21:13.389776453 2017: pid 16607: thd-0x1dcae00: taper: pid 16607 ruid 9000 euid 9000 version 3.4: rename at Mon Apr 10 15:21:13 2017 Mon Apr 10 15:21:13.397097849 2017: pid 16607: thd-0x1dcae00: taper: Amanda::Taper::Scan::traditional stage 1: search for oldest reusable volume Mon Apr 10 15:21:13.397251012 2017: pid 16607: thd-0x1dcae00: taper: Amanda::Taper::Scan::traditional oldest reusable volume is 'NMHPVPR0002' Mon Apr 10 15:21:13.397341803 2017: pid 16607: thd-0x1dcae00: taper: Amanda::Taper::Scan::traditional changer is not fast-searchable; skipping to stage 2 Mon Apr 10 15:21:13.397421969 2017: pid 16607: thd-0x1dcae00: taper: Amanda::Taper::Scan::traditional stage 2: scan for any reusable volume Mon Apr 10 15:21:13.401516306 2017: pid 16607: thd-0x1dcae00: taper: Device is in variable block size Mon Apr 10 15:21:18.258290267 2017: pid 16607: thd-0x1dcae00: taper: Slot 1 with label NMHPVPR0002 is usable Mon Apr 10 15:21:18.258422019 2017: pid 16607: thd-0x1dcae00: taper: Amanda::Taper::Scan::traditional result: 'NMHPVPR0002' on tape:/dev/nst0 slot 1, mode 2 Mon Apr 10 15:21:18.260327601 2017: pid 16607: thd-0x1dcae00: taper: Amanda::Taper::Scribe preparing to write, part size 0, using no cache (PEOM will be fatal) (splitter) (no LEOM) Mon Apr 10 15:21:18.260781324 2017: pid 16607: thd-0x1dcae00: taper: Starting -> )> Mon Apr 10 15:21:18.260819175 2017: pid 16607: thd-0x1dcae00: taper: Final linkage: -(MEM_RING)-> Mon Apr 10 15:21:18.261417598 2017: pid 16607: thd-0x1dcae00: taper: header native_crc: 48f5f7aa:3983360 Mon Apr 10 15:21:18.261445517 2017: pid 16607: thd-0x1dcae00: taper: header client_crc: 48f5f7aa:3983360 Mon Apr 10 15:21:18.261456690 2017: pid 16607: thd-0x1dcae00: taper: header server_crc: 823a1732:1282787 Mon Apr 10 15:21:18.261557266 2017: pid 16607: thd-0x1dcae00: taper: start_recovery called Mon Apr 10 15:21:18.274176799 2017: pid 16607: thd-0x1dcae00: taper: Building type TAPESTART header of 262144-262144 bytes with name='NMHPVPR0002' disk='' dumplevel=0 and blocksize=262144 Mon Apr 10 15:21:30.273418789 2017: pid 16607: thd-0x338a800: taper: Building type SPLIT_FILE header of 262144-262144 bytes with name='fileserver2' disk='/Hope_IT' dumplevel=1 and blocksize=262144 /usr/bin/perl amflush stack trace: #0 0x7f478b5a9ecc in waitpid () from /lib64/libpthread.so.0 #1 0x7f478c5c2c1f in Perl_wait4pid () from /usr/lib64/perl5/CORE/libperl.so #2 0x7f478c630e86 in Perl_pp_wait () from /usr/lib64/perl5/CORE/libperl.so #3 0x7f478c5deba6 in Perl_runops_standard () from /usr/lib64/perl5/CORE/libperl.so #4 0x7f478c57b9a5 in perl_run () from /usr/lib64/perl5/CORE/libperl.so #5 0x00400d99 in main () /usr/libexec/amanda/driver stack trace: #0 0x7fed83286de0 in __poll_nocancel () from /lib64/libc.so.6 #1 0x7fed837c104c in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 #2 0x7fed837c116c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #3 0x7fed83ae6aed in event_loop_wait () from /usr/lib64/amanda/libamanda-3.4.so #4 0x00404da8 in main () /usr/bin/perl taper stack trace: #0 0x7fcbe7187dfd in poll () from /lib64/libc.so.6 #1 0x7fcbe5a5904c in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 #2 0x7fcbe5a5916c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #3 0x7fcbe65dcb45 in event_loop_wait () from /usr/lib64/amanda/libamanda-3.4.so #4 0x7fcbdfc698b0 in _wrap_run_c () from /usr/local/share/perl5/auto/Amanda/MainLoop/libMainLoop.so #5 0x7fcbe84a742f in Perl_pp_entersub () from /usr/lib64/perl5/CORE/libperl.so #6 0x7fcbe849fba6 in Perl_runops_standard () from /usr/lib64/perl5/CORE/libperl.so #7 0x7fcbe843c9a5 in perl_run () from /usr/lib64/perl5/CORE/libperl.so #8 0x00400d99 in main () -Sandro From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com] Sent: Tuesday, April 11, 2017 8:37 AM To: Ochressandro Rettinger ; Nathan Stratton Treadway ; amanda-users@amanda.org Subject: Re: amflush It looks like the taper process is hang. Can you post the taper debug file? Can you get a gdb stacktrace of all threads? Jean-Louis On 11/04/17 10:12 AM, Ochressandro Rettinger wrote: > In fact, I am now sure that it's not doing anything. I ran amstatus this > morning and it looks exactly the same as it did yesterday afternoon
RE: amflush
In fact, I am now sure that it's not doing anything. I ran amstatus this morning and it looks exactly the same as it did yesterday afternoon. If I can't get amflush to work, is there a way to clear out the stuff that needs flushing in a way that won't mess Amanda up? I need to be able to run backups tonight. -Sandro -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On Behalf Of Ochressandro Rettinger Sent: Monday, April 10, 2017 4:31 PM To: Nathan Stratton Treadway ; amanda-users@amanda.org Subject: Re: amflush I'm not sure it's doing anything. [amandabackup@archivist NMHPVPR]$ amstatus NMHPVPR Using: /var/lib/amanda/NMHPVPR/state/log/amdump >From Mon Apr 10 15:21:05 MDT 2017 fileserver2:/Hope_IT 20170408010017 1 1252k flushing (0k done (0.00%)) (15:21:10) fileserver2:/Hope_Secure 20170408010017 1 2006k wait for flushing fileserver2:/Hope_Shared 20170408010017 1 876k wait for flushing fileserver2:/Hope_Students 20170408010017 0 17825086k wait for flushing fileserver2:/slash 20170408010017 0 1192436k wait for flushing pr-db2:/slash 20170408010017 0 179616325k wait for flushing pr-db2test:/slash 20170408010017 0 11823469k wait for flushing SUMMARY dle real estimated size size - - disk: 0 estimated : 00k flush : 7 210461452k dump failed : 00k ( 0.00%) wait for dumping: 00k ( 0.00%) dumping to tape : 0 0k 0k ( 0.00%) ( 0.00%) dumping : 0 0k 0k ( 0.00%) ( 0.00%) dumped : 0 0k 0k ( 0.00%) ( 0.00%) wait for writing wait to flush : 6 210460199k 210460199k (100.00%) ( 0.00%) writing to tape : 1 1252k 1252k (100.00%) ( 0.00%) dumping to tape failed to tape taped 10 dumpers idle : no-dumpers NMHPVPR qlen: 6 0: flushing (fileserver2:/Hope_IT) network free kps: 8 holding space : 2097152k (100.00%) 0 dumpers busy : 0:00:17 (100.00%) no-dumpers: 0:00:12 ( 70.32%) not-idle: 0:00:05 ( 29.68%) -Sandro From: Nathan Stratton Treadway Sent: Monday, April 10, 2017 4:26 PM To: amanda-users@amanda.org Cc: Ochressandro Rettinger Subject: Re: amflush On Mon, Apr 10, 2017 at 21:56:40 +, Ochressandro Rettinger wrote: > Is there a way to check to see how far along amflush is? the "amstatus" command. Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amflush
I'm not sure it's doing anything. [amandabackup@archivist NMHPVPR]$ amstatus NMHPVPR Using: /var/lib/amanda/NMHPVPR/state/log/amdump >From Mon Apr 10 15:21:05 MDT 2017 fileserver2:/Hope_IT 20170408010017 1 1252k flushing (0k done (0.00%)) (15:21:10) fileserver2:/Hope_Secure 20170408010017 1 2006k wait for flushing fileserver2:/Hope_Shared 20170408010017 1 876k wait for flushing fileserver2:/Hope_Students 20170408010017 0 17825086k wait for flushing fileserver2:/slash 20170408010017 0 1192436k wait for flushing pr-db2:/slash 20170408010017 0 179616325k wait for flushing pr-db2test:/slash 20170408010017 0 11823469k wait for flushing SUMMARY dle real estimated size size - - disk: 0 estimated : 00k flush : 7 210461452k dump failed : 00k ( 0.00%) wait for dumping: 00k ( 0.00%) dumping to tape : 0 0k 0k ( 0.00%) ( 0.00%) dumping : 0 0k 0k ( 0.00%) ( 0.00%) dumped : 0 0k 0k ( 0.00%) ( 0.00%) wait for writing wait to flush : 6 210460199k 210460199k (100.00%) ( 0.00%) writing to tape : 1 1252k 1252k (100.00%) ( 0.00%) dumping to tape failed to tape taped 10 dumpers idle : no-dumpers NMHPVPR qlen: 6 0: flushing (fileserver2:/Hope_IT) network free kps: 8 holding space : 2097152k (100.00%) 0 dumpers busy : 0:00:17 (100.00%) no-dumpers: 0:00:12 ( 70.32%) not-idle: 0:00:05 ( 29.68%) -Sandro From: Nathan Stratton Treadway Sent: Monday, April 10, 2017 4:26 PM To: amanda-users@amanda.org Cc: Ochressandro Rettinger Subject: Re: amflush On Mon, Apr 10, 2017 at 21:56:40 +, Ochressandro Rettinger wrote: > Is there a way to check to see how far along amflush is? the "amstatus" command. Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amflush
I just gave up and put the next tape in. It seems to be working now. Is there a way to check to see how far along amflush is? -Sandro From: owner-amanda-us...@amanda.org on behalf of Jean-Francois Malouin Sent: Monday, April 10, 2017 2:53 PM To: amanda-users@amanda.org Subject: Re: amflush * Debra S Baddorf [20170410 16:46]: > > > On Apr 10, 2017, at 3:43 PM, Debra S Baddorf wrote: > > > > Were there any other tapes “available” for it to use?The one you just > > re-labeled > > will have dropped to the last of the list.If it’s the only one, it’ll > > still be the one used. If there are other free tapes that you labelled > > before this one, > > they’ll be used first. > > > > You *CAN* edit the tapelist file and move around the lines, especially > > just these > > new labels, where the date is still blank.The bottom most one (with > > date 0) > > will get used. PPS check your 'taperscan' setting: default is 'traditional'. You might want to set it to 'oldest' See man amanda-taperscan. With 'oldest' you get: "An acceptable volume is a reusable volume, a new labeled volume or an unlabeled volume that can be labeled according to autolabel"... cheers, jf > > > > Deb > > PS You can check which one it intends to use next: > amadmintape > will show you the next one, and perhaps a few after that. > Deb > > > > > > > >> On Apr 10, 2017, at 3:36 PM, Ochressandro Rettinger > >> wrote: > >> > >>I did that, and it worked, but then when I ran amflush again, it didn't > >> list the tape name. > >> > >> [amandabackup@archivist ~]$ amflush NMHPVPR > >> Flushing dumps from 20170408010017 using storage "NMHPVPR", tape changer > >> "tape_drive". > >> > >> Are you sure you want to do this [yN]? Y > >> Running in background, you can log off now. > >> You'll get mail when amflush is finished. > >> > >>-Sandro > >> > >> -Original Message- > >> From: Debra S Baddorf [mailto:badd...@fnal.gov] > >> Sent: Monday, April 10, 2017 2:33 PM > >> To: Ochressandro Rettinger > >> Cc: Debra S Baddorf ; Debra S Baddorf > >> ; amanda-users@amanda.org > >> Subject: Re: amflush > >> > >> Try “amlabel -f ….. “ for “force”. > >> Be sure it’s the right tape, but I use it all the time. > >> Deb > >> > >> > >>> On Apr 10, 2017, at 3:17 PM, Ochressandro Rettinger > >>> wrote: > >>> > >>> Yes. It was less effective than I might have hoped. :-/ > >>> > >>> [amandabackup@archivist ~]$ amlabel NMHPVPR NMHPVPR0001 Reading > >>> label... > >>> Found label 'NMHPVPR0001' but it is not in the tapelist file. > >>> Not writing label. > >>> Not writing label. > >>> > >>> Do I need to erase the label somehow first? > >>> > >>> -Sandro > >>> > >>> -Original Message- > >>> From: Debra S Baddorf [mailto:badd...@fnal.gov] > >>> Sent: Monday, April 10, 2017 2:13 PM > >>> To: Ochressandro Rettinger > >>> Cc: Debra S Baddorf ; amanda-users@amanda.org > >>> Subject: Re: amflush > >>> > >>> Did you do another “amlabel” after doing “amrmtape”? > >>> Deb Baddorf > >>> > >>> > >>>> On Apr 10, 2017, at 2:16 PM, Ochressandro Rettinger > >>>> wrote: > >>>> > >>>> > >>>> I’m having problems with amflush and the tapelist. > >>>> > >>>> My backups didn’t work last night, so I swapped the tape > >>>> and ran amflush. Amflush hung, so I tried to stop it and run it again, > >>>> without changing the tape. In order to do that, I ran amrmtape on the > >>>> tape, and removed it from the tapelist file. This was apparently a > >>>> mistake, because now I can’t get amanda to do anything with that tape. > >>>> > >>>> [amandabackup@archivist ~]$ amcheck NMHPVPR Amanda Tape Server Host > >>>> Check > >>>> - > >>>> NOTE: Holding disk '/holding': 4085694464 KB disk space available, > >>>> using 2147483648 KB as requested FIPS mode initialized FIPS mode > >>>> initialized FIPS mode initialized FIPS mode initialized slot 1: > >>>> volume 'NMHPVPR0001' is not in the tapelist all slots have been > >>>> loaded Taper scan algorithm did not find an acceptable volume. > >>>> (expecting a new volume) > >>>> ERROR: No acceptable volumes found > >>>> Server check took 0.217 seconds > >>>> Amanda Backup Client Hosts Check > >>>> > >>>> Client check: 4 hosts checked in 1.217 seconds. 0 problems found. > >>>> (brought to you by Amanda 3.4) > >>>> > >>>> Is there a way to add this tape back into the tapelist > >>>> so that I can use it to finish my amflush dump? (I don’t actually > >>>> care if the dump is any good or not at this point, I just want the > >>>> thing cleaned up so I can run regular backups tonight.) > >>>> > >>>> -Sandro > >>> > >> > > >
RE: amflush
I did that, and it worked, but then when I ran amflush again, it didn't list the tape name. [amandabackup@archivist ~]$ amflush NMHPVPR Flushing dumps from 20170408010017 using storage "NMHPVPR", tape changer "tape_drive". Are you sure you want to do this [yN]? Y Running in background, you can log off now. You'll get mail when amflush is finished. -Sandro -Original Message- From: Debra S Baddorf [mailto:badd...@fnal.gov] Sent: Monday, April 10, 2017 2:33 PM To: Ochressandro Rettinger Cc: Debra S Baddorf ; Debra S Baddorf ; amanda-users@amanda.org Subject: Re: amflush Try “amlabel -f ….. “ for “force”. Be sure it’s the right tape, but I use it all the time. Deb > On Apr 10, 2017, at 3:17 PM, Ochressandro Rettinger > wrote: > > Yes. It was less effective than I might have hoped. :-/ > > [amandabackup@archivist ~]$ amlabel NMHPVPR NMHPVPR0001 Reading > label... > Found label 'NMHPVPR0001' but it is not in the tapelist file. > Not writing label. > Not writing label. > > Do I need to erase the label somehow first? > > -Sandro > > -Original Message- > From: Debra S Baddorf [mailto:badd...@fnal.gov] > Sent: Monday, April 10, 2017 2:13 PM > To: Ochressandro Rettinger > Cc: Debra S Baddorf ; amanda-users@amanda.org > Subject: Re: amflush > > Did you do another “amlabel” after doing “amrmtape”? > Deb Baddorf > > >> On Apr 10, 2017, at 2:16 PM, Ochressandro Rettinger >> wrote: >> >> >>I’m having problems with amflush and the tapelist. >> >>My backups didn’t work last night, so I swapped the tape and >> ran amflush. Amflush hung, so I tried to stop it and run it again, without >> changing the tape. In order to do that, I ran amrmtape on the tape, and >> removed it from the tapelist file. This was apparently a mistake, because >> now I can’t get amanda to do anything with that tape. >> >> [amandabackup@archivist ~]$ amcheck NMHPVPR Amanda Tape Server Host >> Check >> - >> NOTE: Holding disk '/holding': 4085694464 KB disk space available, >> using 2147483648 KB as requested FIPS mode initialized FIPS mode >> initialized FIPS mode initialized FIPS mode initialized slot 1: >> volume 'NMHPVPR0001' is not in the tapelist all slots have been >> loaded Taper scan algorithm did not find an acceptable volume. >>(expecting a new volume) >> ERROR: No acceptable volumes found >> Server check took 0.217 seconds >> Amanda Backup Client Hosts Check >> >> Client check: 4 hosts checked in 1.217 seconds. 0 problems found. >> (brought to you by Amanda 3.4) >> >>Is there a way to add this tape back into the tapelist >> so that I can use it to finish my amflush dump? (I don’t actually >> care if the dump is any good or not at this point, I just want the >> thing cleaned up so I can run regular backups tonight.) >> >>-Sandro >
RE: amflush
Yes. It was less effective than I might have hoped. :-/ [amandabackup@archivist ~]$ amlabel NMHPVPR NMHPVPR0001 Reading label... Found label 'NMHPVPR0001' but it is not in the tapelist file. Not writing label. Not writing label. Do I need to erase the label somehow first? -Sandro -Original Message- From: Debra S Baddorf [mailto:badd...@fnal.gov] Sent: Monday, April 10, 2017 2:13 PM To: Ochressandro Rettinger Cc: Debra S Baddorf ; amanda-users@amanda.org Subject: Re: amflush Did you do another “amlabel” after doing “amrmtape”? Deb Baddorf > On Apr 10, 2017, at 2:16 PM, Ochressandro Rettinger > wrote: > > > I’m having problems with amflush and the tapelist. > > My backups didn’t work last night, so I swapped the tape and > ran amflush. Amflush hung, so I tried to stop it and run it again, without > changing the tape. In order to do that, I ran amrmtape on the tape, and > removed it from the tapelist file. This was apparently a mistake, because > now I can’t get amanda to do anything with that tape. > > [amandabackup@archivist ~]$ amcheck NMHPVPR Amanda Tape Server Host > Check > - > NOTE: Holding disk '/holding': 4085694464 KB disk space available, > using 2147483648 KB as requested FIPS mode initialized FIPS mode > initialized FIPS mode initialized FIPS mode initialized slot 1: volume > 'NMHPVPR0001' is not in the tapelist all slots have been loaded Taper > scan algorithm did not find an acceptable volume. > (expecting a new volume) > ERROR: No acceptable volumes found > Server check took 0.217 seconds > Amanda Backup Client Hosts Check > > Client check: 4 hosts checked in 1.217 seconds. 0 problems found. > (brought to you by Amanda 3.4) > > Is there a way to add this tape back into the tapelist > so that I can use it to finish my amflush dump? (I don’t actually > care if the dump is any good or not at this point, I just want the > thing cleaned up so I can run regular backups tonight.) > > -Sandro
amflush
I'm having problems with amflush and the tapelist. My backups didn't work last night, so I swapped the tape and ran amflush. Amflush hung, so I tried to stop it and run it again, without changing the tape. In order to do that, I ran amrmtape on the tape, and removed it from the tapelist file. This was apparently a mistake, because now I can't get amanda to do anything with that tape. [amandabackup@archivist ~]$ amcheck NMHPVPR Amanda Tape Server Host Check - NOTE: Holding disk '/holding': 4085694464 KB disk space available, using 2147483648 KB as requested FIPS mode initialized FIPS mode initialized FIPS mode initialized FIPS mode initialized slot 1: volume 'NMHPVPR0001' is not in the tapelist all slots have been loaded Taper scan algorithm did not find an acceptable volume. (expecting a new volume) ERROR: No acceptable volumes found Server check took 0.217 seconds Amanda Backup Client Hosts Check Client check: 4 hosts checked in 1.217 seconds. 0 problems found. (brought to you by Amanda 3.4) Is there a way to add this tape back into the tapelist so that I can use it to finish my amflush dump? (I don't actually care if the dump is any good or not at this point, I just want the thing cleaned up so I can run regular backups tonight.) -Sandro
RE: Backing up the backup server
Are there any instructions available for how to do a full bare metal restore onto a physical server? I've got a process down for restoring VMs, but that's easy, because I can just make a new virtual hard drive and then move the whole thing onto my virtual hosts. I've got a process set up to record information about the underlying file systems and hard drive layout, but I have no idea how to take a blank machine and restore onto it. Is the general idea that you'd do an OS install, and an Amanda client install, and then run amrecover from / ? -Sandro -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On Behalf Of Alan Hodgson Sent: Wednesday, January 04, 2017 9:33 AM To: amanda-users@amanda.org Subject: Re: Backing up the backup server On Wednesday 04 January 2017 15:29:37 Ochressandro Rettinger wrote: > The ultimate goal of all of this backing up, for us, > is in case there's some sort of catastrophic failure. Like, the > server room burns down. But if that happened, the machine that's > making the tapes would be lost as well. Which means that with my very > limited knowledge of Amanda, I don't know how to recover from a tape > without the Amanda server that created it. > > If I were to copy /var/lib/amanda and /etc/amanda to > some other remote system, is that enough to reconstruct the tape logs > (for lack of a better term) and configuration that would be needed to > perform recoveries? Obviously I'd need to install Amanda on the > replacement server, but if I had those files, would that let Amanda > think that it was the system that had created those tapes, at least > enough to read them? Is there a better way to do this? > /etc/amanda, and wherever the amanda db files are (the infofile, logdir, indexdir, and tapelist settings from amanda.conf) You should also have copies of any encryption keys used. I would also recommend you have details on each client regarding at least drives sizes and partitioning, RAID setups, filesystem sizes and layouts, LVM configuration, etc, things you'll need to prep on them before restoring any data. Also, where you can find the latest database backups, and other stuff that amanda can't backup live, and how to restore those. Technically,you don't need the amanda config, the files can be extracted from the tapes for a bare-metal restore without needing the index files. You should document and practice your restoration process, for at least the amanda server and one full client machine of each type, to ensure it works. Full restores are a pain, honestly, testing the process before you need it makes panic time less stressful.
Backing up the backup server
The ultimate goal of all of this backing up, for us, is in case there's some sort of catastrophic failure. Like, the server room burns down. But if that happened, the machine that's making the tapes would be lost as well. Which means that with my very limited knowledge of Amanda, I don't know how to recover from a tape without the Amanda server that created it. If I were to copy /var/lib/amanda and /etc/amanda to some other remote system, is that enough to reconstruct the tape logs (for lack of a better term) and configuration that would be needed to perform recoveries? Obviously I'd need to install Amanda on the replacement server, but if I had those files, would that let Amanda think that it was the system that had created those tapes, at least enough to read them? Is there a better way to do this? Thanks, -Sandro
Monthly full backups
I've got Amanda running in the normal manner, with a 10 day tape cycle, 7 day dump cycle, and 5 runspercycle, letting Amanda handle when to do fulls and incrementals. My boss wants to do separate monthly full backups on top of that. I found the FAQ answer that talks about using a completely separate set of tapes and setting "record no", but I was wondering what that actually does? Does it tell the *client* not to record something, or the server? And what is it not recording, at that point? Does recovering data from one of those tapes work just like recovering from a regular tape, only using the name of the new config with 'amrecover'? -Sandro
RE: amanda-3.4: new parameters etc
This is what I have in my 3.4 config for a single tape drive:
---
tapetype "LTO6"
define tapetype LTO6 {
comment "Created by amtapetype; compression disabled"
length 2459879424 kbytes
filemark 2684 kbytes
speed 154767 kps
blocksize 256 kbytes
}
define changer "tape_drive" {
tpchanger "chg-single:tape:/dev/nst0"
device-property "BLOCK_SIZE" "256 kbytes"
}
tpchanger "tape_drive"
---
It works for me. I have made backups and recovered from them.
-Sandro
-Original Message-
From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On
Behalf Of Stefan G. Weichinger
Sent: Monday, November 14, 2016 9:36 AM
To: Jean-Francois Malouin ;
amanda-users@amanda.org
Subject: Re: amanda-3.4: new parameters etc
Am 2016-11-14 um 17:12 schrieb Jean-Francois Malouin:
> I'm just starting experimenting with amanda-3.4 new feature set so I
> can't really say anything relevant at the moment. I'm still curious at
> the new 'storage' and 'policy' stuff and will experiment with them
> later this week.
>
> Regarding your problem, I usually have the tapedev enclosed in a
> define section like:
>
> define device "lto6-drive" {
> tapedev "tape:/dev/nst1"
> device-property "BLOCK_SIZE" "2 mbytes"
> }
>
> and then have tpchanger reference it like this:
>
> define changer "neo-t48" {
> tpchanger "chg-robot:/dev/changer"
> changerfile "/opt/amanda/etc/amanda/neo-t48-state"
> property "tape-device" "1=lto6-drive"
> property "use-slots" "1-48"
> property "eject-before-unload" "yes"
> property "eject-delay" "20s"
> property "unload-delay" "2s"
> property "load-poll" "5s poll 20s until 180s"
> property "status-interval" "5s"
> }
>
> tpchanger "neo-t48"
>
> amcheck seems happy with those.
thanks for providing this example.
I am looking for a more basic setup: no changer, just a single tape drive. Most
of my customers servers are set up this way, I will approach the changer-setups
later (doing it with vtapes already, btw)
-
As always I try to follow the documentation ;-)
It says ( http://wiki.zmanda.com/man/amanda.conf.5.html ):
> tapedev string
>
> Default: "null:". This parameter can either specify a device
> (explicitly or by referencing a device definition
[..]
> tpchanger string
>
> Default: not set. (deprecated)
so I have:
tapedev "tape:/dev/nst0"
in /etc/amanda/daily/amanda.conf
and no string/parameter "tpchanger" anywhere in that file.
But amcheck gives:
$ amcheck daily
Amanda Tape Server Host Check
-
NOTE: Holding disk '/mnt/amhold/daily': 112 GB disk space available, using 111
GB
ERROR: You must specify the storage 'tpchanger'
*maybe* a bug, maybe my fault somewhere.
I even tried to define and use a storage section like that:
define storage tpchanger {
runtapes 1 # just set something for tests }
storage tpchanger
... didn't change a thing.
RE: amanda-3.4 amtapetype: Error setting FSF_AFTER_FILEMARK
I had the same problem. I tried debugging it, but couldn't figure out
why it was failing, because the code returned was for success. So, I turned
the die() into a warn(), which, since it wasn't actually failing, never fired
off.
-Sandro
-Original Message-
From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On
Behalf Of Jean-Francois Malouin
Sent: Monday, November 14, 2016 8:06 AM
To: AMANDA users
Subject: amanda-3.4 amtapetype: Error setting FSF_AFTER_FILEMARK
Hi,
Amanda-3.4 and a new LTO6 tape library:
~amanda/sbin/amtapetype --version
amtapetype-3.4
~amanda/sbin/amtapetype -b 2048k -t tape-lto6 -f /dev/nst1 Checking for
FSF_AFTER_FILEMARK requirement
amtapetype: Error setting FSF_AFTER_FILEMARK: Success at
/opt/amanda/sbin/amtapetype line 372.
Any ideas?
The 3.3.6 version happily produced an tapetype entry:
/usr/sbin/amtapetype --version
amtapetype-3.3.6
/usr/sbin/amtapetype -b 2048k -t tape-lto6 -f /dev/nst1
define tapetype tape-lto6 {
comment "Created by amtapetype; compression disabled"
length 2459914240 kbytes
filemark 3227 kbytes
speed 156832 kps
blocksize 2048 kbytes
}
# LEOM is not supported for this drive and kernel
Thanks,
jf
Server compression vs: client compression
So, I understand the subject of software vs: hardware compression now (thanks for that very enlightening description of why it's good to let Amanda handle the compression, Chris) but now I'm wondering about the question of server vs: client compression. I would tend to think that it would be best to use client compression, if possible, because then you can take advantage of the parallel nature of all of those separate processors working on their compression tasks. But from what several people have said, it seems like server side compression is a common choice. Why would I want to choose one over the other? (Beyond the fact that in my particular case, client side compression isn't actually working for recovery purposes.) Thanks for answering all these questions, guys. :) -Sandro
RE: amrecover problems on compressed DLEs
I ran another backup with client compression, and tried
recovering from it. It hung in the same fashion as the previous time I tried
it. I then tried running amrecover on the actual client system itself (the
cleverly named "backuptest"), in the hopes that it would work better from
there. Sadly, it did not.
I then tried to read the files off the tape directly myself:
[root@archivist ssh]# tar -tf /dev/st0
tar: /dev/st0: Cannot read: Cannot allocate memory
tar: At beginning of tape, quitting now
tar: Error is not recoverable: exiting now
I'm not sure what that's about.
-Sandro
From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On
Behalf Of Ochressandro Rettinger
Sent: Tuesday, November 01, 2016 10:03 AM
To: 'Jean-Louis Martineau' ;
'amanda-users@amanda.org'
Subject: RE: amrecover problems on compressed DLEs
I tried to recover 4 or 5 times. It failed each time.
I only ran one backup of that type, but amcheckdump said it was
a good dump. I could try again.
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Tuesday, November 01, 2016 9:50 AM
To: Ochressandro Rettinger
mailto:orettin...@salud.unm.edu>>;
'amanda-users@amanda.org'
mailto:amanda-users@amanda.org>>
Subject: Re: amrecover problems on compressed DLEs
client compressed dump are decompressed by amrecover
server compressed dump are decompressed by amidxtaped (on the server)
I tried many recovery with client compressed dump and it never hanged.
Do you tried it once or many times?
Knowing if it always fail or sometimes fail can help.
Jean-Louis
On 01/11/16 11:40 AM, Ochressandro Rettinger wrote:
Since you asked about server vs: client compression, I decided
to try server side compression instead. And, because my life just isn't weird
enough, it worked.
When I look at the amidxtaped.debug file for the process that
worked on recovery from server compressed tape, I see that it appears as
though amidxtaped itself is spawning a gzip process, and when I look at the
amidxtaped.debug file for the process that hung forever, I see no similar
message. Also, it appears that amidxtaped is simply aware of more needed
steps, for the server compressed backups.
Tue Nov 01 09:17:14.081375699 2016: pid 153615: thd-0x19b6400: amidxtaped:
Starting ->
-> ->
)>
Tue Nov 01 09:17:14.081424025 2016: pid 153615: thd-0x19b6400: amidxtaped:
Final linkage: -(PULL_BUFFER)->
-(READFD)->
-(WRITEFD)-> -(PUSH_BUFFER_STATIC)->
-(PUSH_BUFFER_STATIC)->
-(WRITEFD)->
Vs:
Sat Oct 29 14:18:46.905301215 2016: pid 98917: thd-0x2653600: amidxtaped:
Starting ->
)>
Sat Oct 29 14:18:46.905335006 2016: pid 98917: thd-0x2653600: amidxtaped: Final
linkage: -(PULL_BUFFER)->
-(WRITEFD)->
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Monday, October 31, 2016 2:53 PM
To: Ochressandro Rettinger
<mailto:orettin...@salud.unm.edu>;
'amanda-users@amanda.org<mailto:amanda-users@amanda.org>'
<mailto:amanda-users@amanda.org>
Subject: Re: amrecover problems on compressed DLEs
You are doing client or server compression?
The backup was done with 3.4 or 3.3.?
Can you post the complete amrecover and amidxtaped debug files.
Jean-Louis
On 31/10/16 03:51 PM, Ochressandro Rettinger wrote:
I'm running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an RHEL
7.2 machine. My client is an RHEL 6.8 machine, running the same generation of
client, also from the zmanda RPM.
My disklist file was as follows:
backuptest /slash/ {
comp-gnutar-ssh
exclude append "./boot"
exclude append "./var"
}
backuptest /bootgnutar-ssh
backuptest /varcomp-gnutar-ssh-full
with the thought that everything in /boot is compressed already
anyway, and wanting to test the idea of splitting DLEs up and use different
backup methods and the like.
Well, the backup went OK, and running amcheckdump on the backup
showed as OK, but when I went to recover, attempting to recover /slash for
example, it would start trying to extract the files, and then just hang
forever. (Forever in this case being defined as 24 hours.) However, when I
tried to recover the /boot DLE, that actually worked. So, I changed my DLEs to
all be just plain "gnutar-ssh" type, re-ran the backup, and then attempted to
recover again, and was successful recovering.
I ran "ps -ef" while the amrecover process was hung, and saw
that it had spawned a "gzip -dc" process. So, I presume it was trying to pipe
compressed data to that process, but somehow, either before or afte
RE: amrecover problems on compressed DLEs
I tried to recover 4 or 5 times. It failed each time.
I only ran one backup of that type, but amcheckdump said it was
a good dump. I could try again.
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Tuesday, November 01, 2016 9:50 AM
To: Ochressandro Rettinger ;
'amanda-users@amanda.org'
Subject: Re: amrecover problems on compressed DLEs
client compressed dump are decompressed by amrecover
server compressed dump are decompressed by amidxtaped (on the server)
I tried many recovery with client compressed dump and it never hanged.
Do you tried it once or many times?
Knowing if it always fail or sometimes fail can help.
Jean-Louis
On 01/11/16 11:40 AM, Ochressandro Rettinger wrote:
Since you asked about server vs: client compression, I decided
to try server side compression instead. And, because my life just isn't weird
enough, it worked.
When I look at the amidxtaped.debug file for the process that
worked on recovery from server compressed tape, I see that it appears as
though amidxtaped itself is spawning a gzip process, and when I look at the
amidxtaped.debug file for the process that hung forever, I see no similar
message. Also, it appears that amidxtaped is simply aware of more needed
steps, for the server compressed backups.
Tue Nov 01 09:17:14.081375699 2016: pid 153615: thd-0x19b6400: amidxtaped:
Starting ->
-> ->
)>
Tue Nov 01 09:17:14.081424025 2016: pid 153615: thd-0x19b6400: amidxtaped:
Final linkage: -(PULL_BUFFER)->
-(READFD)->
-(WRITEFD)-> -(PUSH_BUFFER_STATIC)->
-(PUSH_BUFFER_STATIC)->
-(WRITEFD)->
Vs:
Sat Oct 29 14:18:46.905301215 2016: pid 98917: thd-0x2653600: amidxtaped:
Starting ->
)>
Sat Oct 29 14:18:46.905335006 2016: pid 98917: thd-0x2653600: amidxtaped: Final
linkage: -(PULL_BUFFER)->
-(WRITEFD)->
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Monday, October 31, 2016 2:53 PM
To: Ochressandro Rettinger
<mailto:orettin...@salud.unm.edu>;
'amanda-users@amanda.org<mailto:amanda-users@amanda.org>'
<mailto:amanda-users@amanda.org>
Subject: Re: amrecover problems on compressed DLEs
You are doing client or server compression?
The backup was done with 3.4 or 3.3.?
Can you post the complete amrecover and amidxtaped debug files.
Jean-Louis
On 31/10/16 03:51 PM, Ochressandro Rettinger wrote:
I'm running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an RHEL
7.2 machine. My client is an RHEL 6.8 machine, running the same generation of
client, also from the zmanda RPM.
My disklist file was as follows:
backuptest /slash/ {
comp-gnutar-ssh
exclude append "./boot"
exclude append "./var"
}
backuptest /bootgnutar-ssh
backuptest /varcomp-gnutar-ssh-full
with the thought that everything in /boot is compressed already
anyway, and wanting to test the idea of splitting DLEs up and use different
backup methods and the like.
Well, the backup went OK, and running amcheckdump on the backup
showed as OK, but when I went to recover, attempting to recover /slash for
example, it would start trying to extract the files, and then just hang
forever. (Forever in this case being defined as 24 hours.) However, when I
tried to recover the /boot DLE, that actually worked. So, I changed my DLEs to
all be just plain "gnutar-ssh" type, re-ran the backup, and then attempted to
recover again, and was successful recovering.
I ran "ps -ef" while the amrecover process was hung, and saw
that it had spawned a "gzip -dc" process. So, I presume it was trying to pipe
compressed data to that process, but somehow, either before or afterwards, it
was getting lost on its way to the tar process. Indeed, looking at the debug
file, I see "amrecover: Spawning "/usr/bin/gzip /usr/bin/gzip -dc" in pipeline".
The last thing in the debug file is "amrecover:
send_to_tape_server: DATA-READY" until I hit ctrl-C in the amrecover window, at
which point a "QUIT" was sent by amrecover, presumably to the amandad process
that it was connected to.
Any thoughts on why this wouldn't be working? Any thoughts on
other things I can look at?
-Sandro
RE: amrecover problems on compressed DLEs
Since you asked about server vs: client compression, I decided
to try server side compression instead. And, because my life just isn't weird
enough, it worked.
When I look at the amidxtaped.debug file for the process that
worked on recovery from server compressed tape, I see that it appears as
though amidxtaped itself is spawning a gzip process, and when I look at the
amidxtaped.debug file for the process that hung forever, I see no similar
message. Also, it appears that amidxtaped is simply aware of more needed
steps, for the server compressed backups.
Tue Nov 01 09:17:14.081375699 2016: pid 153615: thd-0x19b6400: amidxtaped:
Starting ->
-> ->
)>
Tue Nov 01 09:17:14.081424025 2016: pid 153615: thd-0x19b6400: amidxtaped:
Final linkage: -(PULL_BUFFER)->
-(READFD)->
-(WRITEFD)-> -(PUSH_BUFFER_STATIC)->
-(PUSH_BUFFER_STATIC)->
-(WRITEFD)->
Vs:
Sat Oct 29 14:18:46.905301215 2016: pid 98917: thd-0x2653600: amidxtaped:
Starting ->
)>
Sat Oct 29 14:18:46.905335006 2016: pid 98917: thd-0x2653600: amidxtaped: Final
linkage: -(PULL_BUFFER)->
-(WRITEFD)->
-Sandro
From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com]
Sent: Monday, October 31, 2016 2:53 PM
To: Ochressandro Rettinger ;
'amanda-users@amanda.org'
Subject: Re: amrecover problems on compressed DLEs
You are doing client or server compression?
The backup was done with 3.4 or 3.3.?
Can you post the complete amrecover and amidxtaped debug files.
Jean-Louis
On 31/10/16 03:51 PM, Ochressandro Rettinger wrote:
I'm running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an RHEL
7.2 machine. My client is an RHEL 6.8 machine, running the same generation of
client, also from the zmanda RPM.
My disklist file was as follows:
backuptest /slash/ {
comp-gnutar-ssh
exclude append "./boot"
exclude append "./var"
}
backuptest /bootgnutar-ssh
backuptest /varcomp-gnutar-ssh-full
with the thought that everything in /boot is compressed already
anyway, and wanting to test the idea of splitting DLEs up and use different
backup methods and the like.
Well, the backup went OK, and running amcheckdump on the backup
showed as OK, but when I went to recover, attempting to recover /slash for
example, it would start trying to extract the files, and then just hang
forever. (Forever in this case being defined as 24 hours.) However, when I
tried to recover the /boot DLE, that actually worked. So, I changed my DLEs to
all be just plain "gnutar-ssh" type, re-ran the backup, and then attempted to
recover again, and was successful recovering.
I ran "ps -ef" while the amrecover process was hung, and saw
that it had spawned a "gzip -dc" process. So, I presume it was trying to pipe
compressed data to that process, but somehow, either before or afterwards, it
was getting lost on its way to the tar process. Indeed, looking at the debug
file, I see "amrecover: Spawning "/usr/bin/gzip /usr/bin/gzip -dc" in pipeline".
The last thing in the debug file is "amrecover:
send_to_tape_server: DATA-READY" until I hit ctrl-C in the amrecover window, at
which point a "QUIT" was sent by amrecover, presumably to the amandad process
that it was connected to.
Any thoughts on why this wouldn't be working? Any thoughts on
other things I can look at?
-Sandro
amrecover problems on compressed DLEs
I'm running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an RHEL
7.2 machine. My client is an RHEL 6.8 machine, running the same generation of
client, also from the zmanda RPM.
My disklist file was as follows:
backuptest /slash/ {
comp-gnutar-ssh
exclude append "./boot"
exclude append "./var"
}
backuptest /bootgnutar-ssh
backuptest /varcomp-gnutar-ssh-full
with the thought that everything in /boot is compressed already
anyway, and wanting to test the idea of splitting DLEs up and use different
backup methods and the like.
Well, the backup went OK, and running amcheckdump on the backup
showed as OK, but when I went to recover, attempting to recover /slash for
example, it would start trying to extract the files, and then just hang
forever. (Forever in this case being defined as 24 hours.) However, when I
tried to recover the /boot DLE, that actually worked. So, I changed my DLEs to
all be just plain "gnutar-ssh" type, re-ran the backup, and then attempted to
recover again, and was successful recovering.
I ran "ps -ef" while the amrecover process was hung, and saw
that it had spawned a "gzip -dc" process. So, I presume it was trying to pipe
compressed data to that process, but somehow, either before or afterwards, it
was getting lost on its way to the tar process. Indeed, looking at the debug
file, I see "amrecover: Spawning "/usr/bin/gzip /usr/bin/gzip -dc" in pipeline".
The last thing in the debug file is "amrecover:
send_to_tape_server: DATA-READY" until I hit ctrl-C in the amrecover window, at
which point a "QUIT" was sent by amrecover, presumably to the amandad process
that it was connected to.
Any thoughts on why this wouldn't be working? Any thoughts on
other things I can look at?
-Sandro
RE: Where to acquire the Perl modules?
OK, I did that, but now yum complains about the missing requires in the rpmdb every time I install something. :-/ Do you know how hard it would be to repackage the RPM to not have this particular packaging bug? -Sandro From: Jean-Louis Martineau [mailto:jmartin...@carbonite.com] Sent: Thursday, October 27, 2016 2:50 PM To: Ochressandro Rettinger ; 'amanda-users@amanda.org' Subject: Re: Where to acquire the Perl modules? This is a packaging bug, Install the package without checking the dependencies: --nodeps Jean-Louis On 27/10/16 04:21 PM, Ochressandro Rettinger wrote: I'm trying to install Amanda on an RHEL 7 machine. I downloaded the rpm from the zmanda downloads page, but when I went to install it, there were complaints about unfulfilled dependencies. Google has not revealed the location of these packages to me. Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 (/amanda-backup_server-3.4-1.rhel7.x86_64) Requires: perl(Dancer2) Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 (/amanda-backup_server-3.4-1.rhel7.x86_64) Requires: perl(Amanda::Recovery) Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 (/amanda-backup_server-3.4-1.rhel7.x86_64) Requires: perl(Amanda::DB) Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 (/amanda-backup_server-3.4-1.rhel7.x86_64) Requires: perl(Amanda::Service) Any suggestions? -Sandro
Software vs: Hardware compression
Why does Amanda recommend the use of software compression vs: the built in hardware compression of the tape drive itself? Is that in fact still the current recommendation? -Sandro
Where to acquire the Perl modules?
I'm trying to install Amanda on an RHEL 7 machine. I downloaded the rpm from the zmanda downloads page, but when I went to install it, there were complaints about unfulfilled dependencies. Google has not revealed the location of these packages to me. Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 (/amanda-backup_server-3.4-1.rhel7.x86_64) Requires: perl(Dancer2) Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 (/amanda-backup_server-3.4-1.rhel7.x86_64) Requires: perl(Amanda::Recovery) Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 (/amanda-backup_server-3.4-1.rhel7.x86_64) Requires: perl(Amanda::DB) Error: Package: amanda-backup_server-3.4-1.rhel7.x86_64 (/amanda-backup_server-3.4-1.rhel7.x86_64) Requires: perl(Amanda::Service) Any suggestions? -Sandro
RE: amcheck failing when checking multiple clients
Oh, there are Ubuntu .deb packages of 3.3.9 on the downloads page on the website. http://www.zmanda.com/download-amanda.php It looks like they might only go through Ubuntu 14, though. I dunno what the difference between system version packages would be. -Sandro From: Chris Nighswonger [mailto:cnighswon...@foundations.edu] Sent: Friday, July 29, 2016 8:31 AM To: Ochressandro Rettinger Cc: amanda-users@amanda.org; Jean-Louis Martineau Subject: Re: amcheck failing when checking multiple clients Good question. The amanda server on this site is running Ubuntu and so 3.3.6 is the latest available amanda in the distro repos. Since most other *nix boxes are running Ubuntu, doing my own build is a bit of a chore. Not to mention I am quite unfamiliar with cooking up deb packages. So the curve is a bit steep which is what keeps me from going to the latest amanda version. That said, I did upgrade the amanda server to Ubuntu 16 in order to move from amanda 3.3.3 to 3.3.6 thinking that would correct this problem based on the post I mentioned previously. On Fri, Jul 29, 2016 at 10:21 AM, Ochressandro Rettinger mailto:orettin...@salud.unm.edu>> wrote: Asking as a newb who genuinely doesn't know: How hard is it to upgrade Amanda? If this is a 3.3.6 era bug, maybe upgrading all of your nodes to 3.3.9 would solve your problem? -Sandro -Original Message- From: owner-amanda-us...@amanda.org<mailto:owner-amanda-us...@amanda.org> [mailto:owner-amanda-us...@amanda.org<mailto:owner-amanda-us...@amanda.org>] On Behalf Of Chris Nighswonger Sent: Thursday, July 28, 2016 12:08 PM To: amanda-users@amanda.org<mailto:amanda-users@amanda.org> Cc: Jean-Louis Martineau mailto:jmartin...@carbonite.com>> Subject: Re: amcheck failing when checking multiple clients Maybe John-Louis can jump in here since these are symptoms of a bug which was supposed to have been fixed in 3.3.6 http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/amanda-20/amdumps-failing-and-some-amchecks-as-well-124340/ Summary of where things stand on this install: Server version 3.3.6 Client versions 3.3.3, 3.3.6 auth = bsdtcp The issue: 1. amcheck fails on a subset of clients when run against multiple clients (regardless of client version) with "selfcheck request failed: error sending REQ: write error to: Broken pipe" 2. amcheck does not fail on all clients, but fails on the same subset of clients each time. 3. amcheck does not fail when run against any single client, including those in the subset which does fail when run against multiple clients. 4. amservice fails when run against any member of that subset of clients which fails amcheck with "Request failed: Permission denied" 5. dumps run fine during the nightly backups for all clients, including those members of that amcheck failing subset. Misc. notes: 1. When amcheck fails on a client, the client contains no debug log. 2. The server amcheck debug log reflects the same issue mentioned above "Broken pipe" 3. From the prospective of a failing client: tcpdump shows an exchange of about 40 packets with the client when amcheck is run against a single client and succeeds 4. From the same prospective, tcpdump shows an exchange of about 68 packets with the client when amcheck is run against multiple clients and fails 5. All file perms have been checked and are correct on both server and client 6. backup user settings are correct on server and client 7. amandahosts is properly configured 8. xinetd configuration is correct on both server and client 9. forward and reverse DNS works correctly for the client I wonder if this might be a variation of the bug mentioned by JLM in the above referenced thread? Thanks for everyone's help here. On Thu, Jul 28, 2016 at 10:15 AM, Ochressandro Rettinger mailto:orettin...@salud.unm.edu>> wrote: > In the second chunk of log messages, it looks like for some reason > the BSDTCP connection is closing early. Unfortunately, I can't help you out > with that, as I'm set up to use ssh. > > Good luck! > > -Sandro > > -Original Message- > From: Chris Nighswonger > [mailto:cnighswon...@foundations.edu<mailto:cnighswon...@foundations.edu>] > Sent: Thursday, July 28, 2016 7:10 AM > To: amanda-users@amanda.org<mailto:amanda-users@amanda.org> > Cc: Ochressandro Rettinger > mailto:orettin...@salud.unm.edu>> > Subject: Re: amcheck failing when checking multiple clients > > Here are some potentially relevant lines form the log: > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > conn_read_callback 1 3 > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > tcpm_recv_token: read 47 bytes from 1 > Wed Ju
RE: amcheck failing when checking multiple clients
Asking as a newb who genuinely doesn't know: How hard is it to upgrade Amanda? If this is a 3.3.6 era bug, maybe upgrading all of your nodes to 3.3.9 would solve your problem? -Sandro -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On Behalf Of Chris Nighswonger Sent: Thursday, July 28, 2016 12:08 PM To: amanda-users@amanda.org Cc: Jean-Louis Martineau Subject: Re: amcheck failing when checking multiple clients Maybe John-Louis can jump in here since these are symptoms of a bug which was supposed to have been fixed in 3.3.6 http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/amanda-20/amdumps-failing-and-some-amchecks-as-well-124340/ Summary of where things stand on this install: Server version 3.3.6 Client versions 3.3.3, 3.3.6 auth = bsdtcp The issue: 1. amcheck fails on a subset of clients when run against multiple clients (regardless of client version) with "selfcheck request failed: error sending REQ: write error to: Broken pipe" 2. amcheck does not fail on all clients, but fails on the same subset of clients each time. 3. amcheck does not fail when run against any single client, including those in the subset which does fail when run against multiple clients. 4. amservice fails when run against any member of that subset of clients which fails amcheck with "Request failed: Permission denied" 5. dumps run fine during the nightly backups for all clients, including those members of that amcheck failing subset. Misc. notes: 1. When amcheck fails on a client, the client contains no debug log. 2. The server amcheck debug log reflects the same issue mentioned above "Broken pipe" 3. From the prospective of a failing client: tcpdump shows an exchange of about 40 packets with the client when amcheck is run against a single client and succeeds 4. From the same prospective, tcpdump shows an exchange of about 68 packets with the client when amcheck is run against multiple clients and fails 5. All file perms have been checked and are correct on both server and client 6. backup user settings are correct on server and client 7. amandahosts is properly configured 8. xinetd configuration is correct on both server and client 9. forward and reverse DNS works correctly for the client I wonder if this might be a variation of the bug mentioned by JLM in the above referenced thread? Thanks for everyone's help here. On Thu, Jul 28, 2016 at 10:15 AM, Ochressandro Rettinger wrote: > In the second chunk of log messages, it looks like for some reason > the BSDTCP connection is closing early. Unfortunately, I can't help you out > with that, as I'm set up to use ssh. > > Good luck! > > -Sandro > > -Original Message- > From: Chris Nighswonger [mailto:cnighswon...@foundations.edu] > Sent: Thursday, July 28, 2016 7:10 AM > To: amanda-users@amanda.org > Cc: Ochressandro Rettinger > Subject: Re: amcheck failing when checking multiple clients > > Here are some potentially relevant lines form the log: > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > conn_read_callback 1 3 > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: > tcpm_recv_token: read 47 bytes from 1 > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > conn_read_callback: tcpm_recv_token returned 47 Wed Jul 27 13:37:41 2016: > thd-0x55f48f90bc00: amcheck-clients: sec: > stream_read_callback: handle 1 > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > stream_read_callback: it was for us > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > stream_read_callback: read 47 bytes from scriptor:1 Wed Jul 27 13:37:41 2016: > thd-0x55f48f90bc00: amcheck-clients: sec: > recvpkt_callback: 47 > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > cancelling recvpkt for scriptor > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > conn_read_cancel: decremented ev_read_refcnt to 0 for scriptor Wed Jul 27 > 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > conn_read_cancel: releasing event handler for scriptor Wed Jul 27 13:37:41 > 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > parse_pkt: parsing buffer of 47 bytes > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > parse_pkt: REP (1): "OPTIONS features=9efefbff3f; > " > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > received REP packet (1) from scriptor, contains: > > "OPTIONS features=9efefbff3f; > " > > Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: > stream_sendpkt: enter > Wed Jul 27 13:37:41 2016:
RE: amcheck failing when checking multiple clients
In the second chunk of log messages, it looks like for some reason the BSDTCP connection is closing early. Unfortunately, I can't help you out with that, as I'm set up to use ssh. Good luck! -Sandro -Original Message- From: Chris Nighswonger [mailto:cnighswon...@foundations.edu] Sent: Thursday, July 28, 2016 7:10 AM To: amanda-users@amanda.org Cc: Ochressandro Rettinger Subject: Re: amcheck failing when checking multiple clients Here are some potentially relevant lines form the log: Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: conn_read_callback 1 3 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: tcpm_recv_token: read 47 bytes from 1 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: conn_read_callback: tcpm_recv_token returned 47 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: stream_read_callback: handle 1 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: stream_read_callback: it was for us Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: stream_read_callback: read 47 bytes from scriptor:1 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: recvpkt_callback: 47 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: cancelling recvpkt for scriptor Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: conn_read_cancel: decremented ev_read_refcnt to 0 for scriptor Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: conn_read_cancel: releasing event handler for scriptor Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: parse_pkt: parsing buffer of 47 bytes Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: parse_pkt: REP (1): "OPTIONS features=9efefbff3f; " Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: received REP packet (1) from scriptor, contains: "OPTIONS features=9efefbff3f; " Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: stream_sendpkt: enter Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: stream_sendpkt: ACK (3) pkt_t (len 0) contains: "" Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: stream_write: writing 2 bytes to scriptor:1 3 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: tcpm_send_token: write 2 bytes to handle 1 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: security_getdriver(name=bsdtcp) returns 0x7ffbb3e53100 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: bsdtcp: bsdtcp_connect: scriptor Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: security_handleinit(handle=0x55f48f9d63d0, driver=0x7ffbb3e53100 (BSDTCP)) Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: security_streaminit(stream=0x55f48fa102d0, driver=0x7ffbb3e53100 (BSDTCP)) Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec_tcp_conn_get: scriptor Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec_tcp_conn_get: exists, refcnt to scriptor is now 3 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: stream_client: connected to stream 13 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: security_close(handle=0x55f48f91e760, driver=0x7ffbb3e53100 (BSDTCP)) Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: closing handle to scriptor Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: cancelling recvpkt for scriptor Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: security_stream_close(0x55f48f9b0e50) Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: tcpma_stream_close: closing stream 1 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: stream_write: writing 0 bytes to scriptor:1 3 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: tcpm_send_token: write 0 bytes to handle 1 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: security_stream_seterr(0x55f48f9b0e50, write error to: Broken pipe) Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec_tcp_conn_put: decrementing refcnt for scriptor to 2 Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: after callback stream_read_callback Wed Jul 27 13:37:41 2016: thd-0x55f48f90bc00: amcheck-clients: sec: conn_read_callback: event_wakeup return 1 On Wed, Jul 27, 2016 at 3:19 PM, Ochressandro Rettinger wrote: > Does the amcheck.XXX.debug or amcheck-device.XXX.debug file have > anything useful in it? > > -Sandro > > -Original Message- > From: owner-amanda-us...@amanda.org > [mailto:owner-amanda-us...@amanda.org] On Behalf Of Chris Nighswonger > Sent: Wednesday, July 27, 2016 12:20 PM > To: amanda-users@amanda.org > Subject: Re: amcheck failing when checkin
RE: amcheck failing when checking multiple clients
Does the amcheck.XXX.debug or amcheck-device.XXX.debug file have anything useful in it? -Sandro -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On Behalf Of Chris Nighswonger Sent: Wednesday, July 27, 2016 12:20 PM To: amanda-users@amanda.org Subject: Re: amcheck failing when checking multiple clients No takers? Additionally, on the failing client side an amcheck log is created *only* if amcheck is run against that client. When amcheck is run against the entire job (all clients) no amcheck log is created on the clients that fail. On Tue, Jul 26, 2016 at 9:09 AM, Chris Nighswonger wrote: > tcpdump shows that there is no (zero) data flow between the server and > failed clients when running amcheck on multiple clients at once. Data > does flow when checking a single client. > > This only started about a month ago. Maybe this is a bug? > > On Mon, Jul 25, 2016 at 4:16 PM, Chris Nighswonger > wrote: >> Here is some snips of output illustrating the problem: >> >> >> backup@scriptor: amcheck -c campus scriptor >> >> Amanda Backup Client Hosts Check >> >> Client check: 1 host checked in 2.372 seconds. 0 problems found. >> >> (brought to you by Amanda 3.3.6) >> backup@scriptor: amcheck -c campus masada >> >> Amanda Backup Client Hosts Check >> >> Client check: 1 host checked in 2.074 seconds. 0 problems found. >> >> (brought to you by Amanda 3.3.6) >> backup@scriptor: amcheck -c campus >> >> Amanda Backup Client Hosts Check >> >> WARNING: scriptor: selfcheck request failed: error sending REQ: write >> error to: Broken pipe >> WARNING: masada: selfcheck request failed: error sending REQ: write >> error to: Broken pipe >> >> >> Server version is 3.3.6 >> Client version on scriptor is 3.3.6 and on masada is 3.3.3 >> >> When the backup runs over night, the same error appears on these clients. >> >> Any thoughts on what might be going on here? >> >> Kind regards, >> Chris
RE: chg-disk / chg-rait problems
I tried modifying the taperscan algorithm. That didn't work.
I tried creating a second vtape library, with 7 slots, to test
the use case where there were two changers with different numbers of slots. In
a chg-rait setup with two chg-disk changers, the slots would properly cycle,
although if I messed with the position of the 'data' link, amcheck wouldn't
cycle through tapes to find ones that matches, and then cycle forward from
there.
Amcheck and or the taperscan algorithm seems to find mismatched
tapes really bothersome.
But short of manually controlling the slot assembly for Amanda,
I don't see a way to get this to work. Has anyone ever successfully gotten a
vtape changer to work with a single tape drive in a RAIT configuration?
-Sandro
From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On
Behalf Of Ochressandro Rettinger
Sent: Thursday, July 21, 2016 2:50 PM
To: amanda-users@amanda.org
Subject: chg-disk / chg-rait problems
Hello. I'm having difficulties with my Amanda setup. I have tried to
configure a RAIT device which is comprised of a 4 slot vtape chg-disk device,
and a 1 slot chg-single tape drive. What is happening is that when I have just
the chg-disk vtape changer activated, it works fine, and cycles through the
slots in the vtape directory. But when I transition to the chg-rait device, it
stops moving through the slots in the vtape directory. Looking at the files in
/var/log/amanda/server/NMHPVPR/amcheck-device.XXX.debug, when I change the
configuration, it appears that Amanda::Taper::Scan::traditional doesn't get
called as many times in the chg-rait mode as in the plain chg-disk mode.
There's also a line in the debug file about "Device is in variable block size"
My amanda.conf below:
org "NMHPVPR"
infofile "/backup/state/curinfo"
logdir "/backup/state/log"
indexdir "/backup/state/index"
dumpuser "amandabackup"
labelstr "NMHPVPR[0-9][0-9][0-9][0-9]"
autolabel "NMHPVPR" EMPTY VOLUME_ERROR
tapecycle 4
dumpcycle 3 days
#amrecover_changer "tape_drive"
#tapetype "LTO4"
#define tapetype LTO4 {
# comment "Dell LTO4 800Gb - Compression Off"
# length 802816 mbytes
# filemark 0 kbytes
# speed 52616 kps
#}
tapetype "VTAPE"
define tapetype VTAPE {
length 200 gbytes
filemark 4 kbytes
}
define changer "vtape_chg" {
tpchanger "chg-disk:/backup/vtapes"
}
define changer "tape_drive" {
tpchanger "chg-single:tape:/dev/nst0"
device-property "BLOCK_SIZE" "2 mbytes"
}
#tpchanger "chg-rait:{vtape_chg,tape_drive}"
tpchanger "vtape_chg"
#tpchanger "tape_drive"
#tpchanger "chg-rait:{chg-disk:/backup/vtapes,chg-single:tape:/dev/nst0}"
define dumptype simple-gnutar-ssh-full {
auth "ssh"
ssh_keys "/var/lib/amanda/.ssh/id_rsa_amdump"
compress none
dumpcycle 0
program "GNUTAR"
}
define dumptype simple-gnutar-ssh {
auth "ssh"
ssh_keys "/var/lib/amanda/.ssh/id_rsa_amdump"
compress none
program "GNUTAR"
}
define dumptype simple-gnutar-local {
auth "local"
compress none
program "GNUTAR"
}
holdingdisk hd1 {
directory "/holding"
use 383 gbytes
chunksize 2 mbytes
}
-
And the amcheck-device.XXX.debug file for a chg-rait run. Slot should have
advanced to {3,1} when amcheck was called.
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: pid 14247 ruid 9000
euid 9000 version 3.3.9: start at Thu Jul 21 14:05:40 2016
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: pid 14247 ruid 9000
euid 9000 version 3.3.9: rename at Thu Jul 21 14:05:40 2016
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: chg-disk: Dir
/backup/vtapes
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: chg-disk: Using
statefile '/backup/vtapes/state'
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional stage 1: search for oldest reusable volume
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional oldest reusable volume is 'NMHPVPR0001'
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional changer is not fast-searchable; skipping to
stage 2
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional stage 2: scan for any reusable volume
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: Device is in variable
block size
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: called _set_current
with slot 2
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck
RE: tapes and external disks: how to combine all this
On the subject of changing the taperscan, how do you do that? I tried seeing if that would have an effect on my chg-rait problem by adding the line taperscan oldest to my amanda.conf, but when I ran amcheck afterwards, Amanda complained: amcheck: "/etc/amanda/NMHPVPR/amanda.conf", line 11: Unknown taperscan named: oldest but I couldn't find any documentation that explicitly said how to change the taperscan algorithm. -Sandro -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On Behalf Of Stefan G. Weichinger Sent: Friday, July 22, 2016 4:52 AM To: Jean-Louis Martineau ; amanda-users@amanda.org Subject: Re: tapes and external disks: how to combine all this Am 2016-07-20 um 19:09 schrieb Jean-Louis Martineau: > May I suggest: autolabel "$m-$3s" any > > Install the new aggregate.pm and apply the Changer.diff to the > Changer.pm file. > > Your problem is because the 'traditional' taperscan fail when it try > to load the current slot. > The workaround is to use the 'oldest' or 'lexical' taperscan. > > The meta label for a disk should never change (unless the state file > is removed), there is a bug somewhere if it happen again. > Jean-Louis, what are your further plans with this? Will you add the mentioned property? Will it get into amanda-3.3.10? Should I write a small howto for the wiki or so?
chg-disk / chg-rait problems
Hello. I'm having difficulties with my Amanda setup. I have tried to
configure a RAIT device which is comprised of a 4 slot vtape chg-disk device,
and a 1 slot chg-single tape drive. What is happening is that when I have just
the chg-disk vtape changer activated, it works fine, and cycles through the
slots in the vtape directory. But when I transition to the chg-rait device, it
stops moving through the slots in the vtape directory. Looking at the files in
/var/log/amanda/server/NMHPVPR/amcheck-device.XXX.debug, when I change the
configuration, it appears that Amanda::Taper::Scan::traditional doesn't get
called as many times in the chg-rait mode as in the plain chg-disk mode.
There's also a line in the debug file about "Device is in variable block size"
My amanda.conf below:
org "NMHPVPR"
infofile "/backup/state/curinfo"
logdir "/backup/state/log"
indexdir "/backup/state/index"
dumpuser "amandabackup"
labelstr "NMHPVPR[0-9][0-9][0-9][0-9]"
autolabel "NMHPVPR" EMPTY VOLUME_ERROR
tapecycle 4
dumpcycle 3 days
#amrecover_changer "tape_drive"
#tapetype "LTO4"
#define tapetype LTO4 {
# comment "Dell LTO4 800Gb - Compression Off"
# length 802816 mbytes
# filemark 0 kbytes
# speed 52616 kps
#}
tapetype "VTAPE"
define tapetype VTAPE {
length 200 gbytes
filemark 4 kbytes
}
define changer "vtape_chg" {
tpchanger "chg-disk:/backup/vtapes"
}
define changer "tape_drive" {
tpchanger "chg-single:tape:/dev/nst0"
device-property "BLOCK_SIZE" "2 mbytes"
}
#tpchanger "chg-rait:{vtape_chg,tape_drive}"
tpchanger "vtape_chg"
#tpchanger "tape_drive"
#tpchanger "chg-rait:{chg-disk:/backup/vtapes,chg-single:tape:/dev/nst0}"
define dumptype simple-gnutar-ssh-full {
auth "ssh"
ssh_keys "/var/lib/amanda/.ssh/id_rsa_amdump"
compress none
dumpcycle 0
program "GNUTAR"
}
define dumptype simple-gnutar-ssh {
auth "ssh"
ssh_keys "/var/lib/amanda/.ssh/id_rsa_amdump"
compress none
program "GNUTAR"
}
define dumptype simple-gnutar-local {
auth "local"
compress none
program "GNUTAR"
}
holdingdisk hd1 {
directory "/holding"
use 383 gbytes
chunksize 2 mbytes
}
-
And the amcheck-device.XXX.debug file for a chg-rait run. Slot should have
advanced to {3,1} when amcheck was called.
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: pid 14247 ruid 9000
euid 9000 version 3.3.9: start at Thu Jul 21 14:05:40 2016
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: pid 14247 ruid 9000
euid 9000 version 3.3.9: rename at Thu Jul 21 14:05:40 2016
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: chg-disk: Dir
/backup/vtapes
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: chg-disk: Using
statefile '/backup/vtapes/state'
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional stage 1: search for oldest reusable volume
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional oldest reusable volume is 'NMHPVPR0001'
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional changer is not fast-searchable; skipping to
stage 2
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional stage 2: scan for any reusable volume
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: Device is in variable
block size
Thu Jul 21 14:05:40 2016: thd-0x15a3bb0: amcheck-device: called _set_current
with slot 2
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: warning: Inconsistent
volume labels/datestamps: Got NMHPVPR0014/20160721132422 on
file:/backup/vtapes/drive0 against NMHPVPR0009/20160720130714 on tape:/dev/nst0.
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: Device
rait:{file:/backup/vtapes/drive0,tape:/dev/nst0} error = 'Inconsistent volume
labels/datestamps: Got NMHPVPR0014/20160721132422 on file:/backup/vtapes/drive0
against NMHPVPR0009/20160720130714 on tape:/dev/nst0.'
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: Device
rait:{file:/backup/vtapes/drive0,tape:/dev/nst0} setting status flag(s):
DEVICE_STATUS_VOLUME_ERROR
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device:
Amanda::Taper::Scan::traditional result: 'NMHPVPR0015' on
rait:{file:/backup/vtapes/drive0,tape:/dev/nst0} slot {2,1}, mode 2
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: ru_utime : 0
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: ru_stime : 0
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: ru_maxrss : 22532
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: ru_ixrss : 0
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: ru_idrss : 0
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: ru_isrss : 0
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: ru_minflt : 6780
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device: ru_majflt : 0
Thu Jul 21 14:05:41 2016: thd-0x15a3bb0: amcheck-device
