Hi Markus,
thanks for your reply.
- the full backup will be kept until the next one is performed, but it will
no longer be reported on with the query, so don´t worry if it doesn´t seem
to show up... you can´t prove it is still there apart from performing a
restore: hard to believe, I admit, but it just works that way
So "knock on wood" if you need a restore and the full backup is still
there ;-)
- the summary table reports processes on volumes but utterly fails to
report on virtual filespacemappings regarding these processes, making it
useless for reporting and analysis
I don't use vfsmappings at the moment.
Finding the right frequency regarding full/differential is a pain, we have
come up with a 4-week rotation using virtual filespace-mappings which works
quite well as only approximately a quarter of the data goes through a full
per weekend.
So we end up with one admin schedule and script for Monday through
Wednesday doing differentials plus four for the four fridays doing partial
fulls.
I wrote a single script that I call with different values for the input
variables, like the following example:
backup node netapp /vol/vol0 mode=$1 mgmt=netapp
backup node netapp /vol/vol1 mode=$2 mgmt=netapp
backup node netapp /vol/vol2 mode=$3 mgmt=netapp
backup node netapp /vol/vol3 mode=$4 mgmt=netapp
On weekdays I call the script with the arguments "diff diff diff diff",
on every second Saturday with "full diff diff diff" or "diff full diff
diff" and on every second Sunday with "diff diff full diff" or "diff
diff diff full". So I have full backups every two weeks for each volume.
It works, but I think, TSM should come up with a better solution.
--
Regards,
Dirk Kastens
Universitaet Osnabrueck, Rechenzentrum (Computer Center)
Albrechtstr. 28, 49069 Osnabrueck, Germany
Tel.: +49-541-969-2347, FAX: -2470
| 