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