Hey Zoltan
Key points for backing up isilon:
1 Each isilon node is limited by it's CPU/protocol rather than Networking
(other than the new G6 F800's )
2 To increase throughput to/from isilon increase the number isilon nodes you
access via your clients
3 To increase the isilon nodes you access
Robert,
Thanks for the insight/suggestions. Your scenario is similar to ours but
on a larger scale when it comes to the amount of data/files to process,
thus the issue (assuming such since you didn't list numbers). Currently we
have 91 ISILON nodes totaling 140M objects and 230TB of data. The
Zoltan, et al:
:IF: I understand the scenario you outline originally, here at Cornell we are
using two different approaches in backing up large storage arrays.
1. For backups of CIFS shares in our Shared File Share service hosted on a
NetApp device, we rely on a set of Powershell scripts to
I will need to translate to English but I gather it is talking about the
RESOURCEUTILZATION / MAXNUMMP values. While we have increased MAXNUMMP to
5 on the server (will try going higher), not sure how much good it would
do since the backup schedule uses OBJECTS to point to a specific/single
Hi Del.
Tagging is OK. It means that our VMware guys will be managing the backups
and I am not sure if they will choose TSM.
Deploying an extra disk just for pagefile.sys, reconfiguring and rebooting
thousands of VMs is a lot of work. Much easier if the product has the
ability to do exclusions.
