Hi Tom,
you leave us in darkness what your offsite pool exactly is.
If it is a backup storage pool of your "onsite" pool,
then yes, deleting onsite files will delete offsite files as well.
Seems like what you want to accomplish is simply effectively turn
co-location on, for new and for existing
equate data back to diskpool,
backup and migrate them back to tapes ? It is important for me to offer
complex solution to my customer althoug he has not enough money (or he don't
want to spend them meanwhile) to buy second drive.
Thanx
Tom
> -Původní zpráva-----
> Od: sal Salak J
sure, that data
cannot be migrated there. Please tell me, if is it good idea, of if exist
some bettter solution.
Thanx
Tom
> -Původní zpráva-----
> Od: sal Salak Juraj [SMTP:[EMAIL PROTECTED]]
> Odesláno: 4. května 2001 8:55
> Komu: [EMAIL PROTECTED]
> Předmět: AW: Copy
Hallo Tomáš,
you could use storage standard storage pool hierarchy,
backing first to disk storage pool,
which later migrates to primary tape pool
(you probably already do this).
If your disk storage pool is large enough not to be migrated for, say,
couple of days,
than you can schedule
backup
Morgan,
I am afraid you were a bit upset when writing
your mail. Stating that Arcserve is capable of 100+ MB/sec
seems either not to be fair, or you must have very
sophisticated hardware.
In order to give you any advice more informations are needed.
If you happen , for example, to use 10MBit net
hallo jack,
no need to worry about reclamation of disk storage pools at all.
(Primary) disk storage pools will be emptied according to
their migration limits as set by you.
Maybe you should read TSM documentation, there is a nice
chapter about its concepts in one of the books (sorry, I forgot
wh
question is the one that goes unasked."
"The command line is your friend"
sal Salak Juraj <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 04/26/2001 11:06:16 PM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager&qu
Yes, you are right, the files will be backed up as if they vere new on the
client.
Besides, under circumstances you are not right with the premise
"with no chance of recovery". If the volume deleted belongs to a primary
pool
and had been backed up by the meands of "backup storage pool",
than you
Schedule Randomization Percentage
affects
Immediate Client Actions
as well,
I believe
regards
Juraj Salak
-Ursprüngliche Nachricht-
Von: Marc D. Taylor [mailto:[EMAIL PROTECTED]]
Gesendet am: Montag, 30. April 2001 21:54
An: [EMAIL PROTECTED]
Betreff: Immediate client actions
Hello Al
Thanks!
Interesting reading, however, with limited usablility scope.
This tests vere optimised highest throughputs / streaming
(fair over all technologies, but for this single task only),
while many of us will cope with lower throughputs because of sets of smaller
files, network limitations etc.
not a direct help for your OPT problem
but a general though about misconception
it has been caused by:
Much too often we speak - with our
vendors and bosses and customers as well -
about backup requirements.
NOBODY HAS ANY BACKUP REQUIREMENTS,
WE ALL DO ONLY HAVE RESTORE REQUIREMENTS.
The back
Yes.
If you happen to have free disk space for your largest node,
it is a breeze.
regards
juraj salak
-Ursprüngliche Nachricht-
Von: Joseph Dawes [mailto:[EMAIL PROTECTED]]
Gesendet am: Mittwoch, 25. April 2001 22:47
An: [EMAIL PROTECTED]
Betreff: exporting nodes
Has anyone ever exported
No.
That´s why I perform incremental db backups
to a disk (on another server).
regards
juraj salak
-Ursprüngliche Nachricht-
Von: Gill, Geoffrey L. [mailto:[EMAIL PROTECTED]]
Gesendet am: Mittwoch, 25. April 2001 22:15
An: [EMAIL PROTECTED]
Betreff: Incremental DBbackups
Hello all,
A qu
Hello,
from what I know about currently available tape technologies
I guess that AIT-2 technology might be best for TSM,
because its performance strongly relies on short search times
and on short tape load/unload cycles.
Tis technology seems to be reliable and durable enough as well.
Can anybo
Shawn,
with the database of this size
you might evenconsider splitting it on two TSM instances.
There are advantages and drawbacks coupled with that,
but it works.
>> - Migrate all the client nodes one by one to other machines with
>> import/export.
I did it when I moved from OS/2 to NT Server,
Hi Mahes,
just few thoughts:
>> 1. With the RAID 5 at AIX level, should a second, synchronized copy
of DB volumes is required.
It had been argumented on this forum that TSM mirroring has
some advantages over OS-based Raid system.
Anyway, an OS-based RAID and only single database vol
.. looks like a problem ...
Look for oldest database backup you have
and try to remember yourself whether
it is older than your ANR0102E problem.
If yes, keep this database backup safe.
Backup your DB and related configuration files,
toggle your db off-line,
adn perform either audit db fix=ye
running my TSM box on W2K with a buffpool size of 196MB and it is
running fine. That is the number that TSM chose on install.
-Original Message-
From: sal Salak Juraj [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 7:24 AM
To: [EMAIL PROTECTED]
Subject: Re: ? BUFPOOLSIZE limit under
AIL PROTECTED]
Betreff: Re: ? BUFPOOLSIZE limit under TSM4.1 / NT
According to the 4.1 Admin. Reference, "The maximum value is limited by
available virtual memory size."
sal Salak Juraj wrote:
hallo,
I have purchased upgrade from TSM Server 3.1.7 under NT 4
to newest TSM server vers
hallo,
I have purchased upgrade from TSM Server 3.1.7 under NT 4
to newest TSM server version.
There is limitation of BufPoolSize to max. 65536 in my current system.
I hope this limit is much larger with TSM 4.x - I would like
to purchase some RAM an speed up my system.
Can anyone tell me how
Hi,
>> Ended up restoring from the day before's database backup.
>> Gonna be some upset people in the A.M.
for future you might want to
either change logmode to rollforward
or simply perform incremental database backups
between full ones.
Limitation: much largere logvolumes necessary.
I have s
-Ursprüngliche Nachricht-
Von: William Boyer [mailto:[EMAIL PROTECTED]]
Gesendet am: Sonntag, 15. April 2001 23:50
An: [EMAIL PROTECTED]
Betreff: Should LOADDB take this long?
TSM 3.7.3.0 running on OS/390 2.9
Last night our automated processes to shut the system down didn't take into
ac
Hi,
looks like your DB is good optimised for read operations,
less for write/change operations.
Load takes long, but not necessarily that long.
My DB of some 6 GB used space took more than an hour to be dumped,
but was loaded in something more than a day.
NT4, 2 333 Pentii CPU´s.
I believe tha
up to my knowledge,
TSM respects the limits of underlying file system.
A years ago I had similar problem,
it turned out to be caused by really too long names,
too long in terms of NTFS.
However, we were able to create such long names in NT with following
scenario:
mount a directory , e.g. c:\tmp
Hi,
as others already pointed out, there are more factors to be considered.
As for Raid5 vs. raid1+0,
the later will almost surely improve overall performance at higher costs.
Changing to either raid 1 or raid1+0 will likely
etremly speed-up tasks where the database is changed,
like client bac
Hi,
just 2 pennies:
- yes, compression on should be used in such configuration,
and *sm client is better suited for that than NTBackup.
- do think in terms of restore, not in terms of backup backup:
while you probbaly will succeed in backuops,
will you still be able to perfom good enough at
Hi,
I use TSM while my colleagues use HP-Omniback.
Looks like everybody cooks from water only.
I had a couple of problems with my adsm/tsm in last 4 yeras,
one of them serious (turned to be HW problem,
but only after nightless weeks).
The collegaues had problems as well.
I feel TSM has had l
27 matches
Mail list logo