Re: Move disk without loosing backup history?
Dustin J. Mitchell wrote: On Thu, Aug 28, 2008 at 7:48 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: The tar folks at gnu do not consider that a bug, but as a part of the security. To be fair, the tar developers did fix this -- in 1.21, IIRC. As to the original question, no, I don't think that there is any way to "pretend" that one host/disk is the same as another. When we have a more expressive catalog, it might be interesting to have some kind of "redirect" that amrecover could follow when browsing the history of a DLE -- similar to Subversion's "copy-from". Yes. This is exactly what I think I need. It would also help when setting up new configs if amanda would compare IP addresses rather than hostnames when determining if different DLEs are on the same host. You might then keep disklist containing the_server_for_disk1 /disk1 full-tar the_server_for_disk2 /disk2 full-tar and so on, where "the_server_for_disk1" and "the_server_for_disk2" are hostname aliases that are moved along with the disk, if you know what I mean. Actually, our hosts database is set up like this already, except there isn't one alias for each disk, but one per disk cabinet and/or logical group of volumes. This already works if "the_server_for_disk1" and "the_server_for_disk2" point to different hosts, and there are no other DLEs for that host, of course, but the idea is that they *might* be different aliases for the same host at a certain point in time. - Toralf
Re: Move disk without loosing backup history?
Toralf Lund wrote: Gene Heskett wrote: On Thursday 28 August 2008, Toralf Lund wrote: I've just moved a disk from one server to another without really changing anything with respect to how the clients see it; logically, the disk still represents exactly the same volume on the network. [... ] Unforch, what I'd call a bug in tar will cause it to be treated as a new device. Part of tar's detection code makes the device's assigned number part of the new/old decision. So it will be subjected to a full level 0 backup as a newly discovered disk. This is not really a problem. But I don't think I follow you. Perhaps I wasn't clear enough in my original post; the disk is physically the same as before, it's the *host* that has changed. I'd really like the DLE in question to list the actual host it's connected to, and not some client that mounts the volume, so as to avoid sending the same data twice across the network. I suppose I should also point out that the hostname in the DLE is not the one of the host running amdump. I suppose I might have used this for all entries from the beginning, since everything is supposed to be available via NFS (thus using NFS rather than the amanda network protocol to transfer the data), but I didn't really think about it a the time. Maybe I could manipulate the host database so that the hostname would be an alias for the dump host after all, but this might cause conflicts with other DLEs where another alias for that host is listed, and raise some issues not directly related to the amanda config... But if I change the DLE just like that, Amanda will think I'm backing up a new disk (won't it?), so I'll get two separate indexes for what's exactly the same disk, and if I want to recover a really old file, I need to remember to switch to the old index/hostname. Which is something I'd rather avoid. I'm mainly talking about an "archival" config without tape reuse, by the way. And yes, I do keep amanda indexes "from the beginning of time" for those, as the way I see it, without these, the tapes would be pretty much useless, since nobody would remember what was supposed to be on them... - Toralf -- Toralf Lund <[EMAIL PROTECTED]> +47 66 85 51 22 ProCaptura AS +47 66 85 51 00 (switchboard) http://www.procaptura.com/ +47 66 85 51 01 (fax)
Re: Move disk without loosing backup history?
Gene Heskett wrote: On Thursday 28 August 2008, Toralf Lund wrote: I've just moved a disk from one server to another without really changing anything with respect to how the clients see it; logically, the disk still represents exactly the same volume on the network. [... ] Unforch, what I'd call a bug in tar will cause it to be treated as a new device. Part of tar's detection code makes the device's assigned number part of the new/old decision. So it will be subjected to a full level 0 backup as a newly discovered disk. This is not really a problem. But I don't think I follow you. Perhaps I wasn't clear enough in my original post; the disk is physically the same as before, it's the *host* that has changed. I'd really like the DLE in question to list the actual host it's connected to, and not some client that mounts the volume, so as to avoid sending the same data twice across the network. But if I change the DLE just like that, Amanda will think I'm backing up a new disk (won't it?), so I'll get two separate indexes for what's exactly the same disk, and if I want to recover a really old file, I need to remember to switch to the old index/hostname. Which is something I'd rather avoid. I'm mainly talking about an "archival" config without tape reuse, by the way. And yes, I do keep amanda indexes "from the beginning of time" for those, as the way I see it, without these, the tapes would be pretty much useless, since nobody would remember what was supposed to be on them... - Toralf
Move disk without loosing backup history?
I've just moved a disk from one server to another without really changing anything with respect to how the clients see it; logically, the disk still represents exactly the same volume on the network. Is there any way I can change the amanda config so that the disk is backed up via the new server, but status is written to the existing backup history of the volume? I originally planned to use hostname aliases in such a way that no config update would be necessary in this situation, but as you know, Amanda doesn't really understand the alias concept (or didn't when I first configured it, anyway)... - Toralf
Re: "disk was stranded on waitq"/sendsize timed out waiting for REP data
Toralf Lund wrote: Forgot to answer this earlier, I think... If you can't kill sendsize, it's because it is hang in a system call. It's often when it try to access a mount point. Do you have a hanged mount point? But yes, you are absolutely right. The host in question had problems with an NFS mount. [ ... ] After I got rid of this mount I thought everything worked fine, but right now I discovered that I still get the "disk stranded" message - but without sendsize hangs this time ;-( Note that I ended up removing "amandates" and all gnutar-lists files on the host in question in order to get back on track. After I had resolved the NFS issues, "sendsize" would not exactly hang, but it didn't work properly, either - the process would just sit there (apparently) doing nothing for hours - until the amanda server eventually timed out and gave up on the DLEs in question. Very frustrating. But like I said, after removing all state files, everything seems to work just fine. - Toralf
Re: sendbackup: index tee cannot write [Broken pipe]
A few days ago I had some backup problems that turned out to be caused by a hanging NFS mount, causing "sendsize" to lock up completely - see a separate post on this. Now I have sorted out this problem, and it seemed like amdump would once again start properly, but it turns out that the backup still doesn't run properly - this time it's "sendbackup" that gets into trouble. The full sendbackup...debug from a failed dump is included below. [ ... ] Right. After looking a bit more at the logs etc. I'm no longer convinced that the error reported here is the main issue, and that it could be caused by a full disk - which I didn't think at first it might be, because I though I got the same behaviour for different configs with different holding space on different disks and I was convinced that they can't all have been filled up. Anyhow, the thing is, I've been getting the following strange and somewhat annoying (because I just can't understand what "stranded on waitq" is supposed to mean) error message: fileserv:/archive0 planner: [hmm, disk was stranded on waitq] This turned out to be caused by various sendsize processes hanging because of NFS access problems. Or at least, so I thought, but after sorting out these issues, I still get the same message. So I looked at the logs again and noticed the "index tee cannot write", but maybe it's just a coincidence that this started occurring right now, and that the other message is caused by something else entirely? - Toralf
sendbackup: index tee cannot write [Broken pipe]
A few days ago I had some backup problems that turned out to be caused by a hanging NFS mount, causing "sendsize" to lock up completely - see a separate post on this. Now I have sorted out this problem, and it seemed like amdump would once again start properly, but it turns out that the backup still doesn't run properly - this time it's "sendbackup" that gets into trouble. The full sendbackup...debug from a failed dump is included below. Does anyone have any idea what may be causing this? What exactly is this "index tee" trying to write to (file, FIFO, socket...)? Is there anything extra that needs to be cleaned up after problems caused by hanging sendsize processes? sendbackup: debug 1 pid 13900492 ruid 33 euid 33: start at Fri Mar 2 16:58:31 2007 sendbackup: version 2.5.0p2 parsed request as: program `GNUTAR' disk `/scanner/golg' device `/scanner/golg' level 0 since 1970:1:1:0:0:0 options `|;auth=BSD;srvcomp-fast;index;exclude-list=.amanda.excludes;exclude-optional;' sendbackup-gnutar: time 0.019: doing level 0 dump as listed-incremental to /usr/freeware/var/lib/amanda/gnutar-lists/fileserv_scanner_golg_0.new sendbackup-gnutar: time 385956.158: doing level 0 dump from date: 1970-01-01 0:00:00 GMT sendbackup: time 385956.592: spawning /usr/freeware/libexec/runtar in pipeline sendbackup: argument list: gtar --create --file - --directory /scanner/golg --one-file-system --listed-incremental /usr/freeware/var/lib/amanda/gnutar-lists/fileserv_scanner_golg_0.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendbackup._scanner_golg.20070307041107.exclude . sendbackup: time 385956.603: started index creator: "/usr/freeware/bin/tar -tf - 2>/dev/null | sed -e 's/^\.//'" sendbackup-gnutar: time 385956.605: /usr/freeware/libexec/runtar: pid 14323097 sendbackup: time 385956.606: started backup sendbackup: time 385969.818: index tee cannot write [Broken pipe] sendbackup: time 385969.818: pid 14193336 finish time Wed Mar 7 04:11:21 2007 sendbackup: time 385969.842: 117: strange(?): sendbackup: index tee cannot write [Broken pipe] sendbackup: time 403598.554: error [/usr/freeware/bin/tar got signal 9] sendbackup: time 403598.615: pid 13900492 finish time Wed Mar 7 09:05:09 2007
Re: "disk was stranded on waitq"/sendsize timed out waiting for REP data
Forgot to answer this earlier, I think... If you can't kill sendsize, it's because it is hang in a system call. It's often when it try to access a mount point. Do you have a hanged mount point? But yes, you are absolutely right. The host in question had problems with an NFS mount. I didn't think I did, but it turned out that it would still mount a certain volume that hadn't been used for a long time, and whose server had been left running, but was shut down some days ago... This was not in any way referenced by the backup config, though, but perhaps sendbackup reads '/' or something, so that *all* hanging mount points there are problematic? After I got rid of this mount I thought everything worked fine, but right now I discovered that I still get the "disk stranded" message - but without sendsize hangs this time ;-( - Toralf
"disk was stranded on waitq"/sendsize timed out waiting for REP data
We just started to get a serious problem with our amdump execution
(Amanda 2.5.0p2). As usual, we don't thing we have changed anything at
all after the last successful dump
Symptoms:
1. "amstatus" says
fileserv:/scanner0 planner: [hmm, disk was
stranded on waitq]
2. "sendsize" on the host in question hangs, and I mean really hangs
- not even 'kill -9' will stop it.
3. The amandad..debug on this host ("fileserv") says:
amandad: time 14027.090: sending ACK pkt:
<
>
amandad: time 21600.297: /usr/freeware/libexec/sendsize timed out
waiting for REP data
amandad: time 21600.309: sending NAK pkt:
<
ERROR timeout on reply pipe
>
amandad: time 35627.467: /usr/freeware/libexec/sendsize timed out
waiting for REP data
amandad: time 35627.467: sending NAK pkt:
<
ERROR timeout on reply pipe
>
amandad: time 35650.476: pid 11670783 finish time Thu Mar 1
07:54:12 2007
This happens for all disks on one particular host. Other DLEs appear to
be OK, but nothing is actually dumped, since amdump will give up the
entire operation due to these problems (I think.)
Also, we actually run amdump with two different configs (the usual tape
backup and an "incremental only" with output to harddisk) on the same
disks every night (but not simultaneously, of course), and we see this
behaviour for both.
HELP!
- Toralf
Re: "Unknown partition table signature" on "ghosted" disk
I'm not sure this is the right place to ask questions like this, but I'll give it a try: Oh. No. It most certainly isn't, since I didn't even post to the intended list. I wanted "Anaconda", not "Amanda" (that's automatic address lookup for you.) Sorry. - Toralf
"Unknown partition table signature" on "ghosted" disk
I'm not sure this is the right place to ask questions like this, but I'll give it a try: On a certain host at work, the RH system installer (usually booted from a customised DVD...) will fail to detect the existing Linux partitions. The error message is (I think) "Unknown partition table signature". I've pretty much asked for such problems, I guess, as the system was set up via filesystem copy from a disk of a different size, using a "ghost" utility, but the weird part is that it boots just fine (after certain adjustments), and perhaps even stranger still: I can also access the filesystems in rescue mode. Or actually, the automatic detection won't work in that case, either, but once I've entered the shell, I can do a "mount" of the devices and subsequently read and write files without any problems. Any ideas what this is all about? What is that signature supposed to be, anyway, and how do you set it? - Toralf
Re: determining backup set
As long as the log files are available, the amandatape script that I posted a while ago to this list will give you the info that you are looking for. You can find it here: Maybe I've missed something, but I can't see why a special script would be necessary in this case. Why not use the commands already provided as part of the amanda distribution? I mean, like amadmin find Ahh, amadmin, the Swiss Army Knife of amanda :) "find" is another of its commands I've not tried. Right. Or how about "info"? Could be even more useful in this case ;-) - Toralf
Re: determining backup set
Maybe I've missed something, but I can't see why a special script would be necessary in this case. [ ... ] This script is not special for the situation in question. In contrast, it is meant to be run after every backup to produce tape-labels with information which files from which tapes you need to recover a given DLE. You attach those labels to the tapes and you always have an answer to OP's question, even if you loose the database. Why not use the commands already provided as part of the amanda distribution? I mean, like amadmin find or amadmin find or amadmin find Maybe because the output of "amadmin find" is no more than a plain dump of amanda's database. Please go and check the above mentioned script and compare its output with the output of "amadmin find". Maybe I'll do that, but I think you misunderstood me. I wasn't trying to imply that your script isn't useful, or anything. I just meant to point out that when newbies ask questions like this, I think we should try to explain what might be done with the built-in commands before we tell them to install additional software. Unless, of course, there is absolutely no way to solve the problem with the usual commands, which I think isn't the case here. - Toralf
Re: determining backup set
Josef Wolf wrote: On Fri, Jun 16, 2006 at 10:47:52AM -0400, Marlin Whitaker wrote: On Jun 15, 2006, at 3:03 PM, Jon LaBadie wrote: On Thu, Jun 15, 2006 at 12:33:16PM -0400, Marlin Whitaker wrote: If I have a collection of tapes from previous amanda backups, is there a procedure for determining which set of tapes contain a complete backup? I'm assuming you don't have access to the logs/indexes/amrecover. Actually, I probably do have access to these things, but I'm not yet sure how to interpret them. Any pointers will be appreciated. (Note that all recent log files represent backup failures, but the old logs are still available in the archive area.) As long as the log files are available, the amandatape script that I posted a while ago to this list will give you the info that you are looking for. You can find it here: Maybe I've missed something, but I can't see why a special script would be necessary in this case. Why not use the commands already provided as part of the amanda distribution? I mean, like amadmin find or amadmin find or amadmin find - Toralf
"strategy incronly" and "skip-full" again: According to manual page, both are buggy. Have bugs been fixed?
Regarding my recent post regarding "strategy incronly" and "skip-full",
I just found out more about the problems I've had in the past with this
simply by checking the amanda.conf manual page it says:
skip-full /boolean/
Default: no. If true and planner has scheduled a full backup,
these disks will be skipped, and full backups should be run
off-line on these days. It was reported that Amanda only
schedules level 1 incrementals in this configuration; this is
probably a bug.
and also
strategy {standard|nofull|noinc|skip|incronly}
[ ... ]
incronly : Only do incremental dumps. amadmin force should be
used to tell Amanda that a full dump has been performed
off-line, so that it resets to level 1. It is similar to
skip-full, but with incronly full dumps may be scheduled
manually. Unfortunately, it appears that Amanda will perform
full backups with this configuration, which is probably a bug.
So, the problem with setting up an incremental-only config is that with
"skip-full", incremental level will never be increased above 1, while
with "strategy incronly", it is updated correctly, but the level 0s
(scheduled via "amadmin force") won't be skipped correctly. Or at least,
that's the way it's been in the past. Does anyone know if anything has
been done lately to address these issues?
- Toralf
Recommended value for bumppercent?
Another question related to one of my recent threads: What do you think is a good value for "bumppercent"? Why? - Toralf
Re: Is tape spanning documented anywhere?
I also have one other scenario in mind, though - which is one I've actually come across a number of times: What if a certain DLE due for backup is estimated to be slightly smaller than *, and thus dumped to holding disk, but then turns out to be slightly larger? Wouldn't it be more accurate to say the scenario you ran into previously was DLE larger than because the tape spanning feature was not available at that time. Yes. But the key issue remains unchanged. With the current setup, amanda will obviously run out of tape-space during the original dump and also if you try amflush. And if auto-flush is enabled, the next dump will hit end-of-tape before any of the new dumps have been written, and the next one after that, and so on; this holding disk image will effectively block the tape operation of all the following backups, and eventually, the holding disk will be full, too, so amdump won't be able to do anything at all. What is different with the tape spanning feature is that you could get the large DLE to tape by simply increasing runtapes, even if only temporarily. Thus, no system lockup. Yes, but that requires manual intervention, and we were talking about safety. All situations where you have to do manual work in order to allow the backup to continue mean reducing safety, IMO, or differently put, a change that means they won't occur, increases safety. - Toralf
Re: Version 2.5.0: Have incronly/skip-fill issues been addressed
Jon LaBadie wrote: On Tue, Jun 13, 2006 at 11:46:20AM +0200, Paul Bijnens wrote: I'm still finding out a use for "skip-full". It seems to be a weird option: when the planner had decided to make a full dump, then in the real run it is skipped. That would mean that you have to be carefully reading the report to know when to run a manual full dump of that DLE. And until you do, you have no backup at all. Strange option... Yeah, I've only used skip-incr (DLE's containing CD .iso images :) [ ...] The reason why I asked about this, was that I'm doing an "incremental only" dump with output to disk, via a separate configuration. This is synced with the "main" config via "amadmin force" - I have written a little script that will extract a list of DLEs that got a full backup during the last run of the main config, and execute the "force" command on the "incremental" one for each of them. Like I said, I can't remember the details, but I found earlier that I had to use "skip-full" *and* "strategy incronly" in that setup. Unfortunately, with amanda 2.4.x, even that is not enough. The dump level isn't actually reset by the "force" command, and I have to patch the "info" file. - Toralf
Re: Is tape spanning documented anywhere?
Toralf Lund wrote: Jon LaBadie wrote: On Tue, Jun 13, 2006 at 02:46:31PM +0200, Toralf Lund wrote: Normally I would agree, but I have to back up 3Tb of data organised as one single volume. The only "simple" option would be to have one 3Tb tape as well, but such a thing isn't available (to me at least.) Toralf, perhaps I'm being dense, but why isn't your situation satisfied by the current tape-spanning. I'm envisioning something like lto-2 or lto-3 drives and using no holding disk but sufficient buffer space. If your data compresses to say 1.6TB with the 400GB lto-3 tapes, a setting of runtapes 5 or 6 will accept an entire level 0 dump with only part of the final tape wasted. Well, like I just said in another post - maybe I worry to much, but I'm a bit concerned about dumping 5 or 6 tapes during one run and nothing during others, based in timing/system load considerations. It just seems nicer to spread the work as evenly as possibly across runs... Also, I was thinking that I might be able to split up the directory enough to make do with 2 tapes per DLE. With the current tape-spanning and "runtapes 2", the waste of tape would then start getting rather significant - I would waste space on every other tape, rather than just one out of 5 or 6... But maybe I shouldn't worry too much about extra tape usage, either, since the tapes are a one-time cost with the normal reuse setup. Wasted tapes means slightly more work for the person responsible for changing the tapes, though... - T
Re: Is tape spanning documented anywhere?
Jon LaBadie wrote: On Tue, Jun 13, 2006 at 02:46:31PM +0200, Toralf Lund wrote: Normally I would agree, but I have to back up 3Tb of data organised as one single volume. The only "simple" option would be to have one 3Tb tape as well, but such a thing isn't available (to me at least.) Toralf, perhaps I'm being dense, but why isn't your situation satisfied by the current tape-spanning. I'm envisioning something like lto-2 or lto-3 drives and using no holding disk but sufficient buffer space. If your data compresses to say 1.6TB with the 400GB lto-3 tapes, a setting of runtapes 5 or 6 will accept an entire level 0 dump with only part of the final tape wasted. Well, like I just said in another post - maybe I worry to much, but I'm a bit concerned about dumping 5 or 6 tapes during one run and nothing during others, based in timing/system load considerations. It just seems nicer to spread the work as evenly as possibly across runs... And like I also said, in general, allowing "partial flush" would also address another issue: The one of blocking the entire tape operation when using a holding disk, and getting a dump larger that won't fit on the tapes even though it was expected to (either because of miscalculations during the planner phase or because it specifying the tape size seems to be a rather inexact science.) We're talking about an LTO-2 changer, by the way... - Toralf
Re: Is tape spanning documented anywhere?
To throw my $.02 in here, the situations would be very different. If one is "forced" to have all DLEs "tapeable" in one amdump run, then (theoretically), nothing will be left on the holding disk to lose should said disk die. But we're talking about a situation where the DLEs are not "tapeable". The With tape spanning as implemented, any DLE is tapeable if runtapes is big enough. :) What I'm slightly worried about, is the "unbalanced" setup a low number of large DLEs combined with a large runtapes value will give me. I mean, it implies that several tapes will have to be written on some nights, while nothing at all is taped on others - at least if we disregard incrementals for the moment. This could mean that the write operation will continue long into the following day, when we want to use the server's capacity for other purposes, or (even worse) isn't finished when the next dump is supposed to start. Actually, maybe there won't be any serious issues associated with this, but I'd just feel more comfortable if I could spread the work more evenly and/or use the idle hours of every night. And a different "flush" operation would help me achieve at least part of that, even though the actual dump would still be pretty unbalanced. Some of my colleagues have just nearly convinced me that I worry too much, though ;-/ Maybe it's just me being curmudgeonly (it wouldn't be the first time -- hell, I haven't found a WM I like more than fvwm2) and slavishly adhering to the KISS method. But I think backups *should* adhere to the KISS method. Normally I would agree, but I have to back up 3Tb of data organised as one single volume. The only "simple" option would be to have one 3Tb tape as well, but such a thing isn't available (to me at least.) Also, I think the whole tape splitting concept is inherently complex, and what I suggest here doesn't change the complexity level. The complexity was introduced already, I'm just talking about a *simple* implementation adjustment... I agree that it doesn't change the complexity level. But it does change the safety level. Suddenly you're making yourself far more vulnerable to losing parts of a backup image. On a practical level, I'm pretty sure that the setup you're proposing would require you to have a 3TB holding disk (or at least 3TB-tapelength) to hold your level 0. It's not quite as bad as that, fortunately. While there is one 3TB volume, I can actually split it into more than one DLE quite easily. Splitting it into (much) more than tapes-per-cycle entries (which seems to be a requirement if you want a "balanced" setup) is however going to very hard. But you are right, holding list space is also going to be a bit of an issue. I also have one other scenario in mind, though - which is one I've actually come across a number of times: What if a certain DLE due for backup is estimated to be slightly smaller than *, and thus dumped to holding disk, but then turns out to be slightly larger? With the current setup, amanda will obviously run out of tape-space during the original dump and also if you try amflush. And if auto-flush is enabled, the next dump will hit end-of-tape before any of the new dumps have been written, and the next one after that, and so on; this holding disk image will effectively block the tape operation of all the following backups, and eventually, the holding disk will be full, too, so amdump won't be able to do anything at all. If we were to introduce "partial tape write" as discussed here, but leave the scheduling algorithm unchanged, we would actually increase the safety in this area - an oversized dump would also be flushed eventually, and not "lock up" the system. We would not compromise the safety in other ways, as Amanda would still try to schedule only *'s worth of data (so nothing would be left on the holding disk if everything went according to plan.) - Toralf
Re: Is tape spanning documented anywhere?
Joshua Baker-LePain wrote: On Tue, 13 Jun 2006 at 12:55pm, Toralf Lund wrote Paul Bijnens wrote: Taping one DLE is several "runs" opens a can of worms: you have to add a notion of "partial" succeeded. Restoring then needs some tapes and some holdingdisk files. What if the holdingdisk crashes or accidently rm the files before all of it is written to tape? etc. This would be a bit of an issue, of course. I'm wondering if the would the situation be that much different from the one we have today, though. Holding disk crash or file removal is always going to be a serious problem, of course. But if you have a partial tape dump of the data, you will at least be able to recover some of it... Maybe it would be wise to keep all data on the To throw my $.02 in here, the situations would be very different. If one is "forced" to have all DLEs "tapeable" in one amdump run, then (theoretically), nothing will be left on the holding disk to lose should said disk die. But we're talking about a situation where the DLEs are not "tapeable". The alternatives are writing parts of a DLE and writing nothing at all. Or maybe, if the scheduling setup was also changed, there *would* be some additional DLEs there to loose - but these would never be taped with the current version either - they would actually not even be dumped... That's obviously not the case if single DLEs are allowed to span amdumps, and the holding disk dies between amdumps. Having the entire night's amdump run on tape at the end of the amdump gives me that warm fuzzy feeling inside. There will be nothing that prevents you from getting that *if it is possible*. But again, in the World I'm talking about, you simply won't get everything on tape. You can only choose between *something* or nothing at all... Maybe it's just me being curmudgeonly (it wouldn't be the first time -- hell, I haven't found a WM I like more than fvwm2) and slavishly adhering to the KISS method. But I think backups *should* adhere to the KISS method. Normally I would agree, but I have to back up 3Tb of data organised as one single volume. The only "simple" option would be to have one 3Tb tape as well, but such a thing isn't available (to me at least.) Also, I think the whole tape splitting concept is inherently complex, and what I suggest here doesn't change the complexity level. The complexity was introduced already, I'm just talking about a *simple* implementation adjustment... What happens in the current version if amdump is interrupted while writing the 2nd tape, by the way? I assume the same thing that would happen if amdump were interrupted while writing to the 1st tape. The image being written to tape would be marked FAILED TO TAPE and be left on the holding disk (along with any other images that hadn't been written yet), and the user would be encouraged to run amflush.
Re: Is tape spanning documented anywhere?
Paul Bijnens wrote: On 2006-06-13 12:10, Toralf Lund wrote: Yes indeed. The whole DLE. A singe DLE still needs to be written in one run, possibly using many tapes. Oh no... Like I said, that's a big disappointment. I'm tempted to say that it is not correct to claim that Amanda now suppots tape spanning, if it can't span dumps across tapes written in separate runs. Shouldn't it be able to delete the corresponding data from the holding disk file as tape-chunks are successfully written - so that only the remaining chunks would be flushed on the next run? Seems like this should be easy enough to implement, especially if you interact with holding disk chunks in a constructive manner. Is there any reason why nobody has looked into this, except for lack of time? ... or maybe what's on the holding disk does not really matter and/or is a separate issue. I suppose the taper already knows how to find a certain tape-chunk within the holding disk data, so it's more a matter of being able to tell it to start writing from a certain chunk (different from 0) during flush. The flush operation would obviously have to find the correct index somewhere in the database. Does it do a lookup at all today, or just blindly tape whatever is on the holding disk? Taping one DLE is several "runs" opens a can of worms: you have to add a notion of "partial" succeeded. Restoring then needs some tapes and some holdingdisk files. What if the holdingdisk crashes or accidently rm the files before all of it is written to tape? etc. This would be a bit of an issue, of course. I'm wondering if the would the situation be that much different from the one we have today, though. Holding disk crash or file removal is always going to be a serious problem, of course. But if you have a partial tape dump of the data, you will at least be able to recover some of it... Maybe it would be wise to keep all data on the disk until all tape-chunks are fully written, though, and also use the "partial" status only for flush purposes, i.e. consider "partial" writes as "unsuccessful" when doing restore etc. What happens in the current version if amdump is interrupted while writing the 2nd tape, by the way? As Stefan used to say: AAPW(*). Well, yes. I was partly also asking if a P would be W in this case, though, or if someone for some good reason had decided that tape split across runs should not be supported. - Toralf
Re: Is tape spanning documented anywhere?
Yes indeed. The whole DLE. A singe DLE still needs to be written in one run, possibly using many tapes. Oh no... Like I said, that's a big disappointment. I'm tempted to say that it is not correct to claim that Amanda now suppots tape spanning, if it can't span dumps across tapes written in separate runs. Shouldn't it be able to delete the corresponding data from the holding disk file as tape-chunks are successfully written - so that only the remaining chunks would be flushed on the next run? Seems like this should be easy enough to implement, especially if you interact with holding disk chunks in a constructive manner. Is there any reason why nobody has looked into this, except for lack of time? ... or maybe what's on the holding disk does not really matter and/or is a separate issue. I suppose the taper already knows how to find a certain tape-chunk within the holding disk data, so it's more a matter of being able to tell it to start writing from a certain chunk (different from 0) during flush. The flush operation would obviously have to find the correct index somewhere in the database. Does it do a lookup at all today, or just blindly tape whatever is on the holding disk? - Toralf
Re: Is tape spanning documented anywhere?
Paul Bijnens wrote: On 2006-06-13 10:32, Toralf Lund wrote: 2. What happens to the holding disk file after a dump is partially written to tape? Will Amanda keep the entire file, or just what will be written next time around? And what if the holding disk data is split into "chunks"? Amanda keeps the entire dump, and will be flushed entirely again on the next amflush or autoflush. You mean entirely as in the whole DLE? That would mean that tape splitting is restricted to multiple tapes written in the same run, which would be rather disappointing. Yes indeed. The whole DLE. A singe DLE still needs to be written in one run, possibly using many tapes. Oh no... Like I said, that's a big disappointment. I'm tempted to say that it is not correct to claim that Amanda now suppots tape spanning, if it can't span dumps across tapes written in separate runs. Shouldn't it be able to delete the corresponding data from the holding disk file as tape-chunks are successfully written - so that only the remaining chunks would be flushed on the next run? Seems like this should be easy enough to implement, especially if you interact with holding disk chunks in a constructive manner. Is there any reason why nobody has looked into this, except for lack of time? But you may still split a v large DLE into smaller ones using the include/exclude mechanism that exists for a long time. Yeah, I know, but hasn't the fact that you have to do that always been seen as the one big limitation of Amanda? I was hoping this was gone now now ;-( This thing is, setting up the exclusions/inclusions right is nearly always non-trivial on a system with dynamic data, and in a setup I'm looking at now, it will simply be impossible to specify a static config for this. Without real tape overflow support, we'll simply have to update amanda.conf every day. The actual update may perhaps be done automatically, but I was rather hoping I wouldn't have to implement a tool for that, and the dump database etc. will obviously also get very messy. Differently put, I don't want to set up an amanda config which has the odd DLE that's slightly larger than a tape - I want *all* DLEs to be like that. I may be able to assume that they are never larger than two tapes, so I could use "runtapes 2", but I fear that this would lead to too much waste of tape space. I suspect the only way to get the full dumps evenly split across a relatively limited number of tapes, will be to set "runtapes" large enough for all full dumps to fit into one run, but this is probably not possible in practice. Only now you are not limited by the capacity of a single tape anymore. Or maybe you misunderstood the question. Sorry if I was a bit unclear, but I'm not sure what terminology to use, now. What do you (should we) call one piece of output from the "tape split"? And what should "dump" be taken to mean? The entire output from the backup of one DLE, or one entry from the tape splitting. And what will a holding disk file contain, anyway? Again, will it be data for the whole DLE, or one instance of output from the split operation? (Like I said, I'm testing a bit as I write this, but haven't been able to draw any conclusions yet, mainly because I had to re-build amanda just now...) A piece of a DLE on tape: a tape-chunk. [ And so on ] OK. Thanks. - Toralf
Version 2.5.0: Have incronly/skip-fill issues been addressed
Another question related to amanda 2.5: Does anyone know if the issues with "skip-full" and/or "strategy incronly" been addressed? In the past, neither "strategy incronly" nor "skip-full" have worked quite as expected. I'm afraid I can't remember the full details, but one problem I've had, was that "amadmin force" would not really reset the dump level to 0. Another issue is of course that there are two slightly different ways of requesting an "incremental only" dump, i.e. "skip-full" and "strategy incronly". I concluded at one point that I actually had to use both in my setup. Anyhow, I'm assuming that some of you lot will know what I'm talking about, and can tell me if the situation has changed lately. - Toralf
Re: Is tape spanning documented anywhere?
2. What happens to the holding disk file after a dump is partially written to tape? Will Amanda keep the entire file, or just what will be written next time around? And what if the holding disk data is split into "chunks"? Amanda keeps the entire dump, and will be flushed entirely again on the next amflush or autoflush. You mean entirely as in the whole DLE? That would mean that tape splitting is restricted to multiple tapes written in the same run, which would be rather disappointing. Or maybe you misunderstood the question. Sorry if I was a bit unclear, but I'm not sure what terminology to use, now. What do you (should we) call one piece of output from the "tape split"? And what should "dump" be taken to mean? The entire output from the backup of one DLE, or one entry from the tape splitting. And what will a holding disk file contain, anyway? Again, will it be data for the whole DLE, or one instance of output from the split operation? (Like I said, I'm testing a bit as I write this, but haven't been able to draw any conclusions yet, mainly because I had to re-build amanda just now...) Anyhow, when I said "holding disk file" earlier, what I meant was "the holding disk data for one DLE", and when I said "partially written to tape", what I meant was "some, but not all, split sections completely written to tape" (i.e. I was not talking about sections that are incomplete because end-of-tape is reached.) - Toralf
Re: Is tape spanning documented anywhere?
Anyhow, I'd really like to know more about how the spanning actually works. Is it documented anywhere? http://www.amanda.org/docs and FAQ still say that the option does not exist... Try http://wiki.zmanda.org/index.php/Splitting_dumps_across_tapes Yes. Thanks. That's quite helpful. A few questions still remain, though. Like 1. Does tape splitting in any way affect the scheduling algorithm? I mean, what if Amanda wants to dump a certain amount in order to reach the "balanced" dump size, and only much larger DLEs are available? Might one of those be scheduled just so that one "split" part can be used to fill up the remaining space? 2. What happens to the holding disk file after a dump is partially written to tape? Will Amanda keep the entire file, or just what will be written next time around? And what if the holding disk data is split into "chunks"? But I'm testing a setup using "tape_splitsize" right now, so maybe I'll find out... - Toralf
Re: filename ... has invalid characters
Hi Toralf, First off, I rather like your approach to configuration files. Good ;-) A little research shows that the explicit test was introduced to plug a security hole reported by PERL... See BUG #1353481 for more information. I see... [ ... ] I'm proposing an alternate solution to our mutual problems: Sanitize file name by simply rejecting any '..' path component in a configuration name. Right. Of course ".." might be used in clever ways to do some evil. Never thought of that. This should allow any arbitrary character in the configuration name and prevent any attempts to use a configuration outside of the amanda configuration directory. Toralf: will this work for you? Yes, this will be quite all right with me. - Toralf
Version 2.5.0p2: amstatus parse error for logfile from older version
I'm trying to run "amstatus" on existing logfiles after upgrading from
version 2.4.4p3 to 2.5.0p2. Unfortunately, the command will most of the
time fail with a message like:
amstatus ks --file /dumps/amanda/ks/log/amdump.1
Using /dumps/amanda/ks/log/amdump.1 from Thu Jun 8 17:04:30 CEST 2006
ERROR getting estimates 0 (909420) -1 (-1) -1 (-1) at
/usr/sbin/amstatus line 213, line 74.
The error seems to come from the following section of PERL code:
if(/getting estimates (-?\d) \(-2\) (-?\d) \(-2\) (-?\d) \(-2\)/) {
if($1 != -1) { $getest{$hostpart} .= ":$1:" };
if($2 != -1) { $getest{$hostpart} .= ":$2:" };
if($3 != -1) { $getest{$hostpart} .= ":$3:" };
}
else {
die("ERROR $_");
}
Which does not really make sense to me. Am I missing something, or does
the above match operator *require* a number of ocurreces of the string
"(-2)" (as opposed to "some value in brackets")?
Isn't the new amstatus expected to work with old logfiles?
- Toralf
filename ... has invalid characters
I'm now testing amanda 2.5.0p2. First problem: # amstatus ks/archive filename 'ks/archive' has invalid characters. I suppose the problem here is that I specified a filename containing "/", but I actually did this on purpose, and it has always worked in the past. I'm using multiple directory levels under /etc/amanda, you see - amanda.conf for the configuration I'm trying to refer to here is stored under /etc/amanda/ks/archive. I set it up like that because I wanted to group configs that would share data like the disklist. (So I have a /etc/amanda/ks/disklist referenced by several different /etc/amanda/ks/*/amanda.conf.) Maybe this was stupid, but it seemed like a good idea at the time... In any case, I'm wondering why an explicit test on the configuration name has (apparently) been introduced. Won't you find out soon enough anyway whether it is correct or not? (I mean, you just look for /etc/amanda//amanda.conf...) -- Toralf Lund
Is tape spanning documented anywhere?
I haven't been following the posts to this list too closely, or bothered to upgrade amanda, for some time (since our existing setup *works*...), so I didn't find out until right now that tape spanning is supported in the current release. Anyhow, I'd really like to know more about how the spanning actually works. Is it documented anywhere? http://www.amanda.org/docs and FAQ still say that the option does not exist... - Toralf
When was bumppercent introduced?
I notice that the doc on amanda.org mentions a parameter "bumppercent". It is not mentioned in my local manual page. Is this a relatively new option? When was it introduced? I mean, what version do I have to install in order to get it? This variant is obviously a lot more flexible than bumpsize... -- Toralf Lund
Re: Slow dump of small directory...
Any idea why I get the following? fileserv:/usr/freeware/etc/openldap 1 32k dumping0k ( 1.53%) (11:32:10) This is from amstatus on a currently running dump, and the time is now # date Thu Feb 23 12:32:35 CET 2006 I mean, why does this dump take so long? I get these very often. Yeah, me to. I meant to say, this (i.e. a *long* time apparently spent on small dumps) is the normal situation - not something exceptional I'm seeing right now. Your dump isn't really taking so long, in fact it's been finished for quite some time. For tiny (essentially empty) dumps, amstatus sometimes doesn't seem to notice them being finished. I haven't investigated any further. Right... What's strange, though, is that the amdump as been busy for *hours* working only on a relatively small number of tiny dumps (I mean, after some other, larger dumps were done.) So, doesn't amdump itself notice that they are finished, either? Or should I expect that the incremental dump takes long even though it is "empty", when the directory itself (or size of a full dump, if you like) is very large? I mean, the directory I mentioned does not contain a lot of data, but some of the others being "busy dumping" for a long time hold several gigabytes, but also have no updated files. - Toralf
Slow dump of small directory...
Any idea why I get the following? fileserv:/usr/freeware/etc/openldap 1 32k dumping0k ( 1.53%) (11:32:10) This is from amstatus on a currently running dump, and the time is now # date Thu Feb 23 12:32:35 CET 2006 I mean, why does this dump take so long? This is (as you can see) a level 1 dump. I don't think anything at all has changed since the last level 0. The total size of the directory is only 544k. Amanda version 2.4.4p3. - Toralf
Dump only files that match a specific pattern?
I have a disk containing all sorts of temporary data etc. that I haven't included in the amanda config so far. Now I've found, however, that there are *some* files on this disk that I want to back up after all. I can quite easily set up a file matching pattern that would include all those files (and nothing else), while writing one that matches everything I do not want on the backup would be a lot harder. So I would really like to be able to say (in disklist) "include only the files matching", where I'd normally say "include all files except". In other words, I'm looking for an option that does exactly the opposite of "exclude". Is there anything like that? I know, there is "include" of course, but if I specify a pattern there, amcheck says [include must start with './': ] so it may not be what I want. Help, anyone? - Toralf
Running multiple amdumps in paralell?
Something I've always wondered about: Is it safe to run multiple instances of amdump simultaneously? I mean, with different configs, but possibly the same hosts and disks? - Toralf
Re: AIT2 tape size?
Toralf Lund wrote:
I've been meaning to ask about this for a long time:
Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup?
What tape length are you using? [ ... ]
I've now finally run amtape - after making absolutely sure H/W
compression was off - and it said:
-sh-2.05b$ amtapetype -e 50g -t SDX2-50C-NOHWC -f /dev/tape
Writing 256 Mbyte compresseable data: 44 sec
Writing 256 Mbyte uncompresseable data: 44 sec
Estimated time to write 2 * 51200 Mbyte: 17600 sec = 4 h 53 min
wrote 1540096 32Kb blocks in 94 files in 8139 seconds (short write)
wrote 1531904 32Kb blocks in 187 files in 8236 seconds (short write)
define tapetype SDX2-50C-NOHWC {
comment "just produced by tapetype prog (hardware compression off)"
length 48386 mbytes
filemark 2818 kbytes
speed 6003 kps
}
The size reported is as you can see quite a bit below 50Gb, but close to
5000b, so I guess the capacity is 50 salesman's gigabytes, like
someone suggested. I seem to remember writing closer to 25 *real* Gb on
an AIT-1, though, so it may still look like the capacity is less than
doubled with AIT-2, but I could be wrong...
- Toralf
Re: AIT2 tape size?
[ ... ] (*) I used to say "on all linux versions", but it seems there are different implementations in different versions. Some systems can control the tapesettings with the file /etc/stinit.def (see "man stinit" if that exists). Yes. I think maybe you can do something like that on this one (Red Hat.) It's the "stinit" program, which is included in the "mt-st" package, that allows this, but as far as I can tell, it's not actually used in the default setup. - Toralf
Re: AIT2 tape size?
Paul Bijnens wrote: Toralf Lund wrote: Paul Bijnens wrote: amtapetype will tell you too if hardware compression is on. OK. Does amanda have any built-in support for switching it off? I mean, can any of the changer scripts or whatever do this? Or even amdump itself? No. Controlling hardware compression is a very OS and hardware specific issue. I thought that there was at least *some* attempt at a standard way of doing it in the SCSI protocol, although I do know it's done in completely different ways at the user level of different OSes. That's one of the main reason we may have got it wrong, actually. The setup was originally running on an SGI server, and there it was really easy to get it right, since you could choose compression mode via the device selection - i.e. /dev had separate files files for compressed and non-compressed access to the unit. But now it's all moved to Linux... In any case, the tape changer scripts can of course be easily modified, but it would be nice if the "standard" ones at least had some kind of mechanism for hooking in "mt" commands or whatever that might do tapedrive config like this. It can even be manipulated by dipswitches on the tapedrive itself. We haven't actually been able to find any of those on this particular unit (i.e. the tape library), or a compression configuration item in the built-in web software. But maybe there are switches on the actual drive. It can even be more complicated: when reading a tape, the drive adjusts itself automatically to the correct setting. On some(*) linux versions this results in automatically writing with whatever setting the tape was previously written. [ ... ] To get out of this situation, you have to insert the tape, disable hardware compression, and write some data to the tape WITHOUT reading something first. URGH. I didn't know it was that bad ;-( (*) I used to say "on all linux versions", but it seems there are different implementations in different versions. Some systems can control the tapesettings with the file /etc/stinit.def (see "man stinit" if that exists). Yes. I think maybe you can do something like that on this one (Red Hat.) There is also a method to use different device names (**), just as in Solaris, where the letters c, h, m, l are indications of compression and density to use when writing. Right. That's what SGI IRIX does, too. This avoids the above problems, because when you open() a drive for writing, the device name (minor device number actually) contains the settings for the drive implicitly. The whole problem is still not completely clear to me. And the lack of documentation on the st-driver in Linux does not help either. I mean: any pointers are welcome. (**) at least the comments in the kernel source code in drivers/scsi/st.c seem to imply this, but I cannot find any other decent documentation of this.
Re: AIT2 tape size?
Paul Bijnens wrote: Toralf Lund wrote: Ah, yes, of course. No, hardware compression is not supposed to be on. But I'm not sure it isn't... In fact, now that to mention it, I suspect it's on after all. I'll a have a closer look. And I very much doubt that the drive will auto-detect compressed data. amtapetype will tell you too if hardware compression is on. OK. Does amanda have any built-in support for switching it off? I mean, can any of the changer scripts or whatever do this? Or even amdump itself?
Re: AIT2 tape size?
Alexander Jolk wrote: Toralf Lund wrote: the tape size is specified as 50Gb, and that's more or less what the "length" parameter in entry says, but it seems to me that it isn't actually possible to write that much data to these tapes. The maximum seems to be closer to 40Gb, actually. That sounds like hardware compression of already software-compressed data. Are you sure you are not using both? (Or else, are AITs as intelligent as LTOs in not recompressing already compressed data?) Ah, yes, of course. No, hardware compression is not supposed to be on. But I'm not sure it isn't... In fact, now that to mention it, I suspect it's on after all. I'll a have a closer look. And I very much doubt that the drive will auto-detect compressed data. Thanks. - Toralf
AIT2 tape size?
I've been meaning to ask about this for a long time: Does anyone here use AIT2 tapes, a.k.a. SDX-50C, for Amanda backup? What tape length are you using? Please note that I'm not asking for the tapetype entry from the amanda.org archives, as it does not seem quite correct. I mean, the tape size is specified as 50Gb, and that's more or less what the "length" parameter in entry says, but it seems to me that it isn't actually possible to write that much data to these tapes. The maximum seems to be closer to 40Gb, actually. OK, I might run amtapetype, but I'm lazy... And I'm also curious about other people's experience with this tapes. For instance, can anyone actually write as much as 50Gb? - Toralf
Re: Multi-Gb dumps using tar + software compression (gzip)?
Toralf Lund wrote: Paul Bijnens wrote: Toralf Lund wrote: Other possible error sources that I think I have eliminated: 1. tar version issues - since gzip complains even if I just uncopress and send the data to /dev/null, or use the -t option. 2. Network transfer issues. I get errors even with server compression, and I'm assuming gzip would produce consistent output even if input data were garbled due to network problems. 3. Problems with a specific amanda version. I've tried 2.4.4p1 and 2.4.4p3. Results are the same. 4. Problems with a special disk. I've tested more than one, as target for "file" dumps as well as holding disk. 5. Hardware errors, e.g. in bad RAM (on a computer without ECC), or disk controller, or cables. If one single bit is flipped, then gzip produces complete garbage from that point on. Good point. The data isn't compeletely garbled, though; closer inspection reveals that the uncompressed data actually have valid tar file entries after the failure point. In other words, it looks like only limited sections within the file are corrupted. Also, I believe it's not the disk controller, since I've even tried dumping to NFS volumes (but maybe that raises other issues.) Maybe you're only seeing it in such large backups with gzip, but it happens (less often) in other cases too. Any tools available to test the hardware? I have one of those stand-alone test software packages... Yes. Maybe I should run it. I can't just take the server down right now, though ;-( Yes, the problem was most probably caused by a memory error. Faults were reported when testing the RAM thoroughly, and we have not been able to reproduce the gzip issues after replacing the memory! - Toralf
Re: Unexpected 'gzip --best' processes
Joshua Baker-LePain wrote: On Thu, 21 Oct 2004 at 6:19pm, Toralf Lund wrote This may be related to our backup problems described earlier: I just noticed that during a dump running just now, I have # ps -f -C gzip UIDPID PPID C STIME TTY TIME CMD amanda3064 769 0 17:18 pts/500:00:00 /bin/gzip --best amanda3129 773 0 17:44 pts/500:00:00 /bin/gzip --best *snip* Any ideas why I get these processes? That's the indexes (indices?) getting compressed. Ah. Yes, of course... Damn, I was hoping that it was something that shouldn't be there, as that might perhaps explain other issues... index (LIST) <http://dictionary.cambridge.org/define.asp?dict=CALD&key=40207&ph=on> noun [C] plural indices or indexes 1 an alphabetical list, such as one printed at the back of a book showing which page a subject, name, etc. is found on: Try looking up 'heart disease' *in* the index. 2 a collection of information stored on a computer or on a set of cards, in alphabetical order: He has all his friends' names and addresses *on* a *card* index.
Unexpected 'gzip --best' processes
This may be related to our backup problems described earlier:
I just noticed that during a dump running just now, I have
# ps -f -C gzip
UIDPID PPID C STIME TTY TIME CMD
amanda3064 769 0 17:18 pts/500:00:00 /bin/gzip --best
amanda3129 773 0 17:44 pts/500:00:00 /bin/gzip --best
on the Amanda server. Parents are
# ps -f -p 769 -p 773
UIDPID PPID C STIME TTY TIME CMD
amanda 769 743 0 12:44 pts/500:00:00 dumper0 ks/incr
amanda 773 743 0 12:44 pts/500:00:00 dumper2 ks/incr
what's strange about this, is that I'm neither using server compression, nor the
"best" compress options.
My dumptype setup is (this is for my incremental-only backup to harddisk):
define dumptype global {
comment "Global definitions"
index yes
compress client fast
strategy incronly
skip-full
}
define dumptype full-tar {
global
program "GNUTAR"
comment "Dump of files via tar"
priority high
exclude list optional ".amanda.excludes"
}
Any ideas why I get these processes?
- Toralf
Re: amadmin force matches too many disks
Paul Bijnens wrote: Toralf Lund wrote: I just noticed the following: $ amadmin ks/incr force fileserv /scanner amadmin: fileserv:/scanner/plankart is set to a forced level 0 at next run. amadmin: fileserv:/scanner/golg is set to a forced level 0 at next run. amadmin: fileserv:/scanner is set to a forced level 0 at next run. Why did this happen? Shouldn't only "/scanner" be forced? (I have separate DLEs for two subdirectories indicated above; these are excluded in the "main" DLE config.) That's because the arguments are interpreted as globs: From "man amanda" (unfortunatly not a word about this in man amadmin) HOST & DISK EXPRESSION All host and disk arguments to programs are special expression. The command apply to all disk that match your arguments. This section describe the matcher. The matcher match by word, each word is a glob expression, word are separated by the separator '.' for host and '/' for disk. You can anchor the expression at left with a '^'. You can anchor the expression at right with a '$'. The matcher is case insensitive for host but is case sen-Â sitive for disk. A match succeed if all word in your expression match contiguous word in the host or disk. Ah. Right. That's of course the way I thought it looked like it worked, more or less, but since the amdump manual page mentioned nothing about it... In I didn't think to try '$' right away... Has it always been that way? I never really noticed it earlier, but I don't use the force that often... - Toralf
amadmin force matches too many disks
I just noticed the following: $ amadmin ks/incr force fileserv /scanner amadmin: fileserv:/scanner/plankart is set to a forced level 0 at next run. amadmin: fileserv:/scanner/golg is set to a forced level 0 at next run. amadmin: fileserv:/scanner is set to a forced level 0 at next run. Why did this happen? Shouldn't only "/scanner" be forced? (I have separate DLEs for two subdirectories indicated above; these are excluded in the "main" DLE config.) Amanda version 2.4.4p3. - Toralf
Re: [paul.bijnens@xplanation.com: Re: Multi-Gb dumps using tar + software compression (gzip)?]
Patrick Michael Kane wrote: If you restore a dump file to disk someplace and run "file" on it, what type of file does it tell you it is? Do you mean a "normal" amrestored'ed file, or a "raw" recovery? Actually, I have examples of both: # file fileserv._scanner2_Hoyde.20041008.6 fileserv._scanner2_Hoyde.20041008.6: GNU tar archive # file fileserv._scanner2_Hoyde.20041006.0 fileserv._scanner2_Hoyde.20041006.0: AMANDA dump file, DATE 20041006 fileserv /scanner2/Hoy But of course the output would be what you expected for valid dump files, since they are *mostly* OK. Like I said earlier, tar extract (or list) on the files starts off right, and if I look at the (uncompressed) files starting at the end, I also find valid tar file entries. If looks like the files have section(s) of corrupt data "in the middle", however. I don't know any way to find out exactly where the error occurs, or what is wrong with the data. Or I know where tar gets into trouble for each of the files, of course, but I don't know how to find the corresponding compressed data, or its offset within the dump. - Toralf - Forwarded message from Paul Bijnens <[EMAIL PROTECTED]> - From: Paul Bijnens <[EMAIL PROTECTED]> To: Toralf Lund <[EMAIL PROTECTED]> Cc: Amanda Mailing List <[EMAIL PROTECTED]> Subject: Re: Multi-Gb dumps using tar + software compression (gzip)? Date: Wed, 20 Oct 2004 13:59:31 +0200 Message-ID: <[EMAIL PROTECTED]> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 Toralf Lund wrote: Other possible error sources that I think I have eliminated: 1. tar version issues - since gzip complains even if I just uncopress and send the data to /dev/null, or use the -t option. 2. Network transfer issues. I get errors even with server compression, and I'm assuming gzip would produce consistent output even if input data were garbled due to network problems. 3. Problems with a specific amanda version. I've tried 2.4.4p1 and 2.4.4p3. Results are the same. 4. Problems with a special disk. I've tested more than one, as target for "file" dumps as well as holding disk. 5. Hardware errors, e.g. in bad RAM (on a computer without ECC), or disk controller, or cables. If one single bit is flipped, then gzip produces complete garbage from that point on. Maybe you're only seeing it in such large backups with gzip, but it happens (less often) in other cases too. Any tools available to test the hardware?
Re: Multi-Gb dumps using tar + software compression (gzip)?
Paul Bijnens wrote: Toralf Lund wrote: Other possible error sources that I think I have eliminated: 1. tar version issues - since gzip complains even if I just uncopress and send the data to /dev/null, or use the -t option. 2. Network transfer issues. I get errors even with server compression, and I'm assuming gzip would produce consistent output even if input data were garbled due to network problems. 3. Problems with a specific amanda version. I've tried 2.4.4p1 and 2.4.4p3. Results are the same. 4. Problems with a special disk. I've tested more than one, as target for "file" dumps as well as holding disk. 5. Hardware errors, e.g. in bad RAM (on a computer without ECC), or disk controller, or cables. If one single bit is flipped, then gzip produces complete garbage from that point on. Good point. The data isn't compeletely garbled, though; closer inspection reveals that the uncompressed data actually have valid tar file entries after the failure point. In other words, it looks like only limited sections within the file are corrupted. Also, I believe it's not the disk controller, since I've even tried dumping to NFS volumes (but maybe that raises other issues.) Maybe you're only seeing it in such large backups with gzip, but it happens (less often) in other cases too. Any tools available to test the hardware? I have one of those stand-alone test software packages... Yes. Maybe I should run it. I can't just take the server down right now, though ;-( - Toralf
Re: Multi-Gb dumps using tar + software compression (gzip)?
Gene Heskett wrote:
On Tuesday 19 October 2004 11:10, Paul Bijnens wrote:
Michael Schaller wrote:
I found out that this was a problem of my tar.
I backed up with GNUTAR and "compress server fast".
AMRESTORE restored the file but TAR (on the server!) gave some
horrible messages like yours.
I transferred the file to the original machine ("client") and all
worked fine.
I guess this is a problem of different tar versions ...
That's strange and freightening! Tar is supposed to be a portable
format! Especially gnutar -- there are indeed differences with
normal OS-supplied tar formats, but only to overcome limits in
filesize, path name length etc.; but the same version of gnutar on
different architectures should be able to read each others files.
I'm not 100% sure what happens if you compile tar on an architecture
without largefile support on and try to restore a file exceeding
such a limit.
Are you sure you used the correct version of tar. I've called mine
"gtar" to avoid confusion with the OS-supplied tar (actually, amanda
even uses "amgtar", which is a link to the correct version, or a
wrapper that does some pre/post processing if needed on e.g.
database DLE's).
We probably should point out to the new bees here, that tar-1.13 is
indeed broken. In other words, if your "tar --version" doesn't
report that its at least 1.13-19, it may not, and probably is not,
compatible with anything but itself. (and I'm not sure that 1.13
could even recover its own output!)
I hate to be boreing and repetitive, but there are those here *now*
who did not go thru that period of hair removal that 1.13 caused.
Yep.
But how about gzip? Any known issues there? I think I've ruled out
problems with one particular gzip version since I've tried server as
well as client compression, where the client has a different gzip
version from the server (and I've tried using both for recovery, too),
but if a range of releases has a problem...
Other possible error sources that I think I have eliminated:
1. tar version issues - since gzip complains even if I just uncopress
and send the data to /dev/null, or use the -t option.
2. Network transfer issues. I get errors even with server
compression, and I'm assuming gzip would produce consistent output
even if input data were garbled due to network problems.
3. Problems with a specific amanda version. I've tried 2.4.4p1 and
2.4.4p3. Results are the same.
4. Problems with a special disk. I've tested more than one, as target
for "file" dumps as well as holding disk.
- Toralf
Re: Multi-Gb dumps using tar + software compression (gzip)?
Michael Schaller wrote:
Hi Toralf,
I'v had nearly the same problem this week.
I found out that this was a problem of my tar.
I backed up with GNUTAR and "compress server fast".
AMRESTORE restored the file but TAR (on the server!) gave some
horrible messages like yours.
I transferred the file to the original machine ("client") and all
worked fine.
I guess this is a problem of different tar versions ...
Do you made your tests on the client or on the server??
If the answer is "server" then transfer the restored archive to your
client and untar there!!
I've tried both. In fact, I've tested just about every combination of
tar, gzip, filesystems, hosts, recovery sources (tape, disk dump,
holding disk...) etc. I could think of, and I always get the same result.
I'm thinking this can't possibly be a tar problem, though, or at least
not only that, since gzip reports errors, too. I get
dd if=00010.raid2._scanner4.7 bs=32k skip=1 | gzip -t
124701+0 records in
124701+0 records out
gzip: stdin: invalid compressed data--crc error
gzip: stdin: invalid compressed data--length error
Greets
Michael
Toralf Lund schrieb:
Since I'm still having problems gunzip'ing my large dumps - see
separate thread, I was just wondering:
Some of you people out there are doing the same kind of thing, right?
I mean, have
1. Dumps of directories containing several Gbs of data (up to roughly
20Gb compressed in my case.)
2. Use dumptype GNUTAR.
3. Compress data using "compress client fast" or "compress server
fast".
If you do, what exactly are your amanda.conf settings? And can you
actually extract *all* files from the dumps?
- Toralf
Re: Multi-Gb dumps using tar + software compression (gzip)?
Alexander Jolk wrote: Joshua Baker-LePain wrote: I think that OS and utility (i.e. gnutar and gzip) version info would be useful here as well. True, forgot that. I'm on Linux 2.4.19 (Debian woody), using GNU tar 1.13.25 and gzip 1.3.2. I have never had problems recovering files from huge dumps. I'm using Red Hat Linux 9 with kernel version 2.4.20 on the server, and I have clients running Linux and SGI IRIX (version 6.5.16f). tar version is 1.13.25 on both platforms; gzip is 1.3.3 on Linux, 1.2.4a on IRIX. I'm mainly having problems with IRIX clients since that's where the large filesystems are connected. These get corrupted with server as well as client compression, i.e. I've tried both gzip versions. Alex
Re: how to automate tape changing
Paul Bijnens wrote: Jukka Salmi wrote: Paul Bijnens --> amanda-users (2004-10-18 22:14:10 +0200): Before the chg-disk tape changer was written, I used the chg-multi changer with the file-driver. It's a little more complicated to configure, but the advantage is that it finds and load automatically the vtapes. To what extent (with regard to functionality) does this differ from using chg-disk and setting amrecover_changer to the same value as tapedev? Just tried this out with the chg-disk changer instead of the chg-multi and it works fine indeed. Don't know why I thought it wouldn't. One remark about amrecover_changer: because a changer does not have a name in /dev (especially the chg-disk, or the chg-multi changer), amanda introduced the "amrecover_changer" parameter to name your changer. My changer is called: amrecover_changer "changer" . Some people (distro's even) call it /dev/null, some the same as an existing tapedevice. Personally I find that confusing. Yes. Personally I'm using the following parameters for a config that dumps to disk (using chg-multi): tpchanger "chg-multi" changerfile "chg-multi.conf" tapedev "changer" rawtapedev "/dev/null" amrecover_changer "changer" amrecover_check_label yes The values I posted earlier were actually for a real tape changer setup. - Toralf
Re: Multi-Gb dumps using tar + software compression (gzip)?
Alexander Jolk wrote: Toralf Lund wrote: 1. Dumps of directories containing several Gbs of data (up to roughly 20Gb compressed in my case.) 2. Use dumptype GNUTAR. 3. Compress data using "compress client fast" or "compress server fast". If you do, what exactly are your amanda.conf settings? And can you actually extract *all* files from the dumps? Yes, I'm doing this, and I've never had problems recovering all files, just once when the tape was failing. Good... I'll send you my amanda.conf privately. OK. Thanks. I don't right a way see any significant differences from what I'm doing, but I'll study it closer... Oh, there is one thing, by the way: I notice that you use "chunksize 1Gb" - and so do I, right now, but for a while the holding disk data wasn't split into chunks at all, and I've been wondering if that may have been the problem. BTW which version are you using? I'm at version 2.4.4p1-20030716. I've used the "release" version of 2.4.4p1 for some time, but I'm testing 2.4.4p3 right now. (I'm doing roughly 500GB a night on two sites, one of them has dumps up to 80GB compressed, and takes a little less than 24h to finish, after my exclude lists have been adapted.) Alex
Multi-Gb dumps using tar + software compression (gzip)?
Since I'm still having problems gunzip'ing my large dumps - see separate thread, I was just wondering: Some of you people out there are doing the same kind of thing, right? I mean, have 1. Dumps of directories containing several Gbs of data (up to roughly 20Gb compressed in my case.) 2. Use dumptype GNUTAR. 3. Compress data using "compress client fast" or "compress server fast". If you do, what exactly are your amanda.conf settings? And can you actually extract *all* files from the dumps? - Toralf
Re: how to automate tape changing
Jukka Salmi wrote: Hi, I'm using the chg-disk tape changer. When restoring files using amrecover, after adding some files and issuing the extract command, amrecover tells me what tapes are needed, and asks me to "Load tape now". I load the needed tape using amtape, and tell amrecover to continue. After a while I'm promted to load another tape, and so on... Is it possible to automate the process of loading the needed tapes? Yes. I'm using the following tape device setup to do this: tpchanger "chg-zd-mtx" tapedev "/dev/nrtape" rawtapedev "/dev/tape" changerfile "chg-mtx" changerdev "/dev/changer" amrecover_changer "/dev/nrtape" amrecover_do_fsf yes amrecover_check_label yes It's amrecover_changer that does the trick; essentially it tells amrecover to use the tape changer or the tape device is set to /dev/nrtape. That's not very important, but maybe "nice to have". TIA, Jukka
Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)
Toralf Lund wrote: Alexander Jolk wrote: Toralf Lund wrote: [...] I get the same kind of problem with harddisk dumps as well as tapes, and as it now turns out, also for holding disk files. And the disks and tape drive involved aren't even on the same chain. Actually, I'm starting to suspect that gzip itself is causing the problem. Any known issues, there? The client in question does have a fairly old version, 1.2.4, That rings a bell somewhere. Hasn't there been once a report on this list from someone whose zipped backups got corrupted at every (other) GB mark? Something with chunks on the holding disk having a header that didn't get stripped off when writing to tape? That would of course explain a lot. I wasn't able to find anything on this in the mailing list archives, though, and I haven't been able to identify header data (except for the one at the start) within the dump files, but of course, these are a bit difficult to work with, and I may have looked in the wrong place or for the wrong thing. I've now tested a bit more, and while it may be too early to draw conclusions, I'm starting to suspect that it's actually *not* splitting up into chunk that leads to trouble. I've now changed from no chunksize specification to "chunksize 1Gb", and everything looks more promising. Actually, I did get a crc error from gzip when trying to unpack a dump file created via this setup, too, but that was after all files had been extracted (according to the amanda index), and there was no tar error. BTW, the manual seems to be wrong in this respect; it says that default value for chunksize is 1 Gb, but it actually is 0 (meaning no max size.) Question: Do you know if I can get gzip to report where exactly the mismatch is found? I'd still like to know that. Anybody remember which version had this problem, and whether that gave the same symptoms? Alex
Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)
Alexander Jolk wrote: Toralf Lund wrote: [...] I get the same kind of problem with harddisk dumps as well as tapes, and as it now turns out, also for holding disk files. And the disks and tape drive involved aren't even on the same chain. Actually, I'm starting to suspect that gzip itself is causing the problem. Any known issues, there? The client in question does have a fairly old version, 1.2.4, That rings a bell somewhere. Hasn't there been once a report on this list from someone whose zipped backups got corrupted at every (other) GB mark? Something with chunks on the holding disk having a header that didn't get stripped off when writing to tape? That would of course explain a lot. I wasn't able to find anything on this in the mailing list archives, though, and I haven't been able to identify header data (except for the one at the start) within the dump files, but of course, these are a bit difficult to work with, and I may have looked in the wrong place or for the wrong thing. Question: Do you know if I can get gzip to report where exactly the mismatch is found? Anybody remember which version had this problem, and whether that gave the same symptoms? Alex
Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)
The fun part here is that I have two different tars and two different gzips - the ones supplied with the OS and "SGI freeware" variants installed on /usr/freeware (dowloaded from http://freeware.sgi.com/) Do not use the OS supplied tar! You'll hit a bug. Yes. I do seem to remember that I took care to make sure it wouldn't be used, when I installed Amanda. I've installed the freeware version a while ago (GNU tar) 1.13.25 without an itch along with /usr/sbin/gzip. Both incarnations of gzip return the same version string as the one you included above /usr/freeware/bin/tar is tar (GNU tar) 1.13.25 Not sure how to get version string from /usr/bin/tar, but I have # uname -R 6.5 6.5.16f Based on the dump file headers, I would assume that /usr/freeware variants are used for both tar and gzip. Actually, maybe that one is *required* by Amanda, since it wants GNU tar, and the one on /usr/bin is not, as far as I can tell. Perhaps there wasn't really any point in installing "freeware" version of gzip, or will Amanda make assumptions about binary locations? Check your amandad debug files and look at the paths and defs Good idea. I should also be able to find the actual build setup, but this one seems easier... It looks like /usr/freeware/bin/tar and /usr/freeware/bin/gzip are used - see below. Notice, however, that I've now tried some dumps with "compress server", and I can actually reproduce the problem on those, so if it's a gzip problem, it must be one that's common to multiple versions and platforms. The one on the server is gzip-1.3.3-9 from Red Hat. and check for GNUTAR="/usr/freeware/bin/tar" , COMPRESS_PATH="/usr/sbin/gzip" and UNCOMPRESS_PATH="/usr/sbin/gzip" Mine has: amandad: paths: bindir="/opt/amanda/amanda2/bin" amandad:sbindir="/opt/amanda/amanda2/sbin" amandad:libexecdir="/opt/amanda/amanda2/libexec" amandad:mandir="/opt/amanda/amanda2/man" amandad:AMANDA_TMPDIR="/tmp/amanda-conf2" amandad:AMANDA_DBGDIR="/tmp/amanda-conf2" amandad:CONFIG_DIR="/opt/amanda/amanda2/etc/amanda" amandad:DEV_PREFIX="/dev/dsk/" RDEV_PREFIX="/dev/rdsk/" amandad:DUMP="/sbin/dump" RESTORE="/sbin/restore" VDUMP=UNDEF amandad:VRESTORE=UNDEF XFSDUMP="/sbin/xfsdump" amandad:XFSRESTORE="/sbin/xfsrestore" VXDUMP=UNDEF VXRESTORE=UNDEF amandad:SAMBA_CLIENT=UNDEF GNUTAR="/usr/freeware/bin/tar" amandad:COMPRESS_PATH="/usr/sbin/gzip" amandad:UNCOMPRESS_PATH="/usr/sbin/gzip" LPRCMD="/usr/bsd/lpr" amandad:MAILER="/usr/sbin/Mail" amandad: listed_incr_dir="/opt/amanda/amanda2/var/amanda/gnutar-lists" amandad: defs: DEFAULT_SERVER="bullcalf" DEFAULT_CONFIG="stk_40-conf2" amandad:DEFAULT_TAPE_SERVER="bullcalf" amandad:DEFAULT_TAPE_DEVICE="/hw/tape/tps12d2nrnsv" HAVE_MMAP amandad:HAVE_SYSVSHM LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" amandad:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" Mine is: amandad: paths: bindir="/usr/freeware/bin" sbindir="/usr/freeware/bin" amandad:libexecdir="/usr/freeware/libexec" amandad:mandir="/usr/freeware/man" AMANDA_TMPDIR="/tmp/amanda" amandad:AMANDA_DBGDIR="/tmp/amanda" amandad:CONFIG_DIR="/usr/freeware/etc/amanda" amandad:DEV_PREFIX="/dev/dsk/" RDEV_PREFIX="/dev/rdsk/" amandad:DUMP="/sbin/dump" RESTORE="/sbin/restore" amandad:XFSDUMP="/sbin/xfsdump" XFSRESTORE="/sbin/xfsrestore" amandad:GNUTAR="/usr/freeware/bin/tar" amandad:COMPRESS_PATH="/usr/freeware/bin/gzip" amandad:UNCOMPRESS_PATH="/usr/freeware/bin/gzip" amandad:MAILER="/usr/sbin/Mail" amandad:listed_incr_dir="/usr/freeware/var/lib/amanda/gnutar-lists" amandad: defs: DEFAULT_SERVER="localhost" DEFAULT_CONFIG="DailySet1" amandad:DEFAULT_TAPE_SERVER="localhost" amandad:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" amandad:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" amandad: time 0.002: got packet: HTH jf
Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)
Gene Heskett wrote: On Wednesday 13 October 2004 11:07, Toralf Lund wrote: Jean-Francois Malouin wrote: [ snip ] Actually, I'm starting to suspect that gzip itself is causing the problem. Any known issues, there? The client in question does have a fairly old version, 1.2.4, I think (that's the latest one supplied by SGI, unless they have upgraded it very recently.) Honestly, I missed the earlier post in this thread... Which version of tar are you using? I've used the SGI provided gzip for a long time and never experienced that behaviour... #~> /usr/sbin/gzip -h gzip 1.2.4 (18 Aug 93) #~> uname -R 6.5 6.5.19f [...snip...] The fun part here is that I have two different tars and two different gzips - the ones supplied with the OS and "SGI freeware" variants installed on /usr/freeware (dowloaded from http://freeware.sgi.com/) Both incarnations of gzip return the same version string as the one you included above /usr/freeware/bin/tar is tar (GNU tar) 1.13.25 Not sure how to get version string from /usr/bin/tar, but I have # uname -R 6.5 6.5.16f Based on the dump file headers, I would assume that /usr/freeware variants are used for both tar and gzip. Actually, maybe that one is *required* by Amanda, since it wants GNU tar, and the one on /usr/bin is not, as far as I can tell. Perhaps there wasn't really any point in installing "freeware" version of gzip, or will Amanda make assumptions about binary locations? - T jf You can tell amanda in the ./configuration options given, where the correct tar actually lives and it will be hardcoded into it. And to get the version from the other tar, "/usr/bin/tar --version" should work, Nope. This is not GNU tar at all. But I'm fairly sure it isn't used... and if its not 1.13-19 or newer, use the other one that is -25 on your system. Also, the gzip here is 1.3.3, dated in 2002. There may have been fixes to it, probably in the >2GB file sizes areas. Ahem. If >2GB data is or has been a problem, then I'm definitely doomed, since Amanda dumps tend to get a lot larger than that (on our systems, and I would assume, also in general.)
Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)
Jean-Francois Malouin wrote: [ snip ] Actually, I'm starting to suspect that gzip itself is causing the problem. Any known issues, there? The client in question does have a fairly old version, 1.2.4, I think (that's the latest one supplied by SGI, unless they have upgraded it very recently.) Honestly, I missed the earlier post in this thread... Which version of tar are you using? I've used the SGI provided gzip for a long time and never experienced that behaviour... #~> /usr/sbin/gzip -h gzip 1.2.4 (18 Aug 93) #~> uname -R 6.5 6.5.19f [...snip...] The fun part here is that I have two different tars and two different gzips - the ones supplied with the OS and "SGI freeware" variants installed on /usr/freeware (dowloaded from http://freeware.sgi.com/) Both incarnations of gzip return the same version string as the one you included above /usr/freeware/bin/tar is tar (GNU tar) 1.13.25 Not sure how to get version string from /usr/bin/tar, but I have # uname -R 6.5 6.5.16f Based on the dump file headers, I would assume that /usr/freeware variants are used for both tar and gzip. Actually, maybe that one is *required* by Amanda, since it wants GNU tar, and the one on /usr/bin is not, as far as I can tell. Perhaps there wasn't really any point in installing "freeware" version of gzip, or will Amanda make assumptions about binary locations? - T jf
Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)
Alexander Jolk wrote: Toralf Lund wrote: tar: Skipping to next header tar: Archive contains obsolescent base-64 headers 37800+0 records in 37800+0 records out gzip: stdin: invalid compressed data--crc error tar: Child returned status 1 tar: Error exit delayed from previous errors I've had the same message from tar on what were apparently erroneous backups. I believe the `obsolescent base-64 header' message is what you get whenever tar's input is corrupted, which seems to be confirmed by gzip's `crc error'. I was hoping you wouldn't say that ;-( But yes, I guess it's likely that the actual backup is corrupted. I'd venture to say your backups are hosed; if that arrives systematically, you might want to investigate your SCSI chain. Well, yes, I've now found that I do get this for different dump files (but not all of them), so I guess some serious problem with the setup is likely. I don't think SCSI-issues is likely to be the cause, though, since I get the same kind of problem with harddisk dumps as well as tapes, and as it now turns out, also for holding disk files. And the disks and tape drive involved aren't even on the same chain. Actually, I'm starting to suspect that gzip itself is causing the problem. Any known issues, there? The client in question does have a fairly old version, 1.2.4, I think (that's the latest one supplied by SGI, unless they have upgraded it very recently.) Also, to my great relief, it turned out that I could actually extract most of the files I wanted by skipping over the error point via dd skip=... tar still gave me warnings when I did this (unsurprisingly enough since the data was probably not aligned to a file boundary after the skip), but this time it was actually able to find files after it did. Based on this, I'm thinking that the original tar should at least have been able to resync itself. Any ideas why it didn't? (Sacrificed a goat lately?) Apparently not... - T
tar/gzip problems on restore (CRC error, "Archive contains obsolescent base-64 headers"...)
I'm having serious problems with full restore of a GNUTAR dump. Simply put, if I do amrestore, then tar xvf , tar will exit with tar: Skipping to next header tar: Archive contains obsolescent base-64 headers tar: Error exit delayed from previous errors after extracting most, but not all, files - if the amanda index is anything to go by. There is a significant delay between the two first and last error messages, which leads me to believe that there is more data, but tar just doesn't understand it. I get the same behaviour if I extract files using amrecover instead of amrestore + tar. Also, I actually have two dumps of the filesystem in question: One on tape and one on harddisk (well, I have more than one tape, too, but the others are stored elsewhere.) Both fail in the manner described above, but at different points. Also notice the following behaviour when unpacking the harddisk dump in a more direct manner: # dd if=/dumps/mirror/d4/data/00013.fileserv._scanner2_Hoyde.6 bs=32k skip=1 | tar -xvpzkf - [ file extract info skipped ] tar: Skipping to next header tar: Archive contains obsolescent base-64 headers 37800+0 records in 37800+0 records out gzip: stdin: invalid compressed data--crc error tar: Child returned status 1 tar: Error exit delayed from previous errors All this with amanda 2.4.4p1 with server on Linux and clients on SGI IRIX as well as Linux; I've tried unpacking on both platforms. HELP - Toralf
includefile directive?
Is anyone here using the "includefile" directive in their config? How exactly does it work? Does it apply to all config files, or just amanda.conf? What can the file contain - full config info, or just whatever is not set in the file including it? If I have two configs, can I have one amanda.conf include the other and override some of the params, or is it better to let both include a 3rd file (or several different files for the different sections)? - Toralf
Moving data index data etc. from one config to andother
Following our recent reorg of amanda configs, I've considered moving some data from index, curinfo and possibly the log of one config to the datadirs of another. The object would be to make amrecover think that certain tapes were written using this other config, although they were really dumped by the first one. Has anyone tried this? Will it work at all, and if it does, what exactly do I need to include? - Toralf
Re: More than one tape per run
Paul Bijnens wrote: Toralf Lund wrote: Ah, I see. So it won't actually multiply tape size by runtapes when trying to figure out how much it can write... I'm not sure the functionaltiy is of much use to me then, but perhaps I could cheat and pretend the tapes are "runtapes" times larger than they really are? Maybe I missed something in this discussion, but Amanda does indeed multiply the size by runtapes to measure the total capacity. I asked what exactly the behaviour would be when setting e.g 'runtapes 2'. The answer I got was that Amanda would still distribute data as usual (i.e. as if runtapes were set to 1), but go on writing another tape if a run's data didn't fit on one tape after all (i.e. the estimate was wrong.) Or at least, that was how I interpreted it... There is only the restriction that one single DLE still has to fit on one tape. I knew that all along, of course... I think it will buy me the ability to write, say, 4 tapes in 2 runs (2 in each run.) I can think of no other way to do that (given the information that amanda will schedule only one tape's worth of data even if I set runtapes to 2 or more.) I'm not saying that this is necessarily something I want to do, though. That's exactly what it will buy you, yes indeed. But no, it's not true that amanda will schedule only one tape's worth of data when you set runtapes to 2. Amanda actually schedules just as much to spread all dumps evenly over the dumpcycle. i.e. the date is distributed evenly across * tapes? That makes more sense, of course. If you dumpcyccle is too large, maybe she won't reach the capacity of one tape, even if you specified runtapes > 1. If she hits a capacity limit (one tape or runtapes times one tape) she will complain loud, but will to put as much as possible on the limited capacity. Another option I've been thinking about (again, if I decide I want to write several tapes in one go) is simply to start another amdump once the first is finished. I'm not sure if that's a idea either, though, since amanda seems to be geared towards one run a day, and it will probably increase overall backup time because dumps can't be parallelised between the two runs. And you get a lot of incrementals / fulls done twice. There aren't any incrementals (we are talking about an "archival" type of setup.) Are you saying that the same dumps will always be scheduled again if I run another time on the same day? - Toralf
Re: More than one tape per run
Ah, I see. So it won't actually multiply tape size by runtapes when trying to figure out how much it can write... I'm not sure the functionaltiy is of much use to me then, but perhaps I could cheat and pretend the tapes are "runtapes" times larger than they really are? Won't buy you anything. Amanda will reach the actual end of the tape and not be able to go on to a second tape because runtapes is 1. What I meant was set, say, length (in tape config) = 2* *and* runtapes = 2. Lying to amanda is not nice :) No, it's probably a bad idea in most cases. And again won't buy you anything. I think it will buy me the ability to write, say, 4 tapes in 2 runs (2 in each run.) I can think of no other way to do that (given the information that amanda will schedule only one tape's worth of data even if I set runtapes to 2 or more.) I'm not saying that this is necessarily something I want to do, though. Hypothetical, 1 DLE, 1.5GB, a tape with an actual capacity of 1.0GB. You set tape length to 1GB and runtapes to 1. Amanda notes the impossibility of taping this and may refuse to do a level 0. You leave tape length to 1GB and runtapes to 6. Amanda continues to note the impossibility of taping that DLE. You lie and set tape length to 2.0GB and runtapes to anything, but say 3. Amanda does the dump of 1.5GB but hits end of tape (EOT) at 1.0GB. It thinks there might have been a tape error because the admin said the tape was 2.0GB so it tries the allowed tape 2 by starting to tape the dump from the beginning. And hits EOT again. The same error is encountered on every tape you allow amanda to use. You waste tons of taping time doing an impossible task; fitting a 1.5GB dump into a 1.0GB box. I don't think this is very relevant, though. I think I can safely assume that any DLE will fit on a (real) tape; that's the way the disklist is set up. If one doesn't at a given time, it will be fairly easy to tell from the amdump output and make the appropriate adjustments to the setup. And the fact that this one run will spend some extra time trying (and failing) to write data isn't that much of an issue. Another option I've been thinking about (again, if I decide I want to write several tapes in one go) is simply to start another amdump once the first is finished. I'm not sure if that's a idea either, though, since amanda seems to be geared towards one run a day, and it will probably increase overall backup time because dumps can't be parallelised between the two runs. - Toralf
Re: More than one tape per run
On Thu, Oct 23, 2003 at 05:37:02PM +0200, Toralf Lund wrote: runspercycle does not need to be changed. The "runtapes" means that for each run up to that number of tapes may be used (note: not "must"). You have to increase your tapecycle probably to cover the same dumpcycle(s), because you'll burn twice as much tapes for each run. (well, "burn", hopefully not litteraly). I'm still not sure I understand. If I have runspercycle 2 and runtapes 2 will amanda try to distribute the full dumps across 4 tapes, or just 2? When I think about it, the first answer makes most sense, as the parameter otherwise ought to have been called "tapespercycle". "Sense" is a funny thing. Amanda will "try" to fit each run on a single tape. But will use a second tape during that run if necessary. Ah, I see. So it won't actually multiply tape size by runtapes when trying to figure out how much it can write... I'm not sure the functionaltiy is of much use to me then, but perhaps I could cheat and pretend the tapes are "runtapes" times larger than they really are? Won't buy you anything. Amanda will reach the actual end of the tape and not be able to go on to a second tape because runtapes is 1. What I meant was set, say, length (in tape config) = 2* *and* runtapes = 2. [ ... ] Total data, yes. Data per DLE, no. Because amanda can not deal with individual DLE's larger than a single tape capacity. But it will happily put 10 DLE's on the first tape, 20 on the second and 4 on the third if that is what fits, is needed, and runtapes is >= 3. Yes, I knew that, of course. But actually, one of the reasons why I'm asking about runtapes > 1 is that I've considered setting up so that everything is dumped in one run... Assuming that each individual DLE, when given a level 0, fits on a single tape, then set dumpcycle = 0, runspercycle = 1, and runtapes = 1000. It seems to me that Amanda will *not* try split data evenly between tapes like it normally would, with a setting like this. I'm not sure I mind, though. - Toralf
Re: More than one tape per run
runspercycle does not need to be changed. The "runtapes" means that for each run up to that number of tapes may be used (note: not "must"). You have to increase your tapecycle probably to cover the same dumpcycle(s), because you'll burn twice as much tapes for each run. (well, "burn", hopefully not litteraly). I'm still not sure I understand. If I have runspercycle 2 and runtapes 2 will amanda try to distribute the full dumps across 4 tapes, or just 2? When I think about it, the first answer makes most sense, as the parameter otherwise ought to have been called "tapespercycle". "Sense" is a funny thing. Amanda will "try" to fit each run on a single tape. But will use a second tape during that run if necessary. Ah, I see. So it won't actually multiply tape size by runtapes when trying to figure out how much it can write... I'm not sure the functionaltiy is of much use to me then, but perhaps I could cheat and pretend the tapes are "runtapes" times larger than they really are? Thus the answer is "it depends". It will try to use 2 tapes, but may use 3 or 4. BTW I find it strange that an "archival" configuration would be setup with a dumpcycle > 0 (or 1?) and with runspercycle > 1. When I want an archive dump I want it to be the state of the system now. Not the current state of half the DLE's and incrementals from the last 'archive' of the other half. Maybe that is just me ;) The archival config disables incrementals, obsiously. And *of course* I have to split the backup across several tapes; isn't the data in any real setup larger than what fits on a tape? But actually, one of the reasons why I'm asking about runtapes > 1 is that I've considered setting up so that everything is dumped in one run... - Toralf
Re: More than one tape per run
Paul Bijnens wrote: Toralf Lund wrote: I'm thinking about using more than one tape, i.e. set "runtapes" parameter to a value > 1, for my updated archival setup. Is there anything special I need to keep in mind when doing this? Also, how do I set up runspercycle in this case? Is it the total number of tapes runspercycle * runtapes, or just runspercycle? runspercycle does not need to be changed. The "runtapes" means that for each run up to that number of tapes may be used (note: not "must"). You have to increase your tapecycle probably to cover the same dumpcycle(s), because you'll burn twice as much tapes for each run. (well, "burn", hopefully not litteraly). I'm still not sure I understand. If I have runspercycle 2 and runtapes 2 will amanda try to distribute the full dumps across 4 tapes, or just 2? When I think about it, the first answer makes most sense, as the parameter otherwise ought to have been called "tapespercycle". The parameter "taperalgo largestfit" will help to fill the first tape(s) to 100%. (New since amanda 2.4.3.) I'm using that already. This works better when also using: dumporder "SS" # as many S's as you have dumpers (or use "TT", which is a good approximation of , but optimises the total runtime of your backups better; I use T). For a complete explanation why this works better, see: http://groups.yahoo.com/group/amanda-users/message/46327 This is very helpful indeed. Thanks. I've been wondering how I might avoid having the largest image left on the holding disk when the total size is only just larger than the tape (like you say, taperalgo often doesn't help), but never noticed this parameter, or the message you are referring to. -- - Toralf
More than one tape per run
I'm thinking about using more than one tape, i.e. set "runtapes" parameter to a value > 1, for my updated archival setup. Is there anything special I need to keep in mind when doing this? Also, how do I set up runspercycle in this case? Is it the total number of tapes runspercycle * runtapes, or just runspercycle? - Toralf
How to handle archival runs (again)?
Reviewing the amanda config again in conjunction with a tape format update... I forget (and list search doesn't return anything conclusive): How do you people recommend handling archival runs? There are two obvious ways: 1. Via a special config. 2. Using the normal config, but special labels and "amadmin ... no-reuse" What are the pros and cons of each of these? Note: I know that one argument against 2) is that you normally want different behaviour with regard to incrementals, but that doesn't really apply in my case as there are no incrementals in any case (in the main config; I have a separate one for incrementals as they are written to a different medium.) - Toralf
tapecycle: Are "no-reuse" tapes counted?
It looks like Amanda will count *all* tapes written after the tape in question, even the ones marked as "no-reuse", when comparing count with tapecycle to determine if a tape may be overwritten. Is this observation correct? Should "no-reuse" tapes be included like that? -- Toralf
amrecover: Why does it use disklist and log files
As far as I can't tell, amrecover won't work unless 1. Log file from the backup you are trying to recover is still present 2. DLE is still in the disklist Why? Shouldn't amrecover work from the index alone? - Toralf
Re: Snapshot vs. -p1 (was Re: Lot's of I/O errors)
Eric Siegerman wrote: On Mon, Jul 14, 2003 at 11:07:10AM +0200, Toralf Lund wrote: I've been getting a lot of *** A TAPE ERROR OCCURRED: [[writing file: I/O error]]. On Mon, Jul 14, 2003 at 01:44:26PM +0200, Toralf Lund wrote: Note that I've now gone back to amanda-2.4.4, and successfully flushed some images that caused trouble in the past. I think an important question here is whether something related to the holding disk handling or taping of images has changed since 2.4.4. Did you ever learn anything more about this? I'd like to upgrade from 2.4.4 to -p1 or the latest snapshot, but I'd appreciate your thoughts first -- and those of anyone else who cares to speak up. I didn't really find out what happened. I actually moved the tape changer to a different host, which I was going to do anyway, and after that it all worked fine. Based on that, it's fair to assume that there was a problem with my SCSI bus, but I'm fairly sure the error messages started occurring after the upgrade. That may have been a coincidence, but the reason might also be that -p1 stresses the SCSI subsystem a bit harder, or checks closer if everything works all right. -- - Toralf
Re: Files left on holding disk after successful dumps
On Thursday 14 August 2003 03:21, Toralf Lund wrote: >> On Wednesday 13 August 2003 02:55, Toralf Lund wrote: >> >I suddenly realised that I have a lot of dump directories on my >> > holding disk, even though dumps have generally been successful. >> > The below "amflush" output should illustrate this. >> > >> > >> >-sh-2.05b$ /usr/sbin/amflush ks >> >Scanning /dumps/amanda/hd... >> >> And they're all zero length files?? >> >> I'd assume that /dumps itself is also owned by amanda:disk? >> In which case I've NDI Toralf. Delete them and see if they come >> back. >> >> Is there anything odd in this mornings report for the dle's >> mentioned? > >Ahem... I guess I didn't check "FAILURE AND STRANGE DUMP SUMMARY" > well enough. The thing is, I expect it to contain *some* entries > because we also try to back up laptops etc. that aren't always on > the net (these will be backed up whenever they are connected > overnight, which is good enough.) Sorry. :) >Anyhow, I actually get data timeout for some, if not all, of the > DLEs, i.e. I have > >fileserv /var/www lev 0 FAILED [data timeout] > >That might explain a great deal, I suppose. I don't understand why I > get the timeouts, though. Note in particular that other disks on > the same host are backed up successfully during the same run. Also, > shouldn't the holding disk be cleaned up when dumps fail like this? > >And all this started happening quite suddenly (or so it seems) while > I was on holiday, but I'm somehow not surprised by that... I moved > the amanda server (and tape drives) from one host to another some > time before that, but I *think* everything worked correctly after > that (I'm fairly sure that e.g. fileserv:/var/www has been backed > up a number of times after the move.) Well, my old slow firewall needs a dtimeout of 1800 to get rid of that error when it has to gzip a 2.9 gig /usr/src, so you may want to increment that. I inserted dtimeout 3600 and last night's backup completed without any timeouts. I guess I'll just leave it like that for now, and remove the holding disk dirs. I still don't think those should have been there, though; the holding disk ought to be cleaned up after a data timeout... -- - Toralf
Re: NFS mounts
On Tue, Aug 12, 2003 at 04:08:47PM -0400, LaValley, Brian E wrote: > Can I list an nfs mounted disk in the disklist file? > > I only ask because I am having trouble compiling for Solaris 8. The disklist's contents don't affect compiling one way or the other. What's the specific problem you're seeing? Possibly, what he's saying is that he can't Amanda's own client-server setup because he can't get amanda up-and-running on Solaris 8. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot
Re: Files left on holding disk after successful dumps
On Wednesday 13 August 2003 02:55, Toralf Lund wrote: >I suddenly realised that I have a lot of dump directories on my > holding disk, even though dumps have generally been successful. The > below "amflush" output should illustrate this. > > >-sh-2.05b$ /usr/sbin/amflush ks >Scanning /dumps/amanda/hd... And they're all zero length files?? I'd assume that /dumps itself is also owned by amanda:disk? In which case I've NDI Toralf. Delete them and see if they come back. Is there anything odd in this mornings report for the dle's mentioned? Ahem... I guess I didn't check "FAILURE AND STRANGE DUMP SUMMARY" well enough. The thing is, I expect it to contain *some* entries because we also try to back up laptops etc. that aren't always on the net (these will be backed up whenever they are connected overnight, which is good enough.) Sorry. Anyhow, I actually get data timeout for some, if not all, of the DLEs, i.e. I have fileserv /var/www lev 0 FAILED [data timeout] That might explain a great deal, I suppose. I don't understand why I get the timeouts, though. Note in particular that other disks on the same host are backed up successfully during the same run. Also, shouldn't the holding disk be cleaned up when dumps fail like this? And all this started happening quite suddenly (or so it seems) while I was on holiday, but I'm somehow not surprised by that... I moved the amanda server (and tape drives) from one host to another some time before that, but I *think* everything worked correctly after that (I'm fairly sure that e.g. fileserv:/var/www has been backed up a number of times after the move.) - Toralf
Files left on holding disk after successful dumps
0 Aug 6 00:37 20030805/fileserv._usr_local.0.tmp -rw---1 amanda disk0 Aug 6 00:46 20030805/fileserv._u_project.0.tmp -rw---1 amanda disk0 Aug 6 01:08 20030805/fileserv._scanner3_SMA.0.tmp -rw---1 amanda disk0 Aug 6 01:11 20030805/fileserv._scanner2_Vann.0.tmp -rw---1 amanda disk0 Aug 6 01:16 20030805/fileserv._scanner_plankart.0.tmp -rw---1 amanda disk0 Aug 6 01:38 20030805/fileserv._u_people.0.tmp -rw---1 amanda disk0 Aug 6 23:36 20030806/fileserv._usr_freeware_etc_openldap.0.tmp -rw---1 amanda disk0 Aug 6 23:38 20030806/fileserv._scanner3.0.tmp -rw---1 amanda disk0 Aug 6 23:57 20030806/fileserv._scanner_golg.0.tmp -rw---1 amanda disk0 Aug 7 00:06 20030806/fileserv._archive.0.tmp -rw---1 amanda disk0 Aug 7 00:09 20030806/fileserv._usr_freeware_apache.0.tmp -rw---1 amanda disk0 Aug 7 00:28 20030806/fileserv._var_www.0.tmp -rw---1 amanda disk0 Aug 7 00:36 20030806/fileserv._usr_local.0.tmp -rw---1 amanda disk0 Aug 7 00:39 20030806/fileserv._u_project.0.tmp -rw---1 amanda disk0 Aug 7 00:58 20030806/fileserv._scanner3_SMA.0.tmp -rw---1 amanda disk0 Aug 7 01:09 20030806/fileserv._scanner_plankart.0.tmp -rw---1 amanda disk0 Aug 7 23:09 20030807/fileserv._usr_freeware_var_openldap-ldbm.0.tmp -rw---1 amanda disk0 Aug 7 23:20 20030807/fileserv._usr_freeware_etc_openldap.0.tmp -rw---1 amanda disk0 Aug 7 23:50 20030807/fileserv._scanner3.0.tmp -rw---1 amanda disk0 Aug 8 00:55 20030807/fileserv._usr_freeware_apache.0.tmp -rw---1 amanda disk0 Aug 8 01:21 20030807/fileserv._var_www.0.tmp -rw---1 amanda disk0 Aug 8 01:23 20030807/fileserv._usr_local.0.tmp -rw---1 amanda disk0 Aug 8 01:25 20030807/fileserv._u_project.0.tmp -rw---1 amanda disk0 Aug 8 01:53 20030807/fileserv._scanner_plankart.0.tmp -rw---1 amanda disk0 Aug 8 23:11 20030808/fileserv._usr_freeware_etc_openldap.0.tmp -rw---1 amanda disk0 Aug 8 23:22 20030808/fileserv._scanner3.0.tmp -rw---1 amanda disk0 Aug 8 23:27 20030808/fileserv._scanner_golg.0.tmp -rw---1 amanda disk0 Aug 8 23:42 20030808/fileserv._archive.0.tmp -rw---1 amanda disk0 Aug 8 23:52 20030808/fileserv._usr_freeware_apache.0.tmp -rw---1 amanda disk0 Aug 8 23:58 20030808/fileserv._var_www.0.tmp -rw---1 amanda disk0 Aug 9 00:12 20030808/fileserv._usr_local.0.tmp -rw---1 amanda disk0 Aug 9 00:22 20030808/fileserv._u_project.0.tmp -rw---1 amanda disk0 Aug 11 23:07 20030811/fileserv._usr_freeware_etc_openldap.0.tmp -rw---1 amanda disk0 Aug 11 23:09 20030811/fileserv._scanner3.0.tmp -rw---1 amanda disk0 Aug 11 23:21 20030811/fileserv._scanner_golg.0.tmp -rw---1 amanda disk0 Aug 11 23:37 20030811/fileserv._archive.0.tmp -rw---1 amanda disk0 Aug 11 23:40 20030811/fileserv._usr_freeware_apache.0.tmp -rw---1 amanda disk0 Aug 11 23:51 20030811/fileserv._var_www.0.tmp -rw---1 amanda disk0 Aug 12 22:23 20030812/fileserv._var_www.0.tmp -rw---1 amanda disk0 Aug 12 23:43 20030812/fileserv._usr_freeware_etc_openldap.0.tmp -rw---1 amanda disk0 Aug 12 23:49 20030812/fileserv._scanner3.0.tmp -rw---1 amanda disk0 Aug 12 23:51 20030812/fileserv._archive.0.tmp -rw---1 amanda disk0 Aug 13 00:13 20030812/fileserv._scanner_golg.0.tmp -- Toralf Lund
Re: Lot's of I/O errors...
Hi what does the /var/log/messages (or /var/adm/messages whichever) say around this time? You could have dirty heads, bad tapes or indeed a broken drive. Or something like a bad SCSI cable. As I was trying to say, there is nothing even remotely related to this problem in the system log. Also, I'm nearly 100% sure that the error is somehow linked to specific images, not the actual tapes or the tape unit as such. Note that I've now gone back to amanda-2.4.4, and successfully flushed some images that caused trouble in the past. I think an important question here is whether something related to the holding disk handling or taping of images has changed since 2.4.4. - Toralf -- Martin Hepworth Senior Systems Administrator Solid State Logic Ltd +44 (0)1865 842300 Toralf Lund wrote: I've mentioned this earlier, but not a lot came out of it: I've been getting a lot of *** A TAPE ERROR OCCURRED: [[writing file: I/O error]]. lately. This does not, however, happen all the time, and not for specific tapes, either. Also, I can't find any error messages related to the tape device in the system log etc., and I've tested the unit quite a bit, and based on that, I don't think the problem is really the *write*, but is rather related to the holding disk image read. I can't figure out how exactly, though. How do I go about finding out what exactly is wrong? Also, who wrote the above mentioned error message? I'm a bit annoyed with that person now, I must say. Why? Well, for leaving out the file name from a file related error message, of course. [ Some serious flaming omitted at this point... ] Amanda version (brought to you by Amanda version 2.4.4p1) Before that I used one of the 2.4.4 snapshots, and before that again, 2.4.4. I got the same problem with the snapshot release, but not 2.4.4 itself, I believe (so perhaps I'll downgrade...) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
Lot's of I/O errors...
I've mentioned this earlier, but not a lot came out of it: I've been getting a lot of *** A TAPE ERROR OCCURRED: [[writing file: I/O error]]. lately. This does not, however, happen all the time, and not for specific tapes, either. Also, I can't find any error messages related to the tape device in the system log etc., and I've tested the unit quite a bit, and based on that, I don't think the problem is really the *write*, but is rather related to the holding disk image read. I can't figure out how exactly, though. How do I go about finding out what exactly is wrong? Also, who wrote the above mentioned error message? I'm a bit annoyed with that person now, I must say. Why? Well, for leaving out the file name from a file related error message, of course. [ Some serious flaming omitted at this point... ] Amanda version (brought to you by Amanda version 2.4.4p1) Before that I used one of the 2.4.4 snapshots, and before that again, 2.4.4. I got the same problem with the snapshot release, but not 2.4.4 itself, I believe (so perhaps I'll downgrade...)
Re: I/O error when writing to tape
Toralf anything in the /var/log/messages file (oe where ever the file lives). Nothing related to the tape write operation there, I'm afraid... what tape info (device etc) are you using in the amanda.conf tpchanger "chg-zd-mtx" tapedev "/dev/nrtape" rawtapedev "/dev/tape" (Yep, I have a changer, too.) and do you use the same one when doing other dumps? No, I concluded that the tape drive must be all right because I could write to a different one with a different config on a different host... Seriously, though - of course I'm using the same one for the other dumps! It might also be interesting to dump the failed holding area to a different drive, but I don't have an additional unit that I can test on. Have you tried dd -ing to the device etc.. No. dd what exactly? I don't think dd'ing to the device in general is very interesting since I *know* it works. dd the exact data that fails, perhaps... -- Martin Hepworth Senior Systems Administrator Solid State Logic Ltd +44 (0)1865 842300 Toralf Lund wrote: Just got *** A TAPE ERROR OCCURRED: [[writing file: I/O error]]. during a backup run. - Must be something wrong with the tape or tape drive, I thought, but it turns out that 1. I get this error for various different tapes when trying to amflush the dump to them. 2. I can write other dumps to the same tapes. Any idea what may cause this kind of thing to happen? I'm using the 20030516 snapshot, and holding disk is # ls -lh total 17G -rw---1 amanda disk 1.0G Jun 17 00:48 fileserv._scanner2_nijos.0 -rw---1 amanda disk 1.0G Jun 17 01:08 fileserv._scanner2_nijos.0.1 -rw---1 amanda disk 1.0G Jun 17 01:28 fileserv._scanner2_nijos.0.2 -rw---1 amanda disk 918M Jun 17 01:45 fileserv._scanner2_nijos.0.3 -rw---1 amanda disk 1.0G Jun 17 00:10 fileserv._scanner3_SMA.0 -rw---1 amanda disk 1.0G Jun 17 00:34 fileserv._scanner3_SMA.0.1 -rw---1 amanda disk 438M Jun 17 00:46 fileserv._scanner3_SMA.0.2 -rw---1 amanda disk 1.0G Jun 16 23:57 fileserv._u_people.0 -rw---1 amanda disk 1.0G Jun 17 00:49 fileserv._u_people.0.1 -rw---1 amanda disk 1.0G Jun 17 01:22 fileserv._u_people.0.2 -rw---1 amanda disk 1.0G Jun 17 01:49 fileserv._u_people.0.3 -rw---1 amanda disk 1.0G Jun 17 02:22 fileserv._u_people.0.4 -rw---1 amanda disk 1.0G Jun 17 03:09 fileserv._u_people.0.5 -rw---1 amanda disk 314M Jun 17 03:24 fileserv._u_people.0.6 -rw---1 amanda disk 1.0G Jun 16 23:40 rogaland._usr_work.0 -rw---1 amanda disk 1.0G Jun 16 23:51 rogaland._usr_work.0.1 -rw---1 amanda disk 1.0G Jun 17 00:02 rogaland._usr_work.0.2 -rw---1 amanda disk 529M Jun 17 00:10 rogaland._usr_work.0.3 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
I/O error when writing to tape
Just got *** A TAPE ERROR OCCURRED: [[writing file: I/O error]]. during a backup run. - Must be something wrong with the tape or tape drive, I thought, but it turns out that 1. I get this error for various different tapes when trying to amflush the dump to them. 2. I can write other dumps to the same tapes. Any idea what may cause this kind of thing to happen? I'm using the 20030516 snapshot, and holding disk is # ls -lh total 17G -rw---1 amanda disk 1.0G Jun 17 00:48 fileserv._scanner2_nijos.0 -rw---1 amanda disk 1.0G Jun 17 01:08 fileserv._scanner2_nijos.0.1 -rw---1 amanda disk 1.0G Jun 17 01:28 fileserv._scanner2_nijos.0.2 -rw---1 amanda disk 918M Jun 17 01:45 fileserv._scanner2_nijos.0.3 -rw---1 amanda disk 1.0G Jun 17 00:10 fileserv._scanner3_SMA.0 -rw---1 amanda disk 1.0G Jun 17 00:34 fileserv._scanner3_SMA.0.1 -rw---1 amanda disk 438M Jun 17 00:46 fileserv._scanner3_SMA.0.2 -rw---1 amanda disk 1.0G Jun 16 23:57 fileserv._u_people.0 -rw---1 amanda disk 1.0G Jun 17 00:49 fileserv._u_people.0.1 -rw---1 amanda disk 1.0G Jun 17 01:22 fileserv._u_people.0.2 -rw---1 amanda disk 1.0G Jun 17 01:49 fileserv._u_people.0.3 -rw---1 amanda disk 1.0G Jun 17 02:22 fileserv._u_people.0.4 -rw---1 amanda disk 1.0G Jun 17 03:09 fileserv._u_people.0.5 -rw---1 amanda disk 314M Jun 17 03:24 fileserv._u_people.0.6 -rw---1 amanda disk 1.0G Jun 16 23:40 rogaland._usr_work.0 -rw---1 amanda disk 1.0G Jun 16 23:51 rogaland._usr_work.0.1 -rw---1 amanda disk 1.0G Jun 17 00:02 rogaland._usr_work.0.2 -rw---1 amanda disk 529M Jun 17 00:10 rogaland._usr_work.0.3 -- - Toralf
Unscheduling DLE (with archival involved.)
What is the right and proper way to unschedule the dump of a DLE? I thought the answer would be "amadmin delete, then remove DLE from disklist", but it seems to me that this will prevent me from amrecover'ing the DLE from existing backups, which is something I want to be able to do. Notice that I'm also using the disklist for archival runs, so the dumps won't just be overwritten in a short while. -- Toralf
More flexible "autoflush"?
The addition of "autoflush" option in 2.4.3 was really very helpful, but I'm still not satisfied. What I really want, is to autoflush when one or two smallish DLE dumps are left on the holding disk, but not if the entire taper operation failed due to tape error or something. Comments? -- - Toralf
Re: amrecover Problem
Hi there, ive got a Problem with amrecover on an Debian GNU/Linux maschine. amrecover reports: No index records for disk for specified date If date correct, notify system administrator In debug files in /tmp i cant find any other Informations.Debugfile is there but the informations are the same shown on client. There is a backup on level 0 on specified date. In amanda.conf index yes is set on dumptype. -> index is on the secified indexdir, so i can zcat it and see all files an directorys. Iam using tar (GNU tar 1.13.25), so it cant be the known bug on older gtar versions, and amanda version 2.4.2p2. Are there any solutions. I got the same error message on a recovery attempt some time back, and it was caused by a permission problem that prevented the backup config from being read correctly. Note that the config files are read by amandad (amrecover is just a client application that interacts with amandad), which is usually executed as "amanda", so the files need to be readable by that user. Also, amandad apparently has (or had) a bug that prevents some file open problems from being reported in the logs. In other words, you probably need to chmod or chown one or more of the config files (in my case it was the tapelist) to make them readable by amandad. Greetings Daniel
Re: Sharing index between configs ("full" and "incrementals")?
On 2003.04.03 16:54, Jon LaBadie wrote: On Thu, Apr 03, 2003 at 09:51:25AM +0200, Toralf Lund wrote: > As I've indicated earlier, I want to write full backups to tape, but keep > some or all of the incremental on the harddisk, so I've set up two > different configs; one with "skip-incr" that will write to tape, and one > without full dumps that will dump to harddisk, via chg-multi and a > chg-multi.conf where all slots point to file:. The > disklist is shared between the configs. The question is simply, can they > share the index as well? Will everything work all right if I simply > specify the same indexdir for both configs? I believe they can, however, you can't do an incremental for a config without first doing a level 0. Well, I'm also trying to tell Amanda that a full backup is done off-line by using "force" commands, with arguments based on data from the first (full) backup. And on recovery, the incrementals are ?useless? without the level 0. Really? I thought I could: 1. Do recovery with the full config, then the incremental, to reproduce the data fully. 2. Fetch individual files from the incremental config, provided that they were updated recently enough to be included on the incremenal-dump. Note that my primary concern here is in many ways the recovery of individual files. Not that I'm not worried about loosing everything on a disk crash, but I'm not sure I will use amrecover or the indexes on that event. (And after all, files being deleted by mistake *is* a lot more likely than a major crash.) The common index may solve the first problem, but I don't think it will help the second. Which is really the one I wanted solved, of course - Toralf
Re: backup with exclude
-Messaggio originale- Da: Valeria Cavallini [mailto:[EMAIL PROTECTED] Inviato: giovedi 3 aprile 2003 10.59 A: [EMAIL PROTECTED] Oggetto: backup with exclude Hi, I've read some tread on the hacker newsgroup and I've found that someone talks about the option exclude to exclude more then one pattern. I'd like to exclude from backup some type of file, such mp3 avi divx, but I didn't find the end of the tread, did anybody solved this problem? The explanation is in the "amanda" manpage; look for "exclude" under DUMPTYPE SECTION. Note that the exclusions support is a lot more flexible in version 2.4.3 onwards than it used to be in the past. - Toralf
skip-full/skip-incr vs strategy
I'm a bit confused about the "strategy" setting and the "skip-full"/"skip-incr". Although the functionality of these is not exactly the same, there definitely seems to be an overlap. Can someone explain the idea behind these settings, and why there isn't just one way of choosing what to include on the backup? -- Toralf Lund <[EMAIL PROTECTED]> +47 66 85 51 22 ProCaptura AS +47 66 85 51 00 (switchboard) http://www.procaptura.com/~toralf +47 66 85 51 01 (fax)
Sharing index between configs ("full" and "incrementals")?
As I've indicated earlier, I want to write full backups to tape, but keep some or all of the incremental on the harddisk, so I've set up two different configs; one with "skip-incr" that will write to tape, and one without full dumps that will dump to harddisk, via chg-multi and a chg-multi.conf where all slots point to file:. The disklist is shared between the configs. The question is simply, can they share the index as well? Will everything work all right if I simply specify the same indexdir for both configs? -- Toralf Lund <[EMAIL PROTECTED]> +47 66 85 51 22 ProCaptura AS +47 66 85 51 00 (switchboard) http://www.procaptura.com/~toralf +47 66 85 51 01 (fax)
Re: amrecover: No index records for disk for specified date
[ ... ] > >What's the output of 'amadmin ks find mercedes-benz /usr/people/jfo'? > Trying this helped me figure out what was wrong ;-) The command would list > the expected dates and tape names when executed as root, but as amanda, I > got "No dump to list", which made it quite obvious that the permissions of > some file required were wrong (I suspected that all along, but I wasn't > able to spot the exact problem earlier.) It then turned out that tapelist > was no longer readable by amanda, for some reason. After a simple chmod, I > was able to restore the backup correctly. > > Question: Why didn't amrecover or the amindexd log tell me that the > tapelist was unreadable? > If you ran amrecover as amanda-user, why didn't it tell you: I didn't. The configs aren't read by amrecover, but by amindexd, which is always executed as amanda-user (as far as I can tell.) - Toralf
Re: amrecover: No index records for disk for specified date
On Tue, Feb 11, 2003 at 05:31:04PM +0100, Toralf Lund wrote: > I'm getting error message > > No index records for disk for specified date > > when trying to recover a certain DLE using amrecover (version 2.4.3.) The > full output from the session + some of the debug messages are included > below. The index looks good to me; [ ... ] An index file doesn't mean that the backup is still available. Really? What's the output of 'amadmin ks find mercedes-benz /usr/people/jfo'? Trying this helped me figure out what was wrong ;-) The command would list the expected dates and tape names when executed as root, but as amanda, I got "No dump to list", which made it quite obvious that the permissions of some file required were wrong (I suspected that all along, but I wasn't able to spot the exact problem earlier.) It then turned out that tapelist was no longer readable by amanda, for some reason. After a simple chmod, I was able to restore the backup correctly. Question: Why didn't amrecover or the amindexd log tell me that the tapelist was unreadable? - Toralf
amrecover: No index records for disk for specified date
I'm getting error message No index records for disk for specified date when trying to recover a certain DLE using amrecover (version 2.4.3.) The full output from the session + some of the debug messages are included below. The index looks good to me; I have # ls -lR /dumps/amanda/ks/index/mercedes-benz total 0 drwxr-sr-x2 amanda disk 97 Feb 11 01:43 _usr_people_jfo /dumps/amanda/ks/index/mercedes-benz/_usr_people_jfo: total 192 -rw---1 amanda disk 18539 Nov 14 22:16 20021114_0.gz -rw---1 amanda disk 23757 Dec 9 22:17 20021209_0.gz -rw---1 amanda disk 23043 Jan 6 22:13 20030106_0.gz -rw---1 amanda disk 26515 Jan 31 22:16 20030131_0.gz Also, I successfully ran a similar recovery yesterday - same DLE, but different date, as I didn't have the latest tape available, then - but something must have changed in the meantime, or I'm doing it in a slightly different way (I've tried other dates again today, though, but all with the same result.) Any ideas what is wrong? # amrecover ks AMRECOVER Version 2.4.3. Contacting server on localhost ... 220 praha AMANDA index server (2.4.3) ready. 200 Access OK Setting restore date to today (2003-02-11) 200 Working date set to 2003-02-11. 200 Config set to ks. 501 No index records for host: praha. Invalid? Trying host praha.kscanners.no ... 501 No index records for host: praha.kscanners.no. Invalid? Trying host praha.advim.no ... 501 No index records for host: praha.advim.no. Invalid? Trying host praha ... 501 No index records for host: praha. Invalid? Trying host www ... 501 No index records for host: www. Invalid? Trying host ftp ... 501 No index records for host: ftp. Invalid? Trying host mx ... 501 No index records for host: mx. Invalid? Trying host fileserv ... 200 Dump host set to fileserv. Trying disk /dumps ... Trying disk dks2d11s7 ... Can't determine disk and mount point from $CWD '/dumps/misc/jfo' amrecover> setdate 2003-01-31 200 Working date set to 2003-01-31. amrecover> sethost mercedes-benz 200 Dump host set to mercedes-benz. amrecover> setdisk /usr/people/jfo Scanning /dumps/amanda/hd... 200 Disk set to /usr/people/jfo. No index records for disk for specified date If date correct, notify system administrator # tail -f amindexd.20030211172336.debug amindexd: time 0.752: > HOST ftp amindexd: time 0.753: < 501 No index records for host: ftp. Invalid? amindexd: time 0.953: > HOST mx amindexd: time 0.953: < 501 No index records for host: mx. Invalid? amindexd: time 1.153: > HOST fileserv amindexd: time 1.154: < 200 Dump host set to fileserv. amindexd: time 1.355: > DISK /dumps amindexd: time 1.356: < 501 No index records for disk: /dumps. Invalid? amindexd: time 1.555: > DISK dks2d11s7 amindexd: time 1.556: < 501 No index records for disk: dks2d11s7. Invalid? amindexd: time 16.563: > DATE 2003-01-31 amindexd: time 16.563: < 200 Working date set to 2003-01-31. amindexd: time 37.592: > HOST mercedes-benz amindexd: time 37.593: < 200 Dump host set to mercedes-benz. amindexd: time 53.566: > DISK /usr/people/jfo amindexd: time 53.567: < 200 Disk set to /usr/people/jfo. amindexd: time 53.568: > OISD / amindexd: time 53.568: < 500 No dumps available on or before date "2003-01-31" amindexd: time 118.826: > QUIT amindexd: time 118.827: < 200 Good bye. amindexd: time 118.827: pid 47431195 finish time Tue Feb 11 17:25:35 2003 # tail amrecover.20030211172336.debug guess_disk: 6: 9: "/scanner2": "/dev/xlv/stripedvol3" guess_disk: 6: 6: "/dumps": "/dev/dsk/dks2d11s7" guess_disk: 6: 3: "/u2": "/dev/dsk/dks2d14s7" guess_disk: 6: 14: "/usr/doc-linux": "linuxdoc:/usr/share/doc" guess_disk: 6: 15: "/var/www-server": "localhost:/var/www" guess_disk: 6: 8: "/imgproc": "raid1:/imgproc" guess_disk: 6: 9: "/imgproc2": "imgproc:/imgproc2" guess_disk: 6: 9: "/imgproc3": "imgproc:/imgproc3" guess_disk: 6: 9: "/scanner4": "raid2:/scanner4" amrecover: pid 48822211 finish time Tue Feb 11 17:25:35 2003 -- Toralf Lund <[EMAIL PROTECTED]> +47 66 85 51 22 ProCaptura AS +47 66 85 51 00 (switchboard) http://www.procaptura.com/~toralf +47 66 85 51 01 (fax)
Full backup to tape, incrementals to disk?
I seem to remember that something like this has been discussed before, but I couldn't find anything in the archives ;-/ Anyhow, I'm thinking about setting up a config with full backups to tape and incrementals to harddisk - due to limited tape capacity (yes, I know incrementals are usually small, but we have some filesystems with large files that change a lot), and to allow for faster recovery (at the expense of security, to a certain degree.) Is there a simple way to do that with Amanda 2.4.3? - Seems like I can quite easily set up one config for the fulls and one for the incrementals, but I also need some way to "link" the two, so that the level returns correctly to level 1 for the incremental when a full backup has been executed. Also, I would really prefer to have a common index, so separate configs may not be quite what I want in any case. -- - Toralf
: does not support optional exclude (2.4.3 server & 2.4.2p2 client)
I've just updated my amanda server to version 2.4.3, and adjusted the config for new options etc. Notably, I've inserted the new "optional" keyword into my exclude list spec as exclude lists won't always exist. After this, I get a lot of: WARNING: : does not support optional exclude Not very surprising, as some of the clients are still on version 2.4.2p2 (and will be for another while, I think), but do I need to worry about this? What will amanda do with the exclude list for these clients? Also, are there any other pitfalls associated with combining a version 2.4.3 server and 2.4.2p2 clients -- Toralf Lund <[EMAIL PROTECTED]> +47 66 85 51 22 ProCaptura AS +47 66 85 51 00 (switchboard) http://www.procaptura.com/~toralf +47 66 85 51 01 (fax)
Re: Inexplicable amandahostsauth failure
I've had auth problems with one of the hosts I'm backing up for some time; amcheck says # amcheck -c ks Amanda Backup Client Hosts Check ERROR: bmw: [access as amanda not allowed from root@] amandahostsauth failed I found out what was going on after all; it turned out to be a hostname lookup issue. An official hostname for the Amanda server different from the one on most other machines would be returned on this particular host due to an extra entry in /etc/hosts. (The name usually comes from DNS.) I guess I should list more of the alternative names (there are a lot due to local alias setup and because we have registered several names for our domain) in .amandahosts... Question: Can I use regexps in the file? - Toralf
Inexplicable amandahostsauth failure
I've had auth problems with one of the hosts I'm backing up for some time; amcheck says # amcheck -c ks Amanda Backup Client Hosts Check ERROR: bmw: [access as amanda not allowed from root@] amandahostsauth failed However, .amandahosts seems correct to me, and perhaps more importantly, it's identical to the ones on hosts where I don't get this problem (I even tried to copying it from another machine just to make sure), and as far a I can tell, this is true for the client setup in general, but obviously there is *something* I'm missing. Help, anyone? -- Toralf Lund <[EMAIL PROTECTED]> +47 66 85 51 22 ProCaptura AS +47 66 85 51 00 (switchboard) http://www.procaptura.com/~toralf +47 66 85 51 01 (fax)
Re: Initial disk of amrecover set up incorrectly
>amrecover will in my setup make a completely wrong guess about what disk >to consider at startup in most cases. The example output included below >should illustrate the problem; /usr/freeware/apache is not on the /u >filesystem, and it has a separate disklist entry. Any ideas what is going >on? >... >$CWD '/usr/freeware/apache' is on disk '/u' mounted at '/u'. So where is it mounted? What happens if you run "df -k /usr/freeware/apache"? It's part of the root filesystem; # df -k /usr/freeware/apache Filesystem Type kbytes use avail %use Mounted on /dev/root xfs 16727944 4923500 1180 30 / From Amanda's viewpoint it's a separate entity, though, like I said; it has it's own DLE backed up using GNUTAR. What is the output for "mount" (with no args it lists your mount table). # mount /dev/root on / type xfs (rw,raw=/dev/rroot) /hw on /hw type hwgfs (rw) /proc on /proc type proc (rw) /dev/fd on /dev/fd type fd (rw) /dev/xlv/stripedvol2 on /scanner type xfs (0) /dev/dsk/dks2d11s7 on /dumps type xfs (0) /dev/dsk/dks2d14s7 on /u2 type xfs (0) /dev/xlv/stripedvol3 on /scanner2 type xfs (0) /dev/dsk/dks0d5s7 on /u type xfs (quota) /dev/xlv/stripedvol1 on /scanner3 type xfs (0) linuxdoc:/usr/share/doc on /usr/doc-linux type nfs (vers=2,rw,intr,bg,dev=18) raid1:/imgproc on /imgproc type nfs (vers=3,rw,intr,bg,dev=140002) imgproc:/imgproc2 on /imgproc2 type nfs (vers=3,rw,intr,bg,dev=140001) imgproc:/imgproc3 on /imgproc3 type nfs (vers=3,rw,intr,bg,dev=140003) raid2:/scanner4 on /scanner4 type nfs (vers=2,rw,intr,bg,dev=180001) localhost:/var/www on /var/www-server type nfs (vers=3,rw,intr,bg,dev=140004) What's in /tmp/amanda/amrecover*.debug? There should be some lines referring to "guess_disk". I don't see any. The complete contents (which don't make a lot of sense to me) is included below. The following few lines from amindexd.*.debug may explain a lot, though: OISD sr/freeware/apache f /dumps/amanda/ks/index/fileserv/_u/20030102_0 < 500 "sr/freeware/apache" is an invalid directory --- File amrecover.20030106084800.debug: amrecover: debug 1 pid 27890309 ruid 0 euid 0 start time Mon Jan 6 08:48:00 2003 amrecover: stream_client: connected to 193.214.130.4.10082 amrecover: stream_client: our side is 0.0.0.0.821 add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/." add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.Trash-hhe/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.Trash-jfo/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.Trash-paal/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.Trash-root/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.amanda.excludes" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.nautilus-metafile.xml" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/CVS/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/KENmaster/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/dist/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/ent" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/fax/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/ftp/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/laptoptest.aw" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/logo/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/lost+found/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/mail/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/marketing/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/marketing2/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/test/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/www.kscanners.com.key"
Initial disk of amrecover set up incorrectly
amrecover will in my setup make a completely wrong guess about what disk to consider at startup in most cases. The example output included below should illustrate the problem; /usr/freeware/apache is not on the /u filesystem, and it has a separate disklist entry. Any ideas what is going on? praha 17# cd /usr/freeware/apache praha 18# amrecover ks AMRECOVER Version 2.4.2p2. Contacting server on amanda-server ... 220 praha AMANDA index server (2.4.2p2) ready. 200 Access OK Setting restore date to today (2002-12-20) 200 Working date set to 2002-12-20. 200 Config set to ks. 501 No index records for host: praha. Invalid? Trying praha.kscanners.no ... 501 No index records for host: praha.kscanners.no. Invalid? Trying praha.advim.no ... 501 No index records for host: praha.advim.no. Invalid? Trying praha ... 501 No index records for host: praha. Invalid? Trying www ... 501 No index records for host: www. Invalid? Trying ftp ... 501 No index records for host: ftp. Invalid? Trying mx ... 501 No index records for host: mx. Invalid? Trying fileserv ... 200 Dump host set to fileserv. $CWD '/usr/freeware/apache' is on disk '/u' mounted at '/u'. 200 Disk set to /u. Invalid directory - /usr/freeware/apache amrecover> -- Toralf Lund <[EMAIL PROTECTED]>
