Re: Amrecover fails when using tape spanning: Unexpected EOF in archive
Hi, I checked the logs. There is no error message, and I have no cron running either. I can duplicate the problem every time. Interestingly, the amrecover says that it will need two tapes. When I put the first tape in, it reads it for a long time, gets the error I noted below, and then just gives up on asking for the second tape. Any other ideas? Thanks, David From: Ian Turner <[EMAIL PROTECTED]> To: "David Trusty" <[EMAIL PROTECTED]> CC: amanda-users@amanda.org Subject: Re: Amrecover fails when using tape spanning: Unexpected EOF in archive Date: Mon, 25 Sep 2006 14:27:19 -0400 The "device or resource busy" message comes from your operating system. Normally this error means that two programs tried to access the tape device simultaneously. I suspect one of the following: 1) A hardware problem or kernel bug. Check your kernel debug logs. 2) A cron job that accesses the tape. Check your cron log. --Ian On Friday 22 September 2006 19:21, David Trusty wrote: > Hi, > > I am trying to restore a file which is on a backup > which used tape spanning. I am running version 2.5.1. > > The backup says it completed successfully, but I get > the errors below from amrecover and imidxtaped. > > Any ideas? > > Thanks!! > > David > > amrecover output > > Looking for tape 104... > tar: Read 8192 bytes from - > tar: Unexpected EOF in archive > tar: Error is not recoverable: exiting now > Extractor child exited with status 2 > > > debug log for amidxtaped > ~~~ > midxtaped: 46: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 46/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 47: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 47/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 48: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 48/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 49: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 49/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 50: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 50/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 51: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 51/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: restore read error: Device or resource busy > amidxtaped: time 2988.892: restore read error: Device or resource busy > amidxtaped: time 2988.892: pid 18574 finish time Fri Sep 22 11:29:43 2006 -- Zmanda: Open Source Data Protection and Archiving. http://www.zmanda.com
Re: Amrecover fails when using tape spanning: Unexpected EOF in archive
The "device or resource busy" message comes from your operating system. Normally this error means that two programs tried to access the tape device simultaneously. I suspect one of the following: 1) A hardware problem or kernel bug. Check your kernel debug logs. 2) A cron job that accesses the tape. Check your cron log. --Ian On Friday 22 September 2006 19:21, David Trusty wrote: > Hi, > > I am trying to restore a file which is on a backup > which used tape spanning. I am running version 2.5.1. > > The backup says it completed successfully, but I get > the errors below from amrecover and imidxtaped. > > Any ideas? > > Thanks!! > > David > > amrecover output > > Looking for tape 104... > tar: Read 8192 bytes from - > tar: Unexpected EOF in archive > tar: Error is not recoverable: exiting now > Extractor child exited with status 2 > > > debug log for amidxtaped > ~~~ > midxtaped: 46: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 46/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 47: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 47/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 48: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 48/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 49: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 49/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 50: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 50/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: 51: restoring split dumpfile: date 20060920 host helix disk > /mnt/dataa/invention part 51/UNKNOWN lev 0 comp N program /bin/tar > amidxtaped: restore read error: Device or resource busy > amidxtaped: time 2988.892: restore read error: Device or resource busy > amidxtaped: time 2988.892: pid 18574 finish time Fri Sep 22 11:29:43 2006 -- Zmanda: Open Source Data Protection and Archiving. http://www.zmanda.com
Re: How to use 2 tape drives for backup with amanda?
On Monday 25 September 2006 00:42, Jon LaBadie wrote: > On Sun, Sep 24, 2006 at 08:38:39PM +0200, Dominik Schips wrote: > > # Config for OVERLAND PowerLoader Tape Autoloader > > tpchanger "chg-zd-mtx" # the tape-changer glue script, see TAPE.CHANGERS > > changerdev "/dev/sg2" # tape-changer device > > changerfile "/etc/amanda/DailyFull/CHANGER" > Two things. > > You say your changer is /dev/sg3 but your conf file says sg2. Ups, I used the old amanda.conf and did a cut&past. In this config I had only one device. I changed this in my actual config. > Also, nowhere in the conf files is a tape device defined. Sorry. I did the cut&past a few lines to early. I have this line in the amanda.conf: # Tape device tapedev "/dev/nst0" > As to using multiple drives, amanda is not designed to do that. This is what I want to know. Thank you for this information and your fast reply > Ways amanda users do use multiple drives include: > > chg-multi which treats two (or more) drives as if they were > a tape changer with a single drive > > set up multiple configs, each backing up a different set of > hosts. assign a separate group of slots and 1 drive to each > config I have to think about that if it make sense for my backup. > use the drives as a RAIT, either mirroring the data or > striping the data across the two drives I think I won't do this at the moment. Maybe in a later stat of the backup concept. Best regards Dominik
Re: error
Reinhart Viane wrote: I have done a shutdown -r now Friday. It does not seem to resolve the issue. Could this mean the tape drive is broke? If you have cleaned the drive and you still get the same error, that might indeed mean that your drive is broken. But I recommended that you power-cycle the drive in order to reset it. Also, please do check the drive using tar and dd, by writing to a scratch tape. Just tar up a large directory directly to the tape drive, as in tar cvf /dev/nst0 my/large/directory Do you get an error after a few hundreds of MB just like amanda reports? In that case the error is definitely not with amanda but with your drive somewhere. From your syslog I gather that you are using ide-tape, which I don't know at all. You might want to redirect your problems to a more relevant list for that specific drive unless someone else chimes in. Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29
Re: How can I rename existing config from DailySet1 to daily?
On 9/24/06, Jon LaBadie <[EMAIL PROTECTED]> wrote: On Sun, Sep 24, 2006 at 06:38:17PM -0600, Donald Murray, P.Eng. wrote: > I've been running 2.4.4p4 for some time now on a Fedora Core 1 box. > I'm going to reinstall, this time using CentOS 4. I've backed up all > the goodies I'll need: > - /etc/amanda > - /var/lib/amanda > > I've also done an 'amadmin DailySet1 export > DailySet1.export'. > > I've downloaded the 2.5.1-1 src RPM, hacked it for my needs (home > network), and built some shiny new binary RPMs. One of the things I > did to amanda.spec was added '--with-config=daily' to the configure > section. > > So far, so good. > > Here's what I'd like to be able to do: > - install my amanda RPMs on a fresh install of CentOS 4 > - configure 'daily' with settings similar to those I had in 'DailySet1' > - run amanda daily using ... 'daily' > - still be able to access backups made under the 'DailySet1' regime > One thought. 2.5.1 has some new features, uses some different config setup, and perhaps some differences in the format of its stored data. (not the backups, amanda's data) That said, I don't know if 2.4.4 exported information can be imported into a 2.5.1 server. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax) I've already confirmed that I can 'amadmin DailySet1 export > foo' on Fedora Core 1 and then import on CentOS 4. The only downside to this approach: DailySet1 is the config on the new install. I'm starting to think I might have to create two configs for the new install: - DailySet1 in case I need to recover from the Fedora Core 1 backups - daily for CentOS backups
Re: Just installed 2.5.1 - ufsdump error
Christopher Davis wrote: > I just installed 2.5.1 as a new - clean install. > > > Amanda backups up the linux server that is the backup server with no > problems. > > I added in a solaris 8 box but get the following errors now for every Solaris > DLE > > > server/home1 lev 0 FAILED [/usr/sbin/ufsdump returned 3] [cut] It's a known bug on 2.5.1, please search on the archives. Or just get the latest snapshot here : http://www.iro.umontreal.ca/~martinea/amanda/amanda-2.5.1-20060923.tar.gz Regards, -- Fabio Corazza - Engineering NewBay Software, Ltd. Wilson House, Fenian Street, Dublin 2, Ireland Phone: +353 1 634 5490 - e-mail: [EMAIL PROTECTED]
Just installed 2.5.1 - ufsdump error
I just installed 2.5.1 as a new - clean install.
Amanda backups up the linux server that is the backup server with no
problems.
I added in a solaris 8 box but get the following errors now for every Solaris
DLE
server/home1 lev 0 FAILED [/usr/sbin/ufsdump returned 3]
FAILED AND STRANGE DUMP DETAILS:
/-- server /home1 lev 0 FAILED [/usr/sbin/ufsdump returned 3]
sendbackup: start [server:/home1 level 0]
sendbackup: info BACKUP=/usr/sbin/ufsdump
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/usr/sbin/ufsrestore -f - ...
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| DUMP: Density must be a positive integer
| DUMP: The ENTIRE dump is aborted.
sendbackup: error [/usr/sbin/ufsdump returned 3]
\
I look in the files on the client I see this in the sendbackup log:
sendbackup: debug 1 pid 6647 ruid 65000 euid 65000: rename at Sat Sep 23
03:50:05 2006
sendbackup req:
parsed request as: program `DUMP'
disk `/home1'
device `/home1'
level 0
since 1970:1:1:0:0:0
options `|;auth=BSD;compress-fast;index;'
sendbackup: start: server:/home1 lev 0
sendbackup: time 0.048: spawning /usr/bin/gzip in pipeline
sendbackup: argument list: /usr/bin/gzip --fast
sendbackup-dump: time 0.049: pid 6649: /usr/bin/gzip --fast
sendbackup: time 0.052: dumping device '/dev/rdsk/c1t1d0s7' with 'ufs'
sendbackup: time 0.053: spawning /usr/sbin/ufsdump in pipeline
sendbackup: argument list: /usr/sbin/ufsdump dump 0usf 1048576 -
/dev/rdsk/c1t1d0s7
sendbackup: time 0.055: started backup
sendbackup: time 0.056: started index creator: "/usr/sbin/ufsrestore -tvf -
2>&1 | sed -e '
s/^leaf[]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
sendbackup: time 0.066: 87: normal(|): DUMP: Density must be a positive
integer
sendbackup: time 0.069: 87: normal(|): DUMP: The ENTIRE dump is aborted.
sendbackup: time 0.164: index created successfully
sendbackup: time 0.167: error [/usr/sbin/ufsdump returned 3]
sendbackup: time 0.167: pid 6647 finish time Sat Sep 23 03:50:05 2006
The line that jumps out at me is this:
/usr/sbin/ufsdump dump 0usf 1048576 - /dev/rdsk/c1t1d0s7
This ins't a valid command - the word 'dump' is being interpreted as options
to ufsdump and as far as I can tell shouldn't be there - so where did that
come from and where can I get rid of it?
Chris
Re: amrestore with tar empty directories at mountpoints
Jon LaBadie wrote: On Sun, Sep 24, 2006 at 02:23:56PM -0400, Nick Brockner wrote: Hi All. I am new to amanda, and maybe I just don't understand how it works, but here is my problem: I have a remote machine that I back up over my network. The backups and everything go fine. I am doing a disaster recovery test today, and it went all wrong. Very, very wrong. I have a DLE in disklists for "/" of this remote host. The problem is that on this host, I have several different partitions mounted at /usr, /var/ /home, . . . you get the idea, and when the backup of the "/" DLE happenes, empty directories are created for all the mountpoints! (I am using GNUTAR). So, when I tried to do a bare-metal restore, it clobbered my base install by overwriting all the mountpoints with empty directories, and I couldn't restore the rest of the partitions because the base install was hosed. Can anyone help me / tell me what to do in order to get tar not to create these empty directories at the other mountpoints? When I think of bare-metal restoration, I think of going to an empty, probably partitioned and formatted drive. In that case, restoring the root DLE followed by the /usr, /var, ... DLEs would achieve what you seek. When the backup of your root DLE was made, /usr, as a mountpoint, was an empty directory in the root file system. So that is what was restored. amrecover restores to the state as of a particular time/date. If I ask to recover a single directory from a week ago, and I do the recovery into the original directory, any files created during the week are deleted because it is restoring the state of the directory to that of a week ago. Same with ownership and permission changes I might have made during the week. For this reason it is oft said here, do not do amrecover into the original location, but instead into an empty directory. Then check the files and move/copy to the ultimate location. I don't know if you had used exclude directives to eliminate the mountpoints from the root DLE would have changed anything. Perhaps if they were not even included in the backup, they might be totally eliminated upon recovery rather than left as empty directories. I just don't know. Jon, Thanks. I now realize I was going about the restore all wrong. In the end, working down from the top-level directory and then restoring all mountpoints below worked perfectly. I guess I was expecting a dump/restore type of restoration, where the mountpoints wouldn't show up as empty dirs and therefore would not be overwritten during the actual restoration. I had done a bare minimal install before doing the restore of the filesystems so that the MBR was happy. Amanda rocks. Thanks again, Nick Brockner
RE: error
Hey again Alex, I have done a shutdown -r now Friday. It does not seem to resolve the issue. Could this mean the tape drive is broke? Greetings -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Alexander Jolk Verzonden: vrijdag 22 september 2006 15:31 Aan: Reinhart Viane CC: amanda-users@amanda.org Onderwerp: Re: error Reinhart Viane wrote: > In addition: the syslog (/var/log/messages) > > --Executing yesterdays tape backup-- > Sep 21 20:00:00 daeserver su(pam_unix)[7303]: session opened for user amanda > by (uid=0) > Sep 21 20:14:19 daeserver kernel: ide-tape: ht0: I/O error, pc = a, key = > 3, asc = 52, ascq = 0 > Sep 21 20:14:20 daeserver last message repeated 79 times > Sep 21 20:14:20 daeserver kernel: ide-tape: ht0: I/O error, pc = 10, key = > 3, asc = 52, ascq = 0 > Sep 21 20:14:20 daeserver kernel: ide-tape: Couldn't write a filemark > Sep 21 20:14:20 daeserver kernel: ide-tape: ht0: I/O error, pc = 10, key = > 3, asc = 52, ascq = 0 > Sep 21 20:14:20 daeserver kernel: ide-tape: ht0: I/O error, pc = 10, key = > 3, asc = 52, ascq = 0 Please check whether your tape drive works with standard utilities (tar, dd, mt). Something seems to be seriously hosed. Have you already hard-reset everything, by power-cycling? Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29
