On Thursday 09 October 2003 22:13, Bernd Schemmer wrote:
> I want to implement the following backup definitions:
>
> Create a fullbackup every 1st day of each month
> Create an incremental backup every further day of the month
>
> The fullbackup should be stored for 12 month; the incremental backups
> only until the next fullbackup is done.
>
> The fullbackups and incremental backups should go to the same storage pool.
>
> How do I do this?

Before you do this you should ask yourself (or your users) exactly _why_ you
are doing it, and is it necessary for every node, or is it really necessary
at all?

The best answer is probably to educate your users as to how TSM works, and to
design a normal TSM policy that will achieve the data retention they need,
without requiring unnecessary full backups. But, assuming they do have this
need, there are several options:

If you need to retain the monthly "full" backups for an extended period, for
regulatory reasons, or just because "it sounded like a good idea" - but don't
really expect to ever access them (or only access them rarely), then consider
generating a backup set rather than performing a "real" full backup.

Backup sets are great (though slow to produce) as they don't require the
client to resend a full backup. However, it can be costly in tape (and time)
to produce backup sets for a large number of clients. Media management of
backup sets is also a little harder than for storage pool volumes.

Otherwise, if you need regular and quick access to these "long term backups",
consider instead performing a monthly "archive" instead of a backup - but
realise this will add *significantly* to your TSM database size over time.
Also remeber that "archives" usually treat symbolic links differently than
"backups".

Personally I favour creating two client accounts, to separate my "normal" (35
day retention) from my "long term" (365 day retention) backups. Then create
two schedules, and perform *incremental* backups on both nodes, on the
appropriate day/s of the month - sending each node's backup data to a
separate management class with the appropriate retention periods (which could
then go to the same stgpool if desired).

Eg. "nodename" -> mc35 -> diskpool1 -> tapepool1
            and
      "nodename_ltb" -> mc365 -> diskpool1 -> tapepool1

On the first day of each month the LTB node will perform an incremental
backup, relative to last month's long term backup. This reduces the "long
term" backup from a "full" to an "incremental", and will result in a much
smaller TSM database relative to monthly archives.

While on every day (or every other, if you wish) of the month, the "normal"
node will perform it's regular incremental backup, releative to yesterday's
backup.

Other questions you should ask your users are:
- Does the entire filesystem need to be retained for such a long period, or
just certain critical files/directories?
- Have you considered the need to keep monthly TDP backups for an extended
period (Eg. MS-Exchange).
- Is the data's native format suitable for "archival", consider exporting data
to CSV or XML format prior to archiving (more important for multi-year
archival).

Regards,
Steven P.

--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group

Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +61/3 9820 9907
Level 1, 11 Queens Road, Melbourne, Victoria, 3004, Australia
http://www.senetas.com.au | http://www.ibk.com.au | http://www.datum.com.au