> By "tar snapshot files" are you talking about the index files used
> with amrecover?
No, I mean the files referenced by the 'listed-incremental' tar parameter, which are
needed to restore the exact state of the file system if you're having any dumps with
levels greater 0 (that means always ;-). Without using the snapshot files tar will
only add files that are in it's - for example - "level 1" tar archive, but not delete
files that have been deleted between the level 0 and level 1 dumps. This means after a
restore your file system might contain more files than were actually present at the
time the last backup was done (very ugly thing to happen, especially if it's source
code and you moved e.g. libraries to a subdirectory and are now including the old
versions from the current directory again ...)
That's the reason why I definitely want those files on the same tape and also the
reason I asked what everybody else is doing with their tar snapshot files ;-)
> (btw, the online
>>chapter of the unix backup & restore book states incorrectly that this 'startt
>>ime' is relative to the amdump start time, but I think I'm not the first one t
>>o stumble over it).
> Thanks for mentioning that. I'm in the process of reviewing those pages
> and will get this fixed.
While you're at it, I recently found a nice one liner to convert the unix epoch time
value back to human readable format. IMO that's easier and faster to type than the
perl script given in the restore chapter (where xxxxx is the number of seconds of
course):
date -d '1970-01-01 xxxxxxxxxx sec' +"%c %Z"
> What??? You actually read the sources to see how it worked??? :-) :-)
Welll, not in the first place. But since every try almost took an hour and I got (to
me) confusing results depending on whether the backup fitted into the holding disk or
not etc., I thought it would be better invested time to look at the sources instead of
doing some more tries ... ;-)
<lots of good stuff deleted>
> Another thought that would involve a little C coding would be to define a
> new priority number, e.g. -1000, and then special case that in driver to:
I think I will try this suggestion because I already understood that part of the
source :-); but I admit the seperate queue would be much cleaner. Waiting for that
infamous rewrite ...
I'll let the list know the results.
BTW while testing I modified the conffile.c source a bit to allow the starttime
parameter to contain the relative time from the amdump start time. If you want to use
relative instead of absolute time, use a negative number of the same format as the
'normal' starttime attribut, e.g. -0100 for one hour relative to amdump's start time.
Here's the patch (against 2.4.2p1 server-src/conffile.c):
--- server-src/conffile.c.orig Sun Mar 25 14:01:28 2001
+++ server-src/conffile.c.new Sun Mar 25 13:59:57 2001
@@ -1931,12 +1931,16 @@
get_conftoken(INT);
hhmm = tokenval.i;
- stm = localtime(&st);
- st -= stm->tm_sec + 60 * (stm->tm_min + 60 * stm->tm_hour);
- st += ((hhmm/100*60) + hhmm%100)*60;
+ if (hhmm>=0) {
+ stm = localtime(&st);
+ st -= stm->tm_sec + 60 * (stm->tm_min + 60 * stm->tm_hour);
+ st += ((hhmm/100*60) + hhmm%100)*60;
- if (st-start_time.r.tv_sec<-43200)
- st += 86400;
+ if (st-start_time.r.tv_sec<-43200)
+ st += 86400;
+ } else {
+ st += ((abs(hhmm)/100*60) + abs(hhmm)%100)*60;
+ }
return st;
}
Urban
