I have a server that's has 1 drive fully protected and uses DFRS to 
replicate to other sites, recently we made some ACL changes on a lot of 
data, and DFRS just pushes the ACL changed with very little data transferred 
over the wire, but DPM counts it as a full file change and filled up the 
recovery point volume. Is that expected? It would seem that an ACL change 
could be stored is a much smaller format then the full file being backed up, 
if something like DFRS can do it.

        Changing ACLs of the files/directories alone should not trigger the 
entire file transfer. Even when only few blocks of the files changed, then 
also DPM transfers only the changed blocks.  But some attributes addition 
like compression/encryption may change the entire file and the entire file 
will be transferred when the attribute is applied on the file for the first 
time. Can you please make sure that you are finding the similar behavior? 
Otherwise we should take a look at what is causing the entire file being 
transferred? Can you please provide more details on what files its 
happening, which attribute is causing this problem, DPM version/Service pack 
you are using?

Thanks,
Praveen D [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights

<C.Kelly@noemail.noemail> wrote in message 
news:#iUxig8tKHA.4752@TK2MSFTNGP04.phx.gbl...
> I have a server that's has 1 drive fully protected and uses DFRS to 
> replicate to other sites, recently we made some ACL changes on a lot of 
> data, and DFRS just pushes the ACL changed with very little data 
> transferred over the wire, but DPM counts it as a full file change and 
> filled up the recovery point volume. Is that expected? It would seem that 
> an ACL change could be stored is a much smaller format then the full file 
> being backed up, if something like DFRS can do it.
>
>
>
> 

This is a DPM 2010 server that was upgraded from 2007SP1 protecting Windows 
2003 server's data volumes. I normally get about 20MB to 200MB of changes 
per day max on the volumes protection over the last 30 days, I then changed 
the ACLs on a directory that was about 120GB and it filled up my recovery 
point totally and had to auto expand. I can check the jobs and the day I 
changed the ACLs a sync of 83GB took place filling up the recovery point 
volume and then after the auto expansion another sync for 28GB. This 
happened once before with 2007SP1 I changed the ACLs on a whole volume and 
the only way I could fix it was to delete the protection group and start 
again because it wanted to sync the whole volume again.


"Praveen D [MSFT]" <praveend@microsoft.com> wrote in message 
news:%23LDEIcguKHA.2436@TK2MSFTNGP04.phx.gbl...
>        Changing ACLs of the files/directories alone should not trigger the 
> entire file transfer. Even when only few blocks of the files changed, then 
> also DPM transfers only the changed blocks.  But some attributes addition 
> like compression/encryption may change the entire file and the entire file 
> will be transferred when the attribute is applied on the file for the 
> first time. Can you please make sure that you are finding the similar 
> behavior? Otherwise we should take a look at what is causing the entire 
> file being transferred? Can you please provide more details on what files 
> its happening, which attribute is causing this problem, DPM 
> version/Service pack you are using?
>
> Thanks,
> Praveen D [MSFT]
> This posting is provided "AS IS" with no warranties, and confers no rights
>
> <C.Kelly@noemail.noemail> wrote in message 
> news:#iUxig8tKHA.4752@TK2MSFTNGP04.phx.gbl...
>> I have a server that's has 1 drive fully protected and uses DFRS to 
>> replicate to other sites, recently we made some ACL changes on a lot of 
>> data, and DFRS just pushes the ACL changed with very little data 
>> transferred over the wire, but DPM counts it as a full file change and 
>> filled up the recovery point volume. Is that expected? It would seem that 
>> an ACL change could be stored is a much smaller format then the full file 
>> being backed up, if something like DFRS can do it.
>>
>>
>>
>> 

        If this can be reproed on your environment can you please share the 
repro steps. We would like to know what ACL change has triggered the entire 
file to transfer. Are these files present on DFSR? Were the files related to 
any application? If this can't be reproed on our side we would like to 
investigate the instance on your side. Can you please restore these file 
versions from before the entire transfer and after the entire file transfer 
to different locations and compare the changes between these two versions? 
If you still feel the entire file transfer was un-necessary(if there is no 
change between those two files versions except acls) can you please send a 
mail regarding this issue at praveend at microsoft dot com so that we can 
fast track the issue.

Thanks,
Praveen D [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

<C.Kelly@noemail.noemail> wrote in message 
news:#knIGnhuKHA.6124@TK2MSFTNGP04.phx.gbl...
> This is a DPM 2010 server that was upgraded from 2007SP1 protecting 
> Windows 2003 server's data volumes. I normally get about 20MB to 200MB of 
> changes per day max on the volumes protection over the last 30 days, I 
> then changed the ACLs on a directory that was about 120GB and it filled up 
> my recovery point totally and had to auto expand. I can check the jobs and 
> the day I changed the ACLs a sync of 83GB took place filling up the 
> recovery point volume and then after the auto expansion another sync for 
> 28GB. This happened once before with 2007SP1 I changed the ACLs on a whole 
> volume and the only way I could fix it was to delete the protection group 
> and start again because it wanted to sync the whole volume again.
>
>
> "Praveen D [MSFT]" <praveend@microsoft.com> wrote in message 
> news:%23LDEIcguKHA.2436@TK2MSFTNGP04.phx.gbl...
>>        Changing ACLs of the files/directories alone should not trigger 
>> the entire file transfer. Even when only few blocks of the files changed, 
>> then also DPM transfers only the changed blocks.  But some attributes 
>> addition like compression/encryption may change the entire file and the 
>> entire file will be transferred when the attribute is applied on the file 
>> for the first time. Can you please make sure that you are finding the 
>> similar behavior? Otherwise we should take a look at what is causing the 
>> entire file being transferred? Can you please provide more details on 
>> what files its happening, which attribute is causing this problem, DPM 
>> version/Service pack you are using?
>>
>> Thanks,
>> Praveen D [MSFT]
>> This posting is provided "AS IS" with no warranties, and confers no 
>> rights
>>
>> <C.Kelly@noemail.noemail> wrote in message 
>> news:#iUxig8tKHA.4752@TK2MSFTNGP04.phx.gbl...
>>> I have a server that's has 1 drive fully protected and uses DFRS to 
>>> replicate to other sites, recently we made some ACL changes on a lot of 
>>> data, and DFRS just pushes the ACL changed with very little data 
>>> transferred over the wire, but DPM counts it as a full file change and 
>>> filled up the recovery point volume. Is that expected? It would seem 
>>> that an ACL change could be stored is a much smaller format then the 
>>> full file being backed up, if something like DFRS can do it.
>>>
>>>
>>>
>>>
>
> 

I'm sorry I haven't replied sooner, I'm on a trip and will be back in the 
office next week, but to answer a few questions, the ACL change was triggered 
via windows explorer, but the files are DFRSed which may have something to do 
with the problem. I have 4 servers with DFRS running on a set of folders, one 
of those servers has DPM protection. The ACL changes were made on a different 
server then the one DPM was protecting, those changes were replicated and 
then DPM backed up the full files, the changes that DFRS moved over the wire 
was very small, but DPM re-backuped up 100GB of data.

When I get back to the office I can run the restore process and see if there 
are any differences in the files and will email you. thanks

"Praveen D [MSFT]" wrote:

> 
>         If this can be reproed on your environment can you please share the 
> repro steps. We would like to know what ACL change has triggered the entire 
> file to transfer. Are these files present on DFSR? Were the files related to 
> any application? If this can't be reproed on our side we would like to 
> investigate the instance on your side. Can you please restore these file 
> versions from before the entire transfer and after the entire file transfer 
> to different locations and compare the changes between these two versions? 
> If you still feel the entire file transfer was un-necessary(if there is no 
> change between those two files versions except acls) can you please send a 
> mail regarding this issue at praveend at microsoft dot com so that we can 
> fast track the issue.
> 
> Thanks,
> Praveen D [MSFT]
> This posting is provided "AS IS" with no warranties, and confers no rights.
> 
> <C.Kelly@noemail.noemail> wrote in message 
> news:#knIGnhuKHA.6124@TK2MSFTNGP04.phx.gbl...
> > This is a DPM 2010 server that was upgraded from 2007SP1 protecting 
> > Windows 2003 server's data volumes. I normally get about 20MB to 200MB of 
> > changes per day max on the volumes protection over the last 30 days, I 
> > then changed the ACLs on a directory that was about 120GB and it filled up 
> > my recovery point totally and had to auto expand. I can check the jobs and 
> > the day I changed the ACLs a sync of 83GB took place filling up the 
> > recovery point volume and then after the auto expansion another sync for 
> > 28GB. This happened once before with 2007SP1 I changed the ACLs on a whole 
> > volume and the only way I could fix it was to delete the protection group 
> > and start again because it wanted to sync the whole volume again.
> >
> >
> > "Praveen D [MSFT]" <praveend@microsoft.com> wrote in message 
> > news:%23LDEIcguKHA.2436@TK2MSFTNGP04.phx.gbl...
> >>        Changing ACLs of the files/directories alone should not trigger 
> >> the entire file transfer. Even when only few blocks of the files changed, 
> >> then also DPM transfers only the changed blocks.  But some attributes 
> >> addition like compression/encryption may change the entire file and the 
> >> entire file will be transferred when the attribute is applied on the file 
> >> for the first time. Can you please make sure that you are finding the 
> >> similar behavior? Otherwise we should take a look at what is causing the 
> >> entire file being transferred? Can you please provide more details on 
> >> what files its happening, which attribute is causing this problem, DPM 
> >> version/Service pack you are using?
> >>
> >> Thanks,
> >> Praveen D [MSFT]
> >> This posting is provided "AS IS" with no warranties, and confers no 
> >> rights
> >>
> >> <C.Kelly@noemail.noemail> wrote in message 
> >> news:#iUxig8tKHA.4752@TK2MSFTNGP04.phx.gbl...
> >>> I have a server that's has 1 drive fully protected and uses DFRS to 
> >>> replicate to other sites, recently we made some ACL changes on a lot of 
> >>> data, and DFRS just pushes the ACL changed with very little data 
> >>> transferred over the wire, but DPM counts it as a full file change and 
> >>> filled up the recovery point volume. Is that expected? It would seem 
> >>> that an ACL change could be stored is a much smaller format then the 
> >>> full file being backed up, if something like DFRS can do it.
> >>>
> >>>
> >>>
> >>>
> >
> > 
> .
>