amrecover error
hello When running the command below on client server I get the following error - details are : - terrabkup# amrecover -C fullbkup -s sa01.terra.terrasky.mu -t sa01.terra.terrasky.mu -d /dev/nst0 AMRECOVER Version 2.4.3. Contacting server on sa01.terra.terrasky.mu ... amrecover: Unexpected end of file, check amindexd*debug on server sa01.terra.terrasky.mu Contents of amindexd.20040226113359.debug on backup server [EMAIL PROTECTED] amanda]$ more amindexd.20040226113359.debug amindexd: debug 1 pid 30290 ruid 512 euid 512: start at Thu Feb 26 11:33:59 2004 amindexd: version 2.4.3 amindexd: time 0.002: gethostbyaddr(10.10.20.40): hostname lookup failed amindexd: time 0.002: pid 30290 finish time Thu Feb 26 11:33:59 2004 On the client server terrabkup# more amrecover.20040226114140.debug amrecover: debug 1 pid 48907 ruid 0 euid 0: start at Thu Feb 26 11:41:40 2004 amrecover: stream_client_privileged: connected to 10.10.20.32.10082 amrecover: stream_client_privileged: our side is 0.0.0.0.575 hostname are currently being resolved by dns server. The backup was done when /etc/hosts was still being used. I'll be grateful for any help obtained to resolve this problem. regds M
Re: Can't for the life of me figure out why it won't flush ....
Geoff Swavley wrote: > NOTES: > driver: WARNING: /holding2/schedule4: 52428800 KB requested, but only 37434075 > KB available. > taper: tape schedule4-JAN-2004 kb 1053504 fm 1 writing file: I/O error I once had this and finally found out the I/O error was on my holding disk. You might just want to check you can read all of the files in your holding area without problems. Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29
Re: amrecover error
Hi, Madhvi Gokool schrieb: hello When running the command below on client server I get the following error - details are : - terrabkup# amrecover -C fullbkup -s sa01.terra.terrasky.mu -t sa01.terra.terrasky.mu -d /dev/nst0 AMRECOVER Version 2.4.3. Contacting server on sa01.terra.terrasky.mu ... amrecover: Unexpected end of file, check amindexd*debug on server sa01.terra.terrasky.mu Contents of amindexd.20040226113359.debug on backup server [EMAIL PROTECTED] amanda]$ more amindexd.20040226113359.debug amindexd: debug 1 pid 30290 ruid 512 euid 512: start at Thu Feb 26 11:33:59 2004 amindexd: version 2.4.3 amindexd: time 0.002: gethostbyaddr(10.10.20.40): hostname lookup failed ^^^ and this is your problem: your backupserver can not reverse-lookup your client. it took the ip-adress and asked your nameserver for the name of your client host and got a bad answer back. Fix the reverse-mapping of your client ip-adress and amrecover will be much happier. Christoph
Re: Can't get good backups, where might this timeout be?
On Thu, 26 Feb 2004 at 8:09am, stan wrote > Here's the scenario. I have an existing Amanda installation that was > working well. I added several disk partitons to the backup set. These > partions are on the dumphost. Tey also are big enough that they have to be > broken up into smaller chunks to fit on the tape. You say this, and yet you are using device names in the disklist, so I don't get it. And amanda doesn't complain, so *are* those partitions bigger than a tape? > Since then, I have not gotten a good backup of thes 2 machines in question > (teddy and smokey). Bith report "data timeout" See the report below: I'd look in the system logs for disk related errors. You also may want to try using directory names in the disklist. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: selfcheck request timed out error
This is a tuff one. I really can't figure out what is going on.
Joshua Baker-LePain wrote:
On Wed, 25 Feb 2004 at 3:06pm, jlm17 wrote
I commented out the only_from line from all three amanda services but it
does not work.
The other thing to check is /etc/hosts.{allow,deny}. I don't know Gentoo,
but on RedHat xinetd uses them. Accepts or denies based on those files
should be logged in /var/log/secure.
I didn't have either a /etc/hosts.allow or /etc/hosts.deny. I created an
/etc/hosts.allow with the one line: ALL: LOCAL No change in behavior.
Note that I do not get any lines about removing amanda services.
Yes, but...
If you're not getting anything in /tmp/amanda, then amandad isn't even
starting up. Is ipchains/iptables getting in the way? What's the output
of 'netstat -ln | grep 10080'?
netstat -ln | grep 10080
udp0 0 0.0.0.0:10080 0.0.0.0:*
That means amanda is listening, so that part of xinetd is working right.
As far as I know I do not have any iptables stuff turned on. I don't
even have the iptables userland tools installed. I have turned it on in
the kernel, though.
iptables looks empty:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
You can check what rules are set up with 'iptables -nL'. I'd say the next
thing to do would be to look at the traffic. Do 'tcpdump -i lo' and then
run amcheck and see what happens.
tcpdump gives me this:
tcpdump -vv -i lo
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 68 bytes
10:08:27.706802 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda:
UDP, length: 117
10:08:37.704970 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda:
UDP, length: 117
10:08:47.706323 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda:
UDP, length: 117
Additionally I figured out that xinetd logs some stuff in /var/log/auth.log:
Feb 26 10:08:27 royal xinetd[5766]: START: amanda pid=5941
from=152.148.113.221
Feb 26 10:08:27 royal xinetd[5941]: FAIL: amanda address
from=152.148.113.221
Feb 26 10:08:37 royal xinetd[5766]: START: amanda pid=5942
from=152.148.113.221
Feb 26 10:08:37 royal xinetd[5942]: FAIL: amanda address
from=152.148.113.221
Feb 26 10:08:47 royal xinetd[5766]: START: amanda pid=5943
from=152.148.113.221
Feb 26 10:08:47 royal xinetd[5943]: FAIL: amanda address
from=152.148.113.221
Still not very useful though. I have changed the amandad config in xinetd:
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= amanda
group = amanda
groups = yes
server = /usr/libexec/amandad
# You need to ensure this points to your Amanda server!
# Don't just remove it!
only_from = royal
disable = no
}
so that wait = no. That just made things worse. Running amandad by hand
seems to do the right thing:
sudo -u amanda /usr/libexec/amandad
amandad: error receiving message: timeout
The next thing I will be trying is to run strace on xinetd and see if I
can glean any information that way.
Thanks again for all of your help.
Re: ? amrecover to dir other than CWD
Thanks Allen Liu - Original Message - From: "Christoph Scheeder" <[EMAIL PROTECTED]> To: "Allen Liu --- work" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, February 26, 2004 2:51 AM Subject: Re: ? amrecover to dir other than CWD > Hi, > if you want to restore in the original place, then, more or less, yes. > You'll have to cwd to the dir specified in the disklist as startingpoint > of the backup. From there on pathes are restored. > But beware if there are files newer then the Backup you are restoring, > they will be deleted without prompting, as amnda restores the contents > of the dir's as they where at the backup. > Most of us prefer to restore to a scratch are and then move the wanted > files to the real destination for security reasons. > Christoph > > Allen Liu --- work schrieb: > > > I am testing amrecover. > > In its prompt, I can't find how to specify restore destination directory. It > > looks it always try to recover to CWD, is it true ? > > Do I have to lcd to the destination dir and extract it ? > > > > Thanks > > > > Allen Liu > > > > IP Application Design and Engineering > > Bell Canada > > (613) 781-7368, [EMAIL PROTECTED] > > 1240 -160 Elgin St, Ottawa,ON, K2P 2C4 > > > >
Re: selfcheck request timed out error
On Thu, 26 Feb 2004 at 10:16am, jlm17 wrote > tcpdump gives me this: > tcpdump -vv -i lo > tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 68 bytes > 10:08:27.706802 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda: > UDP, length: 117 > 10:08:37.704970 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda: > UDP, length: 117 > 10:08:47.706323 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda: > UDP, length: 117 Those are the packets from amcheck. As you can see, there's no reply. amandad isn't getting started. > Additionally I figured out that xinetd logs some stuff in /var/log/auth.log: > > Feb 26 10:08:27 royal xinetd[5766]: START: amanda pid=5941 > from=152.148.113.221 > Feb 26 10:08:27 royal xinetd[5941]: FAIL: amanda address > from=152.148.113.221 > > Still not very useful though. I have changed the amandad config in xinetd: Actually, that is pretty useful. From 'man xinetd.log': A FAIL entry has the format: FAIL: service-id reason [from=%d.%d.%d.%d] Possible reasons are: . . addressthe address check failed I'd guess that reverse lookups aren't working? Are you sure you restarted xinetd after removing the 'only_from' directive? Because that address check is your problem. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Problems with amrecover
On Thu, 26 Feb 2004 at 6:02pm, Thomas Jones wrote > [EMAIL PROTECTED] _root]# pwd > /var/lib/amanda/full/index/omega/_root > [EMAIL PROTECTED] _root]# ls > 20040212_1.gz 20040215_2.gz 20040218_1.gz 20040221_0.gz 20040224_1.gz > 20040213_0.gz 20040216_0.gz 20040219_0.gz 20040222_1.gz 20040225_1.gz > 20040214_1.gz 20040217_1.gz 20040220_1.gz 20040223_0.gz 20040226_0.gz What do the contents of the index files look like? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: selfcheck request timed out error
Thanks for the help. Turns out it was xinetd. There was an only_from in both /etc/xinetd.conf and in /etc/xinetd.d/amanda. By commenting out all of those amcheck returned with no errors. Joshua Baker-LePain wrote: On Thu, 26 Feb 2004 at 10:16am, jlm17 wrote tcpdump gives me this: tcpdump -vv -i lo tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 68 bytes 10:08:27.706802 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda: UDP, length: 117 10:08:37.704970 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda: UDP, length: 117 10:08:47.706323 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 145) royal.inse.lucent.com.798 > royal.inse.lucent.com.amanda: UDP, length: 117 Those are the packets from amcheck. As you can see, there's no reply. amandad isn't getting started. Additionally I figured out that xinetd logs some stuff in /var/log/auth.log: Feb 26 10:08:27 royal xinetd[5766]: START: amanda pid=5941 from=152.148.113.221 Feb 26 10:08:27 royal xinetd[5941]: FAIL: amanda address from=152.148.113.221 Still not very useful though. I have changed the amandad config in xinetd: Actually, that is pretty useful. From 'man xinetd.log': A FAIL entry has the format: FAIL: service-id reason [from=%d.%d.%d.%d] Possible reasons are: . . addressthe address check failed I'd guess that reverse lookups aren't working? Are you sure you restarted xinetd after removing the 'only_from' directive? Because that address check is your problem.
Re: Problems with amrecover
Here is an example: [EMAIL PROTECTED] _root]# zmore 20040226_0.gz --> 20040226_0.gz <-- / /.borland/ /.cpan/ /.cpan/Bundle/ /.cpan/build/ /.cpan/build/Algorithm-Cluster-1.24/ /.cpan/build/Algorithm-Cluster-1.24/blib/ /.cpan/build/Algorithm-Cluster-1.24/blib/arch/ /.cpan/build/Algorithm-Cluster-1.24/blib/arch/auto/ /.cpan/build/Algorithm-Cluster-1.24/blib/arch/auto/Algorithm/ /.cpan/build/Algorithm-Cluster-1.24/blib/arch/auto/Algorithm-Cluster/ /.cpan/build/Algorithm-Cluster-1.24/blib/arch/auto/Algorithm/Cluster/ /.cpan/build/Algorithm-Cluster-1.24/blib/lib/ /.cpan/build/Algorithm-Cluster-1.24/blib/lib/Algorithm/ /.cpan/build/Algorithm-Cluster-1.24/blib/lib/auto/ /.cpan/build/Algorithm-Cluster-1.24/blib/lib/auto/Algorithm/ /.cpan/build/Algorithm-Cluster-1.24/blib/lib/auto/Algorithm-Cluster/ /.cpan/build/Algorithm-Cluster-1.24/blib/lib/auto/Algorithm/Cluster/ /.cpan/build/Algorithm-Cluster-1.24/blib/man3/ /.cpan/build/Algorithm-Cluster-1.24/data/ /.cpan/build/Algorithm-Cluster-1.24/perl/ /.cpan/build/Algorithm-Cluster-1.24/perl/examples/ /.cpan/build/Algorithm-Cluster-1.24/perl/t/ /.cpan/build/Algorithm-Cluster-1.24/ranlib/ /.cpan/build/Algorithm-Cluster-1.24/ranlib/linpack/ /.cpan/build/Algorithm-Cluster-1.24/ranlib/src/ /.cpan/build/Algorithm-Cluster-1.24/src/ /.cpan/build/Apache-AuthzPasswd-0.12/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/arch/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/arch/auto/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/arch/auto/Apache/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/arch/auto/Apache/AuthzPasswd/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/lib/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/lib/Apache/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/lib/auto/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/lib/auto/Apache/ /.cpan/build/Apache-AuthzPasswd-0.12/blib/lib/auto/Apache/AuthzPasswd/ [EMAIL PROTECTED] _root]# [EMAIL PROTECTED] _root]# pwd /var/lib/amanda/full/index/omega/_root [EMAIL PROTECTED] _root]# On Thu, 2004-02-26 at 19:31, Joshua Baker-LePain wrote: > On Thu, 26 Feb 2004 at 6:02pm, Thomas Jones wrote > > > [EMAIL PROTECTED] _root]# pwd > > /var/lib/amanda/full/index/omega/_root > > [EMAIL PROTECTED] _root]# ls > > 20040212_1.gz 20040215_2.gz 20040218_1.gz 20040221_0.gz 20040224_1.gz > > 20040213_0.gz 20040216_0.gz 20040219_0.gz 20040222_1.gz 20040225_1.gz > > 20040214_1.gz 20040217_1.gz 20040220_1.gz 20040223_0.gz 20040226_0.gz > > What do the contents of the index files look like?
Problems with amrecover
Hi, Can someone please point me in the right direction, as I can't think what is going wrong I am trying to do a restore using amrecover, but I get the response that the index does not exist: [EMAIL PROTECTED] root]# amrecover -C full AMRECOVER Version 2.4.3. Contacting server on localhost ... 220 omega AMANDA index server (2.4.3) ready. 200 Access OK Setting restore date to today (2004-02-26) 200 Working date set to 2004-02-26. 200 Config set to full. 200 Dump host set to omega. Trying disk / ... Trying disk rootfs ... Can't determine disk and mount point from $CWD '/root' amrecover> sethost omega 200 Dump host set to omega. amrecover> setdisk /root Scanning /d/d1/amanda... 200 Disk set to /root. No index records for disk for specified date If date correct, notify system administrator amrecover> The output of the debug file is: [EMAIL PROTECTED] amanda]# cat amindexd.20040226175730.debug amindexd: debug 1 pid 11904 ruid 33 euid 33: start at Thu Feb 26 17:57:30 2004 amindexd: version 2.4.3 amindexd: time 0.000: < 220 omega AMANDA index server (2.4.3) ready. amindexd: time 0.001: > SECURITY USER root amindexd: time 0.001: bsd security: remote host omega user root local user amanda amindexd: time 0.001: amandahosts security check passed amindexd: time 0.002: < 200 Access OK amindexd: time 0.034: > DATE 2004-02-26 amindexd: time 0.034: < 200 Working date set to 2004-02-26. amindexd: time 0.074: > SCNF full amindexd: time 0.076: < 200 Config set to full. amindexd: time 0.114: > HOST omega amindexd: time 0.114: < 200 Dump host set to omega. amindexd: time 0.154: > DISK / amindexd: time 0.154: < 501 No index records for disk: /. Invalid? amindexd: time 0.194: > DISK rootfs amindexd: time 0.194: < 501 No index records for disk: rootfs. Invalid? amindexd: time 6.054: > HOST omega amindexd: time 6.055: < 200 Dump host set to omega. amindexd: time 10.885: > DISK /root amindexd: time 10.885: < 200 Disk set to /root. amindexd: time 10.925: > OISD / amindexd: time 10.925: < 500 No dumps available on or before date "2004-02-26" amindexd: time 45.037: > QUIT amindexd: time 45.037: < 200 Good bye. amindexd: time 45.037: pid 11904 finish time Thu Feb 26 17:58:15 2004 [EMAIL PROTECTED] amanda]# Here is the list of index files: [EMAIL PROTECTED] _root]# pwd /var/lib/amanda/full/index/omega/_root [EMAIL PROTECTED] _root]# ls 20040212_1.gz 20040215_2.gz 20040218_1.gz 20040221_0.gz 20040224_1.gz 20040213_0.gz 20040216_0.gz 20040219_0.gz 20040222_1.gz 20040225_1.gz 20040214_1.gz 20040217_1.gz 20040220_1.gz 20040223_0.gz 20040226_0.gz [EMAIL PROTECTED] _root]# Thanks
? holding disk contents
Hi all, I ma trying to see what holding disk contents look like. My changer script is chg-manual. The drive didn't have tape in. When I ran amdump, it asked for putting tape in. at this moment I check my holding disk directory, it has timestamp but no contents. Does it suppose to have some data in holding disk ? is this situation so-callled downgrade mode ? Thanks Allen Liu IP Application Design and Engineering Bell Canada (613) 781-7368, [EMAIL PROTECTED] 1240 -160 Elgin St, Ottawa,ON, K2P 2C4
Re: Problem with amrecover and tapeless
Pascal, I recall a similar error when the chg-disk changer wasn't setting the "data" sym-link to the correct "tape" slot. Try using the command: settape chg-disk before doing the extract. It also worked if I manually ran the command: amtape slot in another window before doing the extract. I eventually got the config right in amanda.conf, and it works properly now. Here are my relevant amanda.conf entries: runtapes 1 tpchanger "chg-disk" tapedev "file:/d1/amanda_tapes" rawtapedev "file:/d1/amanda_tapes" changerfile "/usr/local/etc/amanda/daily/changer" changerdev "/dev/null" amrecover_changer "changer" Marc Langlois. On Wed, 2004-02-25 at 08:12, Pascal Robert wrote: > Hi, > > we are doing backups on hard drives, this part works fine, but when I > try to do a recover, I get this error "EOF, check amidxtaped.debug > file". This is a except from my session: > > [EMAIL PROTECTED] /]# /usr/sbin/amrecover -s .xx.cesart.com -t > .xx.cesart.com -C Hosting > AMRECOVER Version 2.4.2p2. Contacting server on .xxx.cesart.com ... > 220 backup AMANDA index server (2.4.4p2) ready. > 200 Access OK > Setting restore date to today (2004-02-25) > 200 Working date set to 2004-02-25. > Scanning /backups/amandadumps/holding... > 200 Config set to Hosting. > 200 Dump host set to xx.cesart.com. > $CWD '/' is on disk '/' mounted at '/'. > 200 Disk set to /. > / > amrecover> cd home/probert > /home/probert > amrecover> add MMI-030922.host-b.gz > Added /home/probert/MMI-030922.host-b.gz > amrecover> list > TAPE Hosting08 LEVEL 2 DATE 2004-02-25 > /home/probert/MMI-030922.host-b.gz > amrecover> settape .xx.cesart.com:file:/backups/amandadumps/tape08 > Using tape file:/backups/amandadumps/tape08 from server > backup.01.cesart.com. > amrecover> extract > > Extracting files using tape drive file:/backups/amandadumps/tape08 on > host backup.01.cesart.com. > The following tapes are needed: Hosting08 > > Restoring files into directory / > Continue? [Y/n]: y > > Load tape Hosting08 now > Continue? [Y/n]: y > EOF, check amidxtaped.debug file on .xx.cesart.com. > > And in the debug file: > > amidxtaped: time 0.000: Ready to execv amrestore with: > path = /usr/local/amanda/sbin/amrestore > argv[0] = "amrestore" > argv[1] = "-h" > argv[2] = "-p" > argv[3] = "file:/backups/amandadumps/tape08" > argv[4] = "x.cesart.com" > argv[5] = "^/$" > argv[6] = "20040225" > amrestore: WARNING: not at start of tape, file numbers will be offset > amrestore: 0: reached end of information > amidxtaped: time 0.002: amrestore terminated normally with status: 1 > amidxtaped: time 0.002: rewinding tape ... > amidxtaped: time 0.002: done > amidxtaped: time 0.002: pid 2491 finish time Wed Feb 25 09:31:20 2004
Can't get good backups, where might this timeout be?
I need some hep figuring out why 2 of my machines sudenly are failing to
backup.
Here's the scenario. I have an existing Amanda installation that was
working well. I added several disk partitons to the backup set. These
partions are on the dumphost. Tey also are big enough that they have to be
broken up into smaller chunks to fit on the tape.
Since then, I have not gotten a good backup of thes 2 machines in question
(teddy and smokey). Bith report "data timeout" See the report below:
These dumps were to tape DailyDump05.
The next tape Amanda expects to use is: DailyDump06.
FAILURE AND STRANGE DUMP SUMMARY:
teddy hda2 lev 0 FAILED [data read: Operation timed out]
smokey hda2 lev 1 FAILED [data read: Operation timed out]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:14
Run Time (hrs:min) 3:39
Dump Time (hrs:min)6:19 6:00 0:19
Output Size (meg) 11340.511064.8 275.7
Original Size (meg) 17396.516187.2 1209.3
Avg Compressed Size (%)65.2 68.4 22.7 (level:#disks ...)
Filesystems Dumped 23 12 11 (1:9 2:1 5:1)
Avg Dump Rate (k/s) 510.9 524.5 250.5
Tape Time (hrs:min)2:16 2:12 0:04
Tape Size (meg) 11340.811065.0 275.8
Tape Used (%) 58.0 56.61.4 (level:#disks ...)
Filesystems Taped23 12 11 (1:9 2:1 5:1)
Avg Tp Write Rate (k/s) 1422.9 1425.9 1310.6
USAGE BY TAPE:
Label Time Size %Nb
DailyDump05 2:16 11340.8 58.023
FAILED AND STRANGE DUMP DETAILS:
/-- teddy hda2 lev 0 FAILED [data read: Operation timed out]
sendbackup: start [teddy:hda2 level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| gtar: ./dev/gpmctl: socket ignored
| gtar: ./dev/lircd: socket ignored
| gtar: ./dev/log: socket ignored
\
/-- smokey hda2 lev 1 FAILED [data read: Operation timed out]
sendbackup: start [smokey:hda2 level 1]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
\
NOTES:
planner: black WAVS-lo 20040226 0 [dumps too big, 1910970 KB, full dump delayed]
planner: black MUSIC-lo 20040226 0 [dumps too big, 2385450 KB, full dump delayed]
planner: black MUSIC-hk 20040226 0 [dumps too big, 3231520 KB, full dump delayed]
planner: black WAVS-oz 20040226 0 [dumps too big, 6139790 KB, full dump delayed]
planner: black WAVS-hk 20040226 0 [dumps too big, 6188260 KB, full dump delayed]
planner: black MUSIC-oz 20040226 0 [dumps too big, 6316650 KB, full dump delayed]
planner: black MUSIC-ag 20040226 0 [dumps too big, 8453050 KB, full dump delayed]
planner: black WAVS-ag 20040226 0 [dumps too big, 10952940 KB, full dump delayed]
planner: black spare-rest 20040226 0 [dumps too big, 7510756 KB, full dump delayed]
planner: smokey hda2 20040226 0 [dumps too big, 7748548 KB, full dump delayed]
planner: yogi hda1 20040226 0 [dumps too big, 15191133 KB, full dump delayed]
planner: black ad0s1g 20040226 0 [dumps too big, 6442932 KB, full dump delayed]
planner: Full dump of koala:wd0e promoted from 4 days ahead.
planner: Full dump of cindy:ad0s1e promoted from 4 days ahead.
planner: Full dump of black:spaer-b promoted from 4 days ahead.
planner: Full dump of koala:wd0a promoted from 4 days ahead.
planner: Full dump of cindy:ad0s1a promoted from 4 days ahead.
planner: Full dump of black:ad0s1f promoted from 4 days ahead.
planner: Full dump of black:ad0s1a promoted from 4 days ahead.
planner: Full dump of cindy:ad0s1f promoted from 4 days ahead.
planner: Full dump of koala:wd0d promoted from 4 days ahead.
planner: Full dump of cindy:ad0s1g promoted from 4 days ahead.
planner: Full dump of koala:wd0g promoted from 4 days ahead.
planner: Full dump of koala:wd0f promoted from 4 days ahead.
taper: tape DailyDump05 kb 11613728 fm 23 [OK]
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKLORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -- -
blackMUSIC-ag1680704 -- 0:05 148.1 0:02298.2
blackMUSIC-hk1300320 -- 0:02 158.0 0:02203.1
blackMUSIC-lo1270288 -- 0:02 147.8 0:02173.7
blackMUSIC-oz1660672 -- 0:05 131.5 0:02355.4
blackWAVS-ag 1120128 -- 0:03 37.1 0:02 70.0
blackWAVS-hk 1
