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
|