Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

1465

June 22nd, 2009 01:00

what will happen if i update the target file

in the replistor mirroring options, i find reflect protection, protect target file, no mirror, copy on close and compatible, what are the difference between them, any document?
what will happen if i update the target file? is it allowed on target, will it cause target corruption?

151 Posts

June 22nd, 2009 05:00

Reflect Protection - Used for circular mirroring. Therefore, if you are replicating from A->B and also replicating the same data back from B->A, this option will tell RepliStor not to perpetually keep updating the same file if the I/O came from the machine that it just updated itself.

Protect Target Files - This option enables a read-only lock on the files on the Target. Therefore, nothing else can touch the files on the Target. This is a default and desired option so you know no one is updating files on the Target. If users can touch the data on the Target, it can lead to inconsistencies and corruption. RepliStor does not Mirror or track changes on the Target data.

No Mirror - This tells the Spec not to 'listen' for I/O and not to perform real-time replication (Mirroring) of the data. The data on the Target is kept up to date by doing Inc Sync's.

Copy on Close - This tells RepliStor to complete the replication of a file after it has been closed on the Source.

The RepliStor Administrator's Guide (via PowerLink) has all these above options detailed.

125 Posts

June 22nd, 2009 19:00

thanks for reply.
for reflect protection, since two site can update the file, will it cause inconsistency?
for protect target file, can i read or copy the target file? is it a mandatory lock or o advisory lock, in another words, can i update the target file if i want?

151 Posts

June 23rd, 2009 05:00

There are several caveats that come with Circular Mirroring and Reflect Protection so it is wise to be aware of them. Review the Admin Guide or the inline Help to review them. The thought is that the same file is only open on one of the machines at a time for changes. This is difficult to monitor so there is always the possibility.

It is not mandatory to make the Target files Read-Only (Protect Target Files). You can certainly change the file on the Target, but if you do several things occur:
- RepliStor does not know about the I/O and changes made to the file.
- The file on the target may not be the same as the Source.
- If changes are made on the Source, the file changes can be over-written on the Target (data loss).
- An Sync would be necessary to ensure the Target data is the same as the Source.

125 Posts

June 26th, 2009 03:00

but i think the lock is mandatory. i have done a test with protect target files. i can't delete or modify the target files, even if the replication link is down.

151 Posts

June 26th, 2009 05:00

The RepliStor server service on the Target maintains the lock. If you need to access the data on the Target w/ Protect Target Files enabled, even with the link down, you need to stop the service.

125 Posts

June 26th, 2009 08:00

I got it. :)

106 Posts

August 17th, 2009 07:00

Actually it it the RS Device Driver which enforces the lock of the Target's files. However, after the Target machine loses contact with the Source node for a specific length of time, RS on the Target will release the locks on the files.

If you want to open a file in read only mode (Notepad.exe) or copy a file that is being locked by RS it works fine. However if you try to open the file with the intention of writing the changes (Wordpad.exe) or try to delete the file, RS will prevent it because of the lock on the files (Target file Protection).

You can also grant permission to specific processes to write to protected file by going to Maintenance > Options > Processes and adding the process to the exception list (Protect target files exclude (target)). This will allow, for example, a backup program to write to the files for purposes of updating the files's attributes.

Generally it is not a good idea to allow updating th same file on two different servers. Only the last saved changes will win and, as noted by Duncan, it will result in data loss.
No Events found!

Top