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.sparr...@exist.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@VM.MARIST.EDU> skrev: ----- > > > Till: ADSM-L@VM.MARIST.EDU > Från: "Prather, Wanda" <wprat...@icfi.com> > Sänt av: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.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@VM.MARIST.EDU > Från: "Prather, Wanda" <wprat...@icfi.com> Sänt av: "ADSM: Dist Stor Manager" > <ADSM-L@VM.MARIST.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 | > wprat...@icfi.com<mailto:wprat...@icfi.com> | www.jasi.com<www.jasi.com%20> > ICF Jacob & Sundstrom | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | > 410.539.1135