File conflicts and lost data are two of the most common problems in file sharing. This is mainly because there’s no central authority to resolve these issues, which means that users must resort to manual intervention.
The recover files deleted from dfs share is a tool that recovers data that has been deleted or overwritten.
I’ve previously gone through situations in which DFS was implemented and made extremely accessible. In my post on DFS clustering, I stated that one of the disadvantages of DFS clustering is the risk of data corruption and loss owing to the possibility for two individuals to operate on the same file at the same time – there is no file lock. There is a simple solution for this, but it is far from ideal and comes at a price.
Before we get started, let’s have a look at
I’m assuming you know what we’re talking about and, by some chance, you’ve stumbled into this SEO-unfriendly site and want to learn more about this DFS miraculous technique (which it isn’t).
This post requires you have a DFS Namespace cluster with at least two servers in place, as well as shared folder replication.
To be clear, just because Namespaces and Replication are both part of DFS Management doesn’t imply they’re inseparable. Contrary to popular belief, they are distinct services and procedures with no obvious link between them.
Why am I making this statement? Because changing certain Namespace settings has no impact on replication.
As usual, the greatest approach to persuade oneself is to put things to the test. If you’re going to attempt this, please do it in a LAB or test setting rather than in production. I couldn’t be held liable if you broke or misplaced anything (even your mind after you realize the damage).
Please do a test first.
Is there a method to avoid data loss when two users access the same file on DFS at the same time?
If you want your DFS and file shares to be highly accessible, there is no “effective” solution for this issue with DFS.
If you need load balancing, this solution is not for you.
If you need a lot of availability, this isn’t the best option. But enough with the theory; let me show you what I’ve got.
I have two servers (TDFS1 and TDFS2) hosting DFS Namespace on the Data1 folder, which is also replicated across the two servers (TDFS1->TDFS2).
We can see that there are two referals for this link TDFS1 and TDFS2 – this client is connected to TDFS1. If I open my namespace TFileServerTFileServer (I know, I’m not the most imaginative person in the world) and right click on Data1 file share and open DFS tab, we can see that there are two referals for this link TDFS1 and TDFS2 – this client is connected to TDFS1. Another computer may be linked to TDFS2 and work on the same file. In the end, the person who saves last wins, and other modifications are overwritten.
When I open DFS Management, I can see my Data1 share under Namespaces, and we can see that both Referral Status on TDFS1 and TDFS2 is Enabled under Folder Targets.
The solution is straightforward: disable one of the referrals.
Because I showed you that my client is using TDFS1, I’m going to turn off TDFS1 and see what happens.
Okay, TDFS1 has been deactivated. Referral is disabled in Namespace.
Is this implying that your replication from TDFS1 to TDFS2 and vice versa has come to a halt? No
You can see that both targets and Connections are active when you open Replication for Data01.
That’s why I was rambling in the start: Namespaces and Replication are two different services.
You may also test replication by generating a few files and folders, even if one Namespace referral is blocked.
I’ve returned to the Client to check what’s up with our users. One moved to TDFS2, but the one who was editing on TDFS1 remained connected to that node. The second client connected to TDFS2 after a reset.
I can only see TDFS2 as a Referral after rebooting.
This implies that all of our users will be connected to the TDFS2Data1 share, which means no more duplicate files being accessed by various users at the same time and the risk of data loss.
This also implies that load balancing and automated high availability are not available.
Also, if someone is accessing the folder via another method, you haven’t gained anything by disabling Namespace referral (folder is still shared).
If you ever require it, just activate second referral (TDFS1) and all clients will see it following a reboot.
It is entirely dependent on your use case to determine whether or not this is appropriate for you. However, this will resolve your file conflict and data loss issues (caused by different users opening same file)
Behind the scenes, replication is taking place. And if one of your DFS nodes fails (due to a hardware failure), you can easily reactivate the second one you deactivated, resulting in little downtime.
Testing
Let’s put our modification to the test. On Client1, I generated a basic document in Libre Office and left it open.
Then I went to Client2 and attempted to access the same file.
Good. You can still overwrite if you try with notepad and a basic txt file. However, LibreOffice or MS Office perform the job properly.
Even on the node where we deactivated Namespace, the file I generated is still duplicated on both nodes. Perfect
So, it seems that the technique works.
Conclusion
This is far from a perfect solution, but it will save you the headache of lost files and changes, and it will allow you to have some level of high availability – because all changes are replicated on both servers, and if one fails, you can simply enable Namespace referral and people can continue to work.
Again, this isn’t perfect; try it out and see if it meets your needs; if it does, fantastic. If not, and you’re having a lot of DFS issues, it may be time to try something else.
Disclaimer
The get-dfsrpreservedfiles is a command-line tool that can be used to find the DFSR files that have been preserved on your computer. If you are experiencing file conflicts or lost data, you should use this tool.
Related Tags
- dfsrprivate access denied
- move deleted files to conflict and deleted folder
- dfs files disappearing
- dfs conflict and deleted folder location
- how to restore dfs replication
About The Author
