We're think about updrading to Backup Exec 2010 with the deduplication option, but reading this: http://www.symantec.com/business/support/index?page=content&id=HOWTO21767 tells me it needs 8GB of RAM - how come?
If the deduplication is done on the client, why does it need so much memory? Our current server has 2GB of RAM, backing up about 2TB from 8 servers so we'd probably be looking at a new server for this.
Thanks
Even if your current server is 32-bit it will still support 4GB of RAM, and per the Technote you would need 3GB (1.5 x 2 TB of data = 3 GB of RAM)
Granted you would be looking at needing a 64-bit machine when you do replace the current media server, and that it will not support much in the way of data growth, that should still get you to the next budget cycle
I can tell you from my experience that on a server housing 2.2.TB of files that client dedupe is brutal 45- 50 MB per minute sometimes, 100 MB per minute if I'm lucky. On the same hardware specs (except for 24 gigs of ram MMs and -12 gigs on the file server) my dedupe server using media server dedupe is way faster at processing the files than the client side. I can process using media server deduping 2500MB per minute on that 2 TB job, not including verify which I haven't set up.
8GM of RAM is the minimum system requirements. And 64bit OS as well.
New capabilbities require new system specs.
From there, it's a good rule of thumb to have 1.5GB of RAM per TB of data BE is managing in the Dedupe folder.
Basically the recommendations came initailly from testing done on different hardware with a number of different specification remote servers (some using client side some not) They were then adjusted for the BE 2010 R2 release based on feedback we received against customer environments using the Pre-R2 version.
At a basic (very simplistic) level there are kind of two key processes going on against DeDup:
One is a form of compression (similar to ZIP) in that we are trying to identify chunks of data that are the same to only back them up once (most of this is the client side operation if so configured, but it does have to reference what is stored on the media server already so journalling updates do take place)
The other process is storing and tracking the chunks of data (maintaining catalogs and journals etc) which is mostly a media server process.
As such the minumim specification for what is a very intensive activity is there for a reason.
It is possible to see DeDup working with less spec - but scalability and performance would/could be a real problem. In fact some of our internal test setups do run in less - but a lot of them only backup 2-3 remote servers and only run test backups infrequently to meet specific tests - we also do not do any kind of performance testing with these under spec configurations as we expect the tests to not be particularly fast.
Thanks Colin, just seemed odd but that explains it. Just needed to be able to explain the inflated costs of my proposal to my boss
