Hi, Brian, on Mittwoch, 01. Dezember 2004 at 21:37 you wrote to amanda-users:
BC> Is "dumped" really the right term there ? "Dumped with Tar" Yes, I know, this can be misleading and ain't pretty ... BC> There is no assurance I will be allowed to continue using /usr5 as an BC> amanda work area. BC> Amanda work can consume whatever is left on /usr5, but there is BC> no assurance that there will be any space and I just know the BC> first time a user tries to save a large file and can't allocate BC> the space there is going to be a problem. Hm ... I assume you have set your holdingdisk-definition with using something like "use -1Gb" to let AMANDA use all the available space except that one Gb (in my example). It would be better to know how much holdingdisk you may use, but I understand the situation. I would try to use a pretty small chunksize (compared to the DLE-sizes), "taperalgo largestfit", and as much of the free space as you can get for the holdingdisk. BC> We always like to use dump rather than tar for root partitions. It BC> has been my understanding that tar is just a character archiver where BC> dump will understand the vendor specific special devices. Dump/restore BC> are the recommended way to preserve and restore a bootable partition. Ok, good point, no question. BC> A closer look at the two most recent amanda dump reports shows that BC> a few partitions where promoted to level 0 and that a couple of the BC> partitions that had encountered EOT on the tape where bumped to level 1. BC> It is still unclear to me if the level 0 of those partitions was properly BC> written to tape. Maybe force to them to lev0 for the next run to try those lev0-backups again. BC> taper: tape SAMAR02 kb 161967808 fm 9 writing file: No space left on device BC> taper: retrying samar:/usr5/allengr.0 on new tape: [writing file: No space BC> +left on device] BC> This last message indicating that amanda will try to write the data BC> to the next tape volume. However there is no file to DD from the amanda BC> work area - in order to retry amanda would have to go all of the way BC> back to the tar and zip it again. BC> Does amanda retry from the start and reasign to a dumper or does it BC> simply reassign the DLE to the taper ? BC> I could always remount the tapes and find out I guess. Have a look at the logfiles and maybe show us the relevant parts. You should see the things AMANDA tries to do there. (I admit, I don't know this exactly, a look at the logs will help ...) >> I know that you as the responsible admin tend to see things >> pessimistic. It is your job to do so, and I understand this perfectly >> as I am "the responsible admin" for several sites, too. >> >> We can't afford to be too OPTIMISTIC, do we? ;-) >> >> I also know from my view as an active member of the list that your >> installation is still in the process of development. BC> On that note I've got to tell you that one fo the other guys here BC> insists (rightly I should add) that the purpose of data backup is not BC> getting the data to tape, its getting the data back off of the tape. Errm, it seems as if I was mis-understood: What I tried to say was that your installation is in the stage of developing the proper schedule (AMANDA needs to run through the tapecycle at least once to get things right ...). I did not want to say that YOU fail to get your configuration working or something similar. BC> Actually the jury hasn't returned a virdict yet. I would guess that BC> in the case of direct to tape amanda would not restart the DLE from BC> dumper but only from taper, which can not work since there is nothing BC> in the work-area. However I don't know that for sure, it is a guess and BC> I haven't mounted the tapes to find out (yet). I think that AMANDA will find out about the fact that there is no data for that DLE in the holdingdisk and THEN go back to the dumpers again. I haven't found the time to look at this closer but I assume that it works this way ... >> I tend to use one "program" for the whole config as it is easier to >> configure (and wrap your head around). BC> It would be easier, but I question reliablity to restore root and can't BC> use dump on the raid, too big. As said before, OK. As I wrote this I did not know your partitioning so I thought that some overlapping DLEs could bite you with GNUTAR .. BC> Thank you all for your time on this, I apreciate it. It's always a challenge to get things right with big installations. Nice problem to chew on ;-) -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
