Hi there

I'm not sure how many files you will be holding in this fileserver cluster, but 
at some point you will reach a soft limit where inspecting the files will take 
to long for the backup to be done within a reasonable amount of time.

Another way of approaching large fileservers and the issues concerning backups 
are using the FastBack client instead of the normal TSM client. Since FastBack 
utilizies VSS snapshots by default, and only does bitlevel incremental backups, 
there is no need for inspection of files.

This will seriously lower the amount of time needed to perform an incremental 
backup. With FB you wont have the need to do any additional VSS snapshots to 
lower the restore time so that will eliminate the need to do different 
solutions to assure restore times are as short as possible.

Another positive effect of using the FastBack client is that the time-to-data 
in case of a restore will be quite short, due to the way FB mounts the backup 
image and lets users access this directly. That means that as soon as you start 
the restore of the filesystem, the files are immediatly accessible by your 
users (even though they havent actually been restored to the filesystem).

FB also has the CDP feature (Continous Data Protection) which might be 
something you'd like to use if we're looking at a large number of changed files 
on a daily basis (the issue with fileservers are normally that you only back it 
up once a day, thus loosing data since the last backup made on a restore event).

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: Steve Harris <steve AT STEVENHARRIS DOT INFO>
Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 06/24/2010 02:25
Ärende: Large fileserver on VMware design questions

Hi gang

One of my customers is implementing a consolidated fileserver. 
 
This will run in a two way MSCS Cluster.  At the moment they are looking at
one big filesystem though I will strenuously attempt to dissuade them from
that course.
 
Each machine in the cluster is a VM based on a different VMware physical
server, running windows 2008 r2 64 bit. TSM client will run on the VMs.
 
My proposed strategy is:
 
- Daily incremental.  With journalling. Standard cluster setup with one
scheduler for each machine and one for the cluster resource.  Journal
database resides on the cluster disk. 
- Weekly VCB image of the cluster disk(s) to enable fast restore after disk
failure. 
- Monthly incremental. Since journalling can't be used on more than one
node-name, the monthly incremental will take days and is run by a separate
scheduler in the cluster as follows:-
-- VSS snapshot of the cluster disk is mounted 
-- backup is taken 
-- snapshot is deleted. 
-- NB VSS snaphots are machine-specific so a failover kills this 

Questions
- Most changing documents are word/excel/powerpoint. Is subfile backup a
good fit here on the daily client? What about overhead? 
- How does one handle the possibility of failover when taking the VCB
image? The volume may be mounted on the other VM 
- can anybody help with scripts for the monthly VSS snapshot backup? 

Other than the one large filesystem issue is there any obvious flaw in my
strategy?

TSM Server is 5.5,  I will install the 6.2.1 client but this server won't
be upgraded for a while.

Thanks for your input

Steve.

Steven Harris
TSM Admin
Paraparaumu NZ