04-03-2013 12:11 AM
Read through the readme and admin guide, and still have questions about this mysterious dedupe service.
The admin guide recommends creating a regular domain account for accessing it (page 128/129). How does this account and credentials get applied to the client? Is it only used by the server to connect to the share or is it used by the clients? It's very confusing mostly because there's only about 1 or 2 pages of information on this new dedupe feature.
If the NUDF share is on the same server, isn't it going to cause a problem trying to connect with two different domain accounts to the same server from the same client? Moreover, do clients connect to the web ports or are they connecting directly to the file share?
Why does it require the shared domain account to be able to login locally on the domain controllers?
Why am I configuring all these AES options if its already protected with the credentials? What and where is it encrypting and why?
Why do all the clients have LiveUpdate installed when this service can't even be used to update the clients from 7 to 7.5? Is it possible to deploy the DLO client without installing LiveUpdate (cut down on the bloat)?
04-03-2013 02:49 AM
04-03-2013 01:13 PM
When it says "Only the administrator and users with “Dedupe Storage Location Access
Credential” account should have access to the network share location used as a
Dedupe Storage Location." does this mean the share permission should be granted to all DLO users, Administrator, and the Dedupe account or just Administrators and the Dedupe account?
If the client connect to both the web port and the network share, are they computing the dedupe information? Do the clients CPU take a hit when dedupe is enabled?
Is there any benefit to using this Dedupe service over something like the built-in Windows Server 2012 dedupe feature?
04-03-2013 09:22 PM
1.Administrators and the Dedupe Account.
2.DLO uses “Source Side” dedupe strategy, hence the client will have some CPU impact when the first backup is taken.But post the seeding, it shouldn’t matter since DLO sends only the changes and the backup triggers are spread over time.
3.Windows 2012 dedupe feature will be a target side dedupe, while the one with DLO is source side. DLO’s in-built dedupe can better understand the DLO backup configuration and the backup data. Also, DLO dedupe is content aware for PSTs. Hence using DLO dedupe would help in saving both the bandwidth and storage, with no compromise on the security of data in flight & at rest.
For Windows 2012 dedupe to be of good use for DLO data – encryption, compression and delta features in the backup profile should be disabled. That will lead to more bandwidth utilization for backups.
Also, Windows 2012 dedupe is not good for compound files like PSTs, since it isn’t content aware. Another problem would be security of data, since the backups aren’t going to be encrypted.