Hi Richard

There are 2 ways of doing it:

a) Only use FastBack. In this case you'd not use tape, only the disk that is 
connected to FastBack

b) Use FastBack in conjunction with TSM to store long-term data in TSM

Which option to use all depends on how large amount of data you're backing up. 
If the amount of data is small, but the number of files are huge, I'd probably 
suggest going with option A. However, if we're talking a large amountof data, 
I'd probably use option B.

Best Regards
Daniel Sparrman

-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----


Till: ADSM-L AT VM.MARIST DOT EDU
Från: "Cheung, Richard" <Richard.Cheung AT SANTOS DOT COM>
Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 03/02/2011 07:39
Ärende: Re: Ang: Re: Ang: Windows servers with a kazillion files and Win2K8...

So are you saying you would use FastBack to disk, then disk to tape ? 


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
ADSM-L
Sent: Tuesday, 1 March 2011 7:19 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Ang: Re: Ang: Windows servers with a kazillion files and 
Win2K8...

There is a 2TB protected volume size limitation with the FastBack client that 
could be a factor here (although I recall that this might actually be a 
Windows/VSS limitation) but otherwise I think FastBack could be a useful option 
for Wanda.

FYI, FastBack 6.1.3.0 was released last week and (finally) introduces Windows 
64-bit support for the FastBack Server. 

Daniel, as far as I remember when I checked the docs yesterday the 40TB limit 
is still there. Another down-side with FB dedupe is, as I understand it, that 
you're limited to a single repository volume - which is a shame.

David McClelland
London, UK

On 1 Mar 2011, at 06:30, Daniel Sparrman <daniel.sparrman AT EXIST DOT SE> 
wrote:

> Hi Wanda
> 
> Not sure if you've told us the size of these machines, but like someone 
> described, image backups or even better, FastBack VSS backups would be a 
> solution.
> 
> With FastBack, there's no fileinspection in the way TSM does it, so the 
> amount of files wouldnt be an issue. Restores would also be alot faster since 
> you have a) No work putting togheter the list of files to be restored b) 
> FastBack Instant Restore. This would solve both your issues with backing the 
> systems up, but primarily, the time needed to restore them.
> 
> The only down-side with FastBack would be that there is a limit on how big 
> the server you're backing up can be. With previous versions of FastBack, I 
> think the repository limit was 40TB. To calculate how big your repository 
> needs to be, you calculate the size of your server(s) with 4. If this size 
> exceeds the repository size of 40TB, you might have an issue using FB. Not 
> sure if the maximum repository size changed with 6.1.3.0, couldnt find any 
> info about it in the release notes.
> 
> Since FastBack uses disk to store repository data, you would need quite some 
> diskspace attached to the FB server, but I guess you could bring the amount 
> needed down to a minimum by using de-dup on the FastBack repository. Only 
> down-side with de-duping is you will need the extra RAM & CPU power to handle 
> de-dup on the FB server.
> 
> Best Regards
> 
> Daniel Sparrman
> 
> -----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
> 
> 
> Till: ADSM-L AT VM.MARIST DOT EDU
> Från: "Prather, Wanda" <wPrather AT ICFI DOT COM>
> Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> Datum: 03/01/2011 01:28
> Ärende: Re: Ang: Windows servers with a kazillion files and Win2K8...
> 
> Two tiny questions:
> 
>>> a) Do the users need instant access to the files or is long-term archiving 
>>> an option?
> 
> Unfortunately, the app that creates the files distributes them across the 
> LUNS, and they are indexed in a giant SQL data base.  The files can't be 
> removed from their original location.
> 
>>> b) Not sure if it would help the issue with long respons times when 
>>> browsing, but HSM might be an option?
> 
> HSM leaves a stub file, so there would be even MORE files on each LUN!  Our 
> problem isn't the size of the LUNS, it's the number of files in the Windows 
> directory.
> 
>>> Your biggest problem isnt now, it's when u need to restore those 70 million 
>>> files. 
> 
> I agree completely!
> 
> Till: ADSM-L AT VM.MARIST DOT EDU
> Från: "Prather, Wanda" <wPrather AT ICFI DOT COM> Sänt av: "ADSM: Dist Stor 
> Manager" <ADSM-L AT VM.MARIST DOT EDU>
> Datum: 02/25/2011 20:03
> Ärende: Windows servers with a kazillion files and Win2K8...
> 
> I have a site with an application that generates kazillions of tiny files 
> that are stored forever.
> I've already yelled about it, but it's a purchased, customer-facing black-box 
> app that they really can't change.
> (Naturally, when it was bought umpty years ago, nobody thought about the 
> problem reaching this size or what the ramifications would be.)  Every day 
> the app creates more files.
> 
> They have multiple Win2K3 servers that already have multiple luns containing 
> over 35M files each, one is over 75M files.
> 
> We are using journaling to back them up successfully (most days).
> But it's a struggle just to expand the file tree with Windows explorer, and 
> there are exposures on the days when the journal gets overrun (takes 72 hours 
> for TSM to scan the filesystem and revalidate the journal).
> 
> Looking for anything that might help save our bacon.
> 
> Has anybody had experience with this issue and Win2K8?
> Does Win2K8 do any better than Win2K3 at handling huge numbers of files in 1 
> NTFS directory?
> Upgrading the OS is something application-independent we might be able to do.
> 
> Thanks for any insight!
> W
> 
> 
> Wanda Prather  |  Senior Technical Specialist  | wprather AT icfi DOT 
> com<mailto:wprather AT icfi DOT com>  |  www.jasi.com<www.jasi.com%20> ICF 
> Jacob & Sundstrom  | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | 
> 410.539.1135

<html>
<body>
<font face="arial" color=#808080 size="-2"><img
alt="Santos Logo" src="http://www.santos.com/library/logo.gif";>
<br>Santos Ltd A.B.N. 80 007 550 923<br>
Disclaimer: The information contained in this email is intended only for the 
use of the person(s) to whom it is addressed and may be confidential or contain 
privileged information. 
If you are not the intended recipient you are hereby notified that any perusal, 
use, distribution, copying or disclosure is strictly prohibited. 
If you have received this email in error please immediately advise us by return 
email and delete the email without making a copy.</font>
<font face="arial" color=#008000 size="-2">Please consider the environment 
before printing this email</font>
</body>
</html>