I have been experimenting with RST software. Can someone explain the difference between setting up a RAID 1 array and setting up a Recovery drive set to "continuous" update, as it would seem they are doing the same thing.

[Hollowsword]

I understand that in a scenario of a laptop with 2nd "recovery" hard disk in a docking station, only the primary disk data changes will be synced to the recovery disk and not perform a complete drive remirror..

I ask because I set up a 2 disk recovery array in a desktop computer with Z77 chipset, and set to "On Request" updating, that works as it should as soon as the array has mirrored , ie: if I initiate an update it does so very quickly as it copies only the changes from the last sync to the recovery drive; but once the computer is shut down and restarted, if I then perform an "On Request" update, it starts from 0% and does a full sync.

I like the idea of the recovery drive disconnecting after a sync, as it will prevent any virus or crypto from attacking the other half of the mirror, as it would do in a regular RAID 1 array.

There does not appear to be much indepth documentation on this useful "on demand recovery" feature.

[Hollowsword]

Hi Alberto

You have not responded to my questions. It appears you have lost track of this case.

Can you answer these two questions please.

1- I asked why Rapid Recover was doing a full sync and not a delta sync after a reboot.

2- I asked what the difference is between the IRST options: "Delete RAID Volume" and "Reset Disks To Non-RAID".

Regards

[Alberto_R_Intel]

Hi ABarr17, Sure, we will continue with our research on this topic, as soon as I get more information I will post it on this thread. Regards, Alberto R. Intel Customer Support Technician Under Contract to Intel Corporation

[Hollowsword]

Hi Alberto

Do you not have any direct access to Intel support who can answer these two questions for you?

Each reply that I have so far received has given me conflicting information to your previous answers.

Regards

[Alberto_R_Intel]

Hi ABarr17, Yes, actually I just received more details about this topic: To answer your first question, what is happening is that when the On Demand Update initiates, the percentage that you see is just a completion percentage of the current run and not of the full mirror. And in reference to your second question, what the difference is between the Intel® RST options: Delete RAID Volume" and "Reset Disks To Non-RAID" , as mentioned previously, theoretically, Delete the Volume, erases data and structure. This means data is no longer accessible. It might be that the computer manufacturer has made changes on the RAID BIOS. You cannot recover data once a volume is deleted. This is documented on the Intel® Rapid Storage help. The Reset disk to non RAID, only deletes the structure, it keeps data intact. “Delete RAID Volume” - Remove the RAID Volume by deleting the meta data on all the disks that make up the RAID volume. I think there’s an option to Preseve customer data on the disks. “Reset Disks to Non-RAID” – Deleting the meta data on the disk that used to belong to a RAID Volume and make the disk available to be used in Intel® RST Raid volume again. Regards, Alberto R. Intel Customer Support Technician Under Contract to Intel Corporation

[Hollowsword]

Hi Alberto

1. On demand Updates

What I am telling you is that the "Current Run" as you call it, is performing a full sync and not a delta sync after the PC is rebooted.

How else can you explain it taking a few minutes before a reboot and two hours after a reboot, (the initial sync also takes two hours) ?

1. Delete RAID volume vs Reset Disks to Non-RAID.

Where are you getting your information from Alberto?

You keep supplying me with completely wrong and conflicting information.

I already told you that I myself used the "Delete RAID Volume" option and was left with two independent non-RAID disks will all data completely intact on both disks.

A search on the Intel website substantiates this: https://www.intel.co.uk/content/www/uk/en/support/articles/000006188/technologies.html

Alberto, I can see you have tried your best and I appreciate your time spent on here, but can you escalate this case to someone else higher up the support chain, as we seem to be wasting each others time now and getting nowhere.

For clarity, my questions are:

1- I asked why Rapid Recover was doing a full sync and not a delta sync after a reboot.

2- I asked what the difference is between the IRST options: "Delete RAID Volume" and "Reset Disks To Non-RAID".

Regards

[Hollowsword]

​Hi Alberto

Did you escalate this case as I requested?

I asked a couple of questions on January 29th and for some reason I cannot get a coherent answer to them.

Can you confirm if you can escalate this case to someone higher up the support chain please.

Thanks

[Alberto_R_Intel]

Hi ABarr17, I just received another update in reference to this subject. Question 1: After checking to try to replicate this issue, engineering was unable to reproduce the sync issue with rapid recovery in update mode. The update is very fast after reboot. Question 2 “Delete RAID Volume” Delete RAID Volume and RAID information meta-data on all the disks that make up the current RAID volume. The RAID Volume is deleted after this operation. All the disks show as non-RAID. “Reset Disks to Non-RAID”: Delete RAID information meta-data on a disk only. If you perform this operation on a disk that is part of a RAID volume in your system, only the disk is removed from the RAID Volume. The RAID volume is left alone. The disk that you perform this operation on shows as non-Raid. If you have a RAID Volume that uses 2 disks (like RAID1), The RAID volume will show missing disk. Regards, Alberto R. Intel Customer Support Technician Under Contract to Intel Corporation

[Hollowsword]

Hi Alberto

Thanks for the response.

Re: Question 1:

Do you know what the BIOS / OS settings are for the SATA ports in the machine that the engineering team used to try and reproduce the sync issue?

I am wondering if it could be the SATA port mode, Hot Plug enable or any cache settings etc. that could be causing the sync issue.

Re: Question 2:

It seems clear now that the fundamental difference between these two options is that :

“Delete RAID Volume” is working at the array VOLUME level.

(Deleting a RAID volume will cause all RAID and USER data to be lost on anything BUT a RAID 1 / Recovery volume.

RAID 1 type arrays would be left with two identical (but now independent) disks and with all user data intact).

“Reset Disks to Non-RAID” is working at the array DISK level.

(Resetting a single RAID array member disk to "Non-RAID" on any good (FAULT TOLERANT) RAID array will remove that disk's RAID metadata (and thus remove that disk from the array) and should leave the array degraded as it is no longer fault tolerant, but fully functional.

“Reset Disks to Non-RAID” applied to a single member disk of a good RAID 1 array would delete only the RAID metadata from it and thus remove that member disk from the array. All user data would remain intact on both disks.

The remaining RAID 1 member disk would now show as degraded or "missing disk" but would be fully functional.

“Reset Disks to Non-RAID” applied to this remaining RAID 1 member disk would again delete only the RAID metadata and leave a fully functional independent disk with all user data intact.

This complete procedure of applying “Reset Disks to Non-RAID” to both RAID 1 member disks individually, would leave the array in the same state as "Delete RAID Volume" would, ie: you will be left with two identical (but now independent) disks and with all user data intact.

In my case of a RAID 1 or a Recovery Array, either of these two options would have a similar outcome leaving all user data intact on both disks.

It took a while but I think we have got there.

Many thanks for persevering with this Alberto.

Regards...

[Alberto_R_Intel]

Hi ABarr17, You are very welcome. We are glad to hear that the information provided previously was useful for you. In reference to your question about the BIOS / OS settings for the SATA ports that the engineering team used, I will try to gather as much information as I can to provide the details you are requesting, that information is not always available so I cannot guarantee that I will be able to provide it, but I will do my best to try to gather it. Regards, Alberto R. Intel Customer Support Technician Under Contract to Intel Corporation

[Alberto_R_Intel]

Hi ABarr17, I just received an update on this case, just to let you know, the information requested regarding the BIOS/OS settings for the SATA ports that the engineering team used is not available since the ticket was assigned to random engineers. We recommend to get in contact with the manufacturer of the computer/board to verify the BIOS recommended settings. Let me apologize for any inconvenience. Regards, Alberto R. Intel Customer Support Technician Under Contract to Intel Corporation

[Hollowsword]

Hi Alberto

Many thanks for your response and continued commitment to this issue.

You advised me that :

"After checking to try to replicate this issue, engineering was unable to reproduce the sync issue with rapid recovery in update mode. The update is very fast after reboot."

Now you advise me that:

"the information requested regarding the BIOS/OS settings for the SATA ports that the engineering team used is not available since the ticket was assigned to random engineers."

I assume that these "random engineers" who tried to reproduce the sync issue and who discovered that "The update is very fast after reboot" would have reported their findings back to their manager or updated the service ticket with this information.

How is it possible that a service ticket has no trail of who has actually worked on it.

From what I would imagine, service tickets are usually "assigned to" or "picked up" by somebody who then takes ownership of the call, they then work on the task, update the call details with their findings, then once marked as resolved would close the call ticket.

Do these "random engineers" you mention work for Intel directly, or are they subcontracted to a third party service provider, or are they literally unidentified "random engineers" who just happened to walk into Intel's offices that particular day, helped out in the computer lab, and then left the Intel office and were never to be seen or heard of again.

A very intriguing support system Intel seems to have.

May I ask, what company do you work for Alberto, or are you an unidentifiable "Random Intel Customer Support Technician"?

I ask because I see in your signature it says "Under Contract to Intel Corporation" and I am very curious as to how the Intel support structure operates, and from where you are obtaining your technical information.

Regards

[Alberto_R_Intel]

Hi ABarr17, You are very welcome. Regarding your questions and the information you are requesting, I just wanted to let you know that those details are confidential, there are some tasks assigned to the engineering team and once they do the lab they provide the results to us so we can post the information in the thread. If you need further data about this matter, we suggest to get in contact directly with the manufacturer of the computer/board and maybe to try to escalate the case to a higher level to gather all the details that you are looking for. Regards, Alberto R. Intel Customer Support Technician Under Contract to Intel Corporation

[Hollowsword]

Hi Alberto

Once again thank you for your response.

I can completely understand that you wish to keep the information that I requested confidential.

It is however a pity that the random anonymous engineer who took the time to replicate the sync issue was not able to enter the BIOS of the test machine and report back on what the SATA port settings were. This would take a few minutes at most, and if not too exhausted, the test machine Windows and IRST cache settings would have been useful to know too in helping to diagnose where the sync issue lies.

Merely advising that "engineering was unable to reproduce the sync issue" helps no one really, does it Alberto.

Anyway, thank you once again for the very helpful and invaluable technical support that you have provided over the last few months Alberto. It genuinely has been a pleasure, a learning experience and an education for me.

Regards

[Alberto_R_Intel]

Hi ABarr17, You are very welcome. It has been a pleasure for me too to try to assist you. Thank you very much for your feedback as well, I really appreciate that. We are sure that all the information posted on this thread will be very helpful for all the peers in the Intel® communities. Any other inquiry, do not hesitate to contact us again. Regards, Alberto R. Intel Customer Support Technician Under Contract to Intel Corporation