Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Incremental\s+forever\s+\-\-\s+any\s+problems\?\s+\(Scary\s+thoughts\)\s*$/: 19 ]

Total 19 documents matching your query.

1. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>
Date: Tue, 18 Dec 2001 21:50:44 +0100
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00680.html (22,116 bytes)

2. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: "<James> <healy>" <James.Healy2 AT AXACS DOT COM>
Date: Tue, 18 Dec 2001 16:22:25 -0500
That seems to be really slow 8 gb per hour. I'm running TSM server on a h70 with 100mb ethernet dedicated backbone to my NT clients. These clients are mostly compaq prolient 7000. I average about 14-
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00682.html (16,334 bytes)

3. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Kelly Lipp <lipp AT STORSOL DOT COM>
Date: Tue, 18 Dec 2001 15:38:16 -0700
Excellent analysis. No, the users would not tolerate this. So what are people doing about this? Nothing. Hoping. Praying. The good news is the RAID will save most of the days. But every now and then
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00685.html (21,145 bytes)

4. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Alex Paschal <AlexPaschal AT FREIGHTLINER DOT COM>
Date: Tue, 18 Dec 2001 15:53:40 -0800
Daniel, With LTO, your capacity is probably about 100GB native. Your 700 GB server might occupy maybe 1.5 TB of space due to file versions, depending on your retentions (my 1TB fileserver occupies 1.
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00688.html (13,581 bytes)

5. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Steve Harris <STEVE_HARRIS AT HEALTH.QLD.GOV DOT AU>
Date: Wed, 19 Dec 2001 10:00:11 +1000
This is a horses for courses problem. TSM across the network may not be the best solution for this server. Instead use some tool which can write to directly attached tape drives. If you want to use T
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00691.html (16,639 bytes)

6. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Date: Wed, 19 Dec 2001 12:19:03 +0200
It is up to the (file) server administrator how he/she will setup, tune and maintain the node. 1 TB of data can be put on a single filesystem - it is up to you. In my practice I've even seen an Oracl
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00699.html (16,112 bytes)

7. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Karel Bos <Karel.Bos AT NUON DOT COM>
Date: Wed, 19 Dec 2001 11:41:33 +0100
Are back-up sets a option?
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00700.html (12,481 bytes)

8. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>
Date: Wed, 19 Dec 2001 12:03:28 +0100
This test was performed during daily operations. This is usually the time when you need to do a restore. Therefore, the machine you're trying to restore won't be the only machine sending packets over
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00701.html (20,203 bytes)

9. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>
Date: Wed, 19 Dec 2001 12:09:51 +0100
The bottleneck in a solution like this is probably not the 3584 drives, which, as you correctly suggest, should perform about 12-15MB/s. But, can the local area network perform this can of speed? A 1
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00702.html (19,902 bytes)

10. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Robin Sharpe <Robin_Sharpe AT BERLEX DOT COM>
Date: Wed, 19 Dec 2001 10:31:07 -0500
Backupsets can be useful in some situations, but saving time is not one of their benefits. In the experiments I've done, generating a backupset took as long as or longer than restoring the client. Th
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00725.html (15,693 bytes)

11. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Karel Bos <Karel.Bos AT NUON DOT COM>
Date: Wed, 19 Dec 2001 16:48:25 +0100
Put SEARCHMPQUEUE in de dsmserv.opt and the number of tapemount will reduce drasticly!
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00729.html (12,412 bytes)

12. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Kelly Lipp <lipp AT STORSOL DOT COM>
Date: Wed, 19 Dec 2001 09:46:35 -0700
Yeah, and when you start to restore 512 byte files the performance will really go into the dumper. This problem is not about tape speed, network speed or disk speed. It's about software. If anybody h
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00738.html (13,298 bytes)

13. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Kelly Lipp <lipp AT STORSOL DOT COM>
Date: Wed, 19 Dec 2001 10:13:20 -0700
On the wishlist item: I have heard talk about implementing an automatic multi-stream restore similar to what we have now with backup and resourceutilization. This will be slick but then only really s
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00743.html (14,531 bytes)

14. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Michael Bartl <michael.bartl AT CW DOT COM>
Date: Thu, 20 Dec 2001 09:51:24 +0100
Hi Kelly, your're right, a multistream restore is one of the items on top of our wishlist. Just one thought on collocation: With collocation you can't mount as many tapes as without, ok. But with col
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00775.html (14,421 bytes)

15. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: John Naylor <John.Naylor AT SCOTTISH-SOUTHERN.CO DOT UK>
Date: Thu, 20 Dec 2001 11:37:57 +0000
Where is SEARCHMPQUEUE documented ? Karel Bos <Karel.Bos AT NUON DOT COM> on 12/19/2001 03:48:25 PM Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> Put SEARCHMPQUEUE in de d
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00781.html (13,419 bytes)

16. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Remco Post <r.post AT SARA DOT NL>
Date: Thu, 20 Dec 2001 14:59:50 +0100
In the Tivoli Administrators guide. -- Met vriendelijke groeten, Met vriendelijke groeten, Remco Post SARA - Stichting Academisch Rekencentrum Amsterdam High Performance Computing Tel. +31 20 592 800
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00788.html (13,186 bytes)

17. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Jeff Bach <jdbach AT WAL-MART DOT COM>
Date: Thu, 20 Dec 2001 08:49:07 -0600
http://www.lrz-muenchen.de/services/datenhaltung/adsm/link/tsm-v42-books/ref erence/anrar402.htm#HDRSEARCHMPQ <http://www.lrz-muenchen.de/services/datenhaltung/adsm/link/tsm-v42-books/re ference/anra
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00792.html (14,281 bytes)

18. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Robin Sharpe <Robin_Sharpe AT BERLEX DOT COM>
Date: Thu, 20 Dec 2001 10:01:37 -0500
Oops -- Forwarded by Robin Sharpe/WA/USR/SHG on 12/20/01 10:01 AM -- Robin Sharpe Robin Sharpe But wait a miniute.... doesn't the multi streamed backup work by allocating a session to each filespace
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00793.html (16,157 bytes)

19. Re: Incremental forever -- any problems? (Scary thoughts) (score: 1)
Author: Kelly Lipp <lipp AT STORSOL DOT COM>
Date: Thu, 20 Dec 2001 09:30:52 -0700
As can be seen, the notion of multiple restore is complicated. I'm sure that the Tivoli engineers are working hard on implementation ideas. I hope that they have lots of people that have seen various
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2001-12/msg00804.html (12,254 bytes)


This search system is powered by Namazu