ase e-mail me directly with any feedback, suggestions, or problems.
Regards,
Steven P.
PS/ The website will probably move to http://www.ibk.com.au in the near
future.
--
Steven Pemberton Mobile: +61 4 1833 5136
Innovative Business Knowledge O
existing incremental backup data already in the TSM server.
2/ The BackupSet contents are indexed on the backupset tapes, and not in the
TSM database. Therefore your database doesn't need to grow as you retain the
monthly backupsets.
Steven P.
--
Steven Pemberton
l
file, only the entire backupset. You need to use the DSMC command line, and
specify the filename, to restore an individual file from a backupset.
Though, my favorite option is still (A) Buy more tape drives. However, (D)
sounds good too. :)
Steven P.
--
Steven Pemberton Mobile: +61 4 1833 5136
Innovative Business Knowledge Office: +61 3 9820 5811
Senior Enterprise Management ConsultantFax: +61 3 9820 9907
ite seems flooded at the moment. Lots of people grabbing the
new 9.0 iso images I guess.)
I also found a copy at:
http://ftp.physics.auth.gr/pub/mirrors/mirrors2/redhat/support/enterprise/sap/7.1/i386/
There's also a copy at http://www.tuganz.org/filemgmt/index.php
Regards,
Steven P.
--
dle
this load, plus copy pool creation, reclamation, migration, etc. Have you
considered using collocation. Scary... :)
Give me a call on the number below if you'd like to talk about your solution.
Regards,
Steven P.
--
Steven Pemberton Mobile: +61 4 1833 5136
IBK (Sene
;s going to hang around
until the data would normally expire.
I like the charge-back option, as it still lets people perform essential
backups, and will hopefully fund any upgrades needed to cope with TSM's
rampant popularity. :)
Regards,
Steven P.
--
Steven Pemberton
g data between pools (using "move nodedata").
Easy. :)
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, Austr
mply backup the required directory only.
dsmc i -subdir=yes c:\backup\*
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,
first, but the data
would promptly be migrated to tape. This might sometimes be useful as it lets
you backup many clients in simultaneously (more than you have tape drives),
briefly buffers the data to disk, and is immediately written to tape.
Steven P.
--
Steven Pemberton
Senior Enterprise Manage
function. This
might actually be the best way to perform "real" archival backups, but it's
important to ask what *really* needs to be "archived" in this way? Do you
really need to retain the entire filesystem backup, or just some
files/directories/database files?
Steven P.
ice
> classes to use drive mappings in the directory parameter.
Also, since TSM (on Windows) usually runs under the "Local System" account, it
probably doesn't have enough permission to access any network resources,
either mapped or UNC.
Steven P.
--
Steven Pemberton
Senior Ente
l still need to update the path settings after a DR
recovery.
Why can't you configure the libraries to use identical scsi addresses?
Steven P.
--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group
Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +
cheduler.
The API client (a separate fileset) is required when using any TDP client.
However, it's recommended to complement your TDP backups with filesystem
backups, which will require the BA fileset.
Steven P.
--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group
Mo
s 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 &quo
mmand, to ensure the database is in a consistent state for
archival (Do not try to do this with "open file" support). Consider running
the "archive" schedule as a command script. The script could then stop,
archive, and restart, the database.
And if you're using a TDP fo
backup to the remote server - then due to the size of the database backup,
I'd probably want to send it "directly" to tape.
> 4) Should I just break down and put some tape drives out there to
> handle the DBs?
That's probably not necessary; If you have the bandwidth to c
he real
physical volume that previously stored many virtual volumes.
Confused yet?
Sometimes (due to comms problems, etc) there may be a discrepancy between the
two TSM servers. You should occasionally schedule "reconcile volumes" on the
source server to syncronize their views on which volume
before sending it around the world.
If you're feeling brave, you might also consider using "rsync" to send only
the binary differential compared to yesterday's DB backup.
Also, Full (weekly) + Incremental (daily) DB backups may be a good idea due to
your bandwidth constrain
servers.
The thought of doing this in the Windows cmd "language" makes my head hurt...
:)
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 Q
I've found the following to work pretty well:
(dsmc sched 2>&1 >/dev/null &)
The parenthesis drop it into a sub-shell and cleanly detaches from your
current session.
Regards,
Steven P.
--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group
Mobile
On Saturday 21 February 2004 11:37, you wrote:
> Um, I think 4.1 was still 4GB. 13 GB was at 4.2 wasn't it?
For TSM versions 4.1 and earlier the recovery log was restricted to 5.4 GB.
This was raised to 13 GB starting from version 4.2.
Regards,
Steven P.
--
Steven Pemberton
Senior En
ata is *immediately* off-site at backup time.
] Current expectation is twenty-four (24) hours for _all_ critical servers
] to be functional.
I can't comment on this requirement without knowing more about your
environment, ie, how many "critical servers", amount of data, etc.
Somethi
On Wednesday 03 March 2004 16:16, Michael D Schleif wrote:
> * Steven Pemberton <[EMAIL PROTECTED]> [2004:03:03:15:15:57+1100] scribed:
[lots of stuff deleted]
> > The easiest "off-site backup" solution to implement in your environment
> > is probably to simply def
stgpool_name, -
count(distinct volume_name) as "TAPE_SPREAD" -
from volumeusage -
group by node_name, stgpool_name
There's more like this at my TSM site, http://ibktsm.dyndns.org:81/sql.html
Regards,
Steven P.
--
Steven Pemberton
Senior Enterprise Management Consultant
IBK,
%'
The output should look something like the following:
UNCOPIED_FILES UNCOPIED_MB
-- -
2 0.12
Note, the query assumes certain naming conventions for primary and copy
storage pools, but you could make it more g
he "backup" objects saved
from previous DB2 backups (if they belong to the same client account).
You probably also want to ensure the Friday backup is a "full" DB2 backup...
Remember, storage pools "contain" data, Management Classes "retain" data.
Regards,
St
TSM again by the usual backup or archive mechanism. Now there is a DB2
> control file that holds details of backups. whether you will be able to
> restore 12 months hence and need to also keep a copy of the control
> information is a question for your DB2 DBA.
>
>
>
lects all "rootvg" filesystems to backup to the
normal node name, and all "non-rootvg" filesystems to backup to a cluster
node name. It will probably require some modification to suit your filesystem
layout, etc.
Regards,
Steven P.
--
Steven Pemberton
Senior Enterprise Manageme
is: is there any way we can say to TSM "Copy this
> client's data (backup and archive) to that server over there, ignoring
> all other client data in that storage pool"? Or am I smoking crack
> (again)?
Probably the easiest way is to use a separate storage pool(s) for the cri
pinions would be appreciated. Thanks!
>
>
> Joni Moyer
> Highmark
> Storage Systems
> Work:(717)302-6603
> Fax:(717)302-5974
> [EMAIL PROTECTED]
>
--
Steven Pemberton
Mobile: +61/0 418 335 136 | Home: +61/3 9820 5811
Melbourne, Victoria, Australia
http://members.iinet.net.au/~spemberton
30 matches
Mail list logo
