Video Screencast Help

DLO 7.5 Questions

Created: 03 Apr 2013 | 3 comments

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)?

Operating Systems:

Comments 3 CommentsJump to latest comment

SSwami's picture

1. The credentials in the Dedupe storage location(DSL) configuration page will be used by the client application to access the DSL share. Client app gets this credentials from the dedupe server, but it is not persisted anywhere in the client computer

2.It will not be a problem. Both the storage location share and the DSL share can exist in the same machine, but as long as the shares are different and the necessary permissions are given to the shares, it should just work fine. Clients connects to the dedupe server through the web port, and to the dedupe storage location by directly connecting to the file share using the credentials configured for the DSL.

3. Deduplication is about storing the shared data only once and making everybody to refer to it. Secretly shared credentials are used for enabling the secure shared access to the common data. The client app will impersonate itself to run under the credentials of the DSL user whenever required, and the impersonation requires the logon locally permission to be enabled in the DC

4. Data at rest in the DSL is accessible to the administrator/DSL user. In order to keep the data at rest safer from the eyes of the administrative users, encryption could be enabled. If enabled, the client app will encrypt the data and write it to the DSL share

5. Currently there is no way to omit liveupdate from client install.

NIzk99's picture

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?

SSwami's picture

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.