Unsolved
This post is more than 5 years old
3 Posts
0
485
March 17th, 2008 02:00
DiskXtender and Replistor. Replicating Stub Files
Hi,
We are using the latest versions of DiskXtender (6.20.090, Service Pack 1) and Replistor (6.2.4.4) in order to correctly replicate stub files with Replistor. This is documented in the Release Notes of both products, but it does not seem to work
correctly.
On my file server, I have created an extended drive, which archives files to a different (low cost storage) file server. Also I have created a replistor specification to replicate this folder to a central server.
On the file server I have selected the option: Replicate DX Stub Files. I have even rebooted all servers, just to make sure (it's a test environment).
The files get replicated to the central server, however the size of the files is 0 KB and the attributes are A (for archive). DiskXtender is not installed on the central server, Replistor is the same version (6.2.4.4).
Can anyone shed some light on this, I think I'm doing everything correctly, but it doesn't work as expected.
regards,
Ronald
We are using the latest versions of DiskXtender (6.20.090, Service Pack 1) and Replistor (6.2.4.4) in order to correctly replicate stub files with Replistor. This is documented in the Release Notes of both products, but it does not seem to work
correctly.
On my file server, I have created an extended drive, which archives files to a different (low cost storage) file server. Also I have created a replistor specification to replicate this folder to a central server.
On the file server I have selected the option: Replicate DX Stub Files. I have even rebooted all servers, just to make sure (it's a test environment).
The files get replicated to the central server, however the size of the files is 0 KB and the attributes are A (for archive). DiskXtender is not installed on the central server, Replistor is the same version (6.2.4.4).
Can anyone shed some light on this, I think I'm doing everything correctly, but it doesn't work as expected.
regards,
Ronald
No Events found!
jschrade1
106 Posts
0
March 17th, 2008 09:00
When RepliStor replicates a DX Stub file, it will appear on the Target node as a zero byte file. This is normal and expected. A Stub file contains only extended attribute information that DX uses to locate the file on the Extended Drive. The actual Stubs contain no data and are only meaningful to the node that owns the Stub. In other words the node that is hosting DX and RepliStor.
These Stub files are generally meaningless to a node that is not running DX. The reason that customers replicate these files is so that if the Source node failed and these files were lost, they could be copied back to the original server that created them. These files, along with the DX registry entries could be used to re-create the pointers to the actual data which resides on the extended storage media.
If you want to actually have a remote copy of the Data and not the Stub, you would not check the box to replicate stubs. Then RS would replicate the actual file data to your central server.
Ronaldpj
3 Posts
0
March 17th, 2008 14:00
Thanks for your answer, this does clarify some of the behavior we are seeing. However, we also tried to restore the files back to the originating server, without the stubs "reappearing". I'll try to explain what we did.
We created a copy of the archived files. We stopped the specification on the originating server. Then we deleted the files from the originating server.
After this the situation would be as if a user had deleted the files, but the files were still available on the back-up server.
We then "restored" the archived files and created a specification to replicate the files back from the target server to the originating server. This resulted in the 0-byte files appearing on the originating server, without any stub-information.
Maybe we need to do something else? There is no information (at least I didn't find any) about this in the documentation.
regards,
Ronald
jschrade1
106 Posts
0
March 18th, 2008 09:00
First let me point out that I am a RepliStor Support Engineer and answered your first question from that perspective.
After seeing your second forum question I wanted to touch base with the DXW folks and make sure I gave you an appropriate answer.
I have checked with both the DXW and the SVC and the answer is that using the Stubs to copy back to the Source node as a DR method is not currently supported.
The DXW and RepliStor teams have developed a DR solution but 1) it will require approval from the Solutions Validation Center (SVC) and 2) will only be provided by EMC Professional Services.
The solution itself is fairly complex and requires the use of additional executable binaries that will only be available from Professional Services.
I am sure you were hoping for a different answer. However, currently the above is the only information I can provide. If you would like to pursue a DR solution based on DXW and RepliStor, please contact your local EMC representative, who can arrange for an SVC approval and Professional Services contact points.
Thank you...JS