This might not answer your question, depending on what you're
trying to do. I run two nearly identical configurations, but
one is always level 0 backups, that we send off-site, archive
for several years, etc. The other configuration is a "normal"
amanda setup that includes a mix of level 0 as well as
incremental backups. Those tapes never leave the tape library
so if we need to recover something right away we've got
everything we need.
Both configs backup the same DLEs with a couple of minor
exceptions (data we don't want to hang onto for years).
The main differences between the two config files are
record no
dumpcycle 0
in the always do level 0's configuration.
Good luck!
--Marcus
On 02/22/2013 05:38:50 AM, Heiko Schlittermann wrote:
Hello,
I've multiple backup sets. The dumptype
define dumptype … {
program DUMP
record yes
index yes
}
My DLE use the dump type above. It works. But now I start using
multiple configs, using the same DLE, the same dump types - but
a completly different set of backup media.
In other words - boths backup sets should be completly independend of
each other.
But they aren't. Every run of dump(8) updates the "dumpdates" file on
the client side (because of "record yes"). This file is shared among
all
configurations and even other dump(8) invocations. I do not see any
configuration option to specify location of the "dumpdates" file
(similiar to the "amandates" config option for the client side
config).
How should this be solved?
According the the sources and the debug output there is the date of
the
last dump passed from the server to the client, but only if non-XML
communication is used. I'm not sure if the client would use this date.
Using ths date "dump" would not need the "dumpdates" file.
Any ideas?
Or I'm just wrong?
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix
support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}:
+49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID:
7CBF764A -
gnupg fingerprint: 9288 F17D BBF9 9625 5ABC 285C 26A9 687E 7CBF
764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0
359B)-
