DFS-R Ate My Files Again

[Marc K]

We have a file share set up with DFS-R providing replication from one server
to another. The home server is running Windows Storage Server 2003 R2 and
the remote server is running Windows Server 2003 R2 Enterprise Edition.



The other day, I noticed that almost the entire directory containing files
that I had been working on the previous day were gone. I checked the event
log on the remote server and noticed DFS-R entries stating that the files
had been moved to the conflict and deleted folder shortly after I had left
the office. Some files were lost because the size of the directory was
larger than the 660MB quota.



Now, I don't understand why this happened. My understanding is that if a
file is modified on two servers, DFS-R will move one copy to the Conflict
and Deleted folder and the then replicate the winner. This is not what
happened. My files were removed from the home server without any events
being added to the event log and moved to Conflict and Deleted on the remote
server leaving me with nothing in the original location on both servers.



This is the second time something like this has happened this year. We do
keep backups, so it was not as disastrous as it could have been. How can I
trust DFS-R when it just randomly decided to delete files like this?

[DaveMills]

Post by Marc K
We have a file share set up with DFS-R providing replication from one server
to another. The home server is running Windows Storage Server 2003 R2 and
the remote server is running Windows Server 2003 R2 Enterprise Edition.
The other day, I noticed that almost the entire directory containing files
that I had been working on the previous day were gone. I checked the event
log on the remote server and noticed DFS-R entries stating that the files
had been moved to the conflict and deleted folder shortly after I had left
the office. Some files were lost because the size of the directory was
larger than the 660MB quota.

DFSR does not sit happily with quotas. This is because there are some files no
replicated link .tmp files. These count towards the quota so the replicated copy
will have all the file except the .tmp files. It will therefore have free space
to store new files. However the master copy (to call it something) may still
have the .tmp file and be over quota. Hence replication fails.

Post by Marc K
Now, I don't understand why this happened. My understanding is that if a
file is modified on two servers, DFS-R will move one copy to the Conflict
and Deleted folder and the then replicate the winner. This is not what
happened. My files were removed from the home server without any events
being added to the event log and moved to Conflict and Deleted on the remote
server leaving me with nothing in the original location on both servers.
This is the second time something like this has happened this year. We do
keep backups, so it was not as disastrous as it could have been. How can I
trust DFS-R when it just randomly decided to delete files like this?

[Marc K]

Dave,

Perhaps I mispsoke when I mentioned the 660MB quota. What I meant was that
the area allocated for "Conflict and Deleted" is set to a maximum of 660MB.
I myself do not have a quota that would have intereferred with the
replication process.

Post by DaveMills

Post by Marc K
We have a file share set up with DFS-R providing replication from one server
to another. The home server is running Windows Storage Server 2003 R2 and
the remote server is running Windows Server 2003 R2 Enterprise Edition.
The other day, I noticed that almost the entire directory containing files
that I had been working on the previous day were gone. I checked the event
log on the remote server and noticed DFS-R entries stating that the files
had been moved to the conflict and deleted folder shortly after I had left
the office. Some files were lost because the size of the directory was
larger than the 660MB quota.

DFSR does not sit happily with quotas. This is because there are some files no
replicated link .tmp files. These count towards the quota so the replicated copy
will have all the file except the .tmp files. It will therefore have free space
to store new files. However the master copy (to call it something) may still
have the .tmp file and be over quota. Hence replication fails.

Post by Marc K
Now, I don't understand why this happened. My understanding is that if a
file is modified on two servers, DFS-R will move one copy to the Conflict
and Deleted folder and the then replicate the winner. This is not what
happened. My files were removed from the home server without any events
being added to the event log and moved to Conflict and Deleted on the remote
server leaving me with nothing in the original location on both servers.
This is the second time something like this has happened this year. We do
keep backups, so it was not as disastrous as it could have been. How can I
trust DFS-R when it just randomly decided to delete files like this?

--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

[itgal]

Marc K wrote on 12/09/2009 11:24 ET

Post by Marc K
We have a file share set up with DFS-R providing replication from one serve
to another. The home server is running Windows Storage Server 2003 R2 an
the remote server is running Windows Server 2003 R2 Enterprise Edition
The other day, I noticed that almost the entire directory containing file
that I had been working on the previous day were gone. I checked the even
log on the remote server and noticed DFS-R entries stating that the file
had been moved to the conflict and deleted folder shortly after I had lef
the office. Some files were lost because the size of the directory wa
larger than the 660MB quota
Now, I don't understand why this happened. My understanding is that if
file is modified on two servers, DFS-R will move one copy to the Conflic
and Deleted folder and the then replicate the winner. This is not wha
happened. My files were removed from the home server without any event
being added to the event log and moved to Conflict and Deleted on the remot
server leaving me with nothing in the original location on both servers
This is the second time something like this has happened this year. We d
keep backups, so it was not as disastrous as it could have been. How can
trust DFS-R when it just randomly decided to delete files like this

Hi, did you find a fix for this problem?

[a***@gmail.com]

I have the same problem, any ideas

[Falcon IT Services]

Hello MarcK,

Please be aware that when DFS exceeds the allotted database size, it enter a journal wrap state and this can cause problems. I would suggest increase the DB size and staging folders to accommodate the volume of data and changes. please check the logs to see if you have errors indicating a possible journal wrap.

https://www.falconitservices.com/?p=663

regards,

Miguel Fra
https://www.falconitservices.com