Creating Large Repository - Multiple locations or turn off write caching policy?

Support recommended turning off caching ...

The only time we recommend turning off caching is in Server 2008 R2. That is because we see high paged pool RAM usage in that scenario when write caching is on for the repository.

I have not seen this issue before with Rapid Recovery 6.1 and I just created a 40 TB repository the other day without any issue. I'd recommend either creating a repository with 2 extents or opening a support case so that we can troubleshoot. There should be no file size limitation as far as I know in Server 2016 that would block the creation of a large repository.

I just updated to 6.1.1 on Windows 2016 Server and get the same error trying to make any repository larger than 15Tb. Anyone else seeing this problem...

Hi aeibl:
This is something new. Windows 2008R2 had a 16TB repository size limitation, but we did not see any issues since.
I would suggest to attempt creating the repository with the cache disabled, see if it is possible and please let us know.
The issue you experience may be caused by some driver/hardware/policy limitation that we are not aware of. Your (in)ability to create a functional repository with the cache disabled may be an indication of it.
If it works, unlike Tim, I am not opposed to running RapidRecovery with the write caching disabled. It all depends on the specifics of your environment and of the load on the system. Running a system with multiple repository extents increases the resource consumption and requires increasing the effective size of the dedupe cache which you may or may not afford.
(Speaking of the dedupe cache -- I recommend a smaller dedupe cache on systems which are slow or have a chance of failure, to reduce the time it takes the cache to be flushed to disk and diminish the overall chances of repository corruption)

So there are 2 places to turn cache on or off. One on the hardware (volume) and one in the Storage Configuration when creating the Repository in RR. I have tried making a 43Tb repository with the hardware cache on and off with the Storage configuration on and get a failure every time, then I turn the cache off for the Storage Configuration and it succeeds both times. So the hardware cache is not an issue just the cache setting in the Storage Configuration for RR. Any idea of why that is an issue? Thanks.

Hi dlh:
So, the hardware cache is probably the disk level cache which is managed by the storage controller or the storage controller cache. There are a few options here; the safest is to have the disk cache disabled and the storage controller enabled and set to "writeback". If the Storage controller does not have an on-board cache this may not be possible (and caching is set automatically to write through). In this case, you may get a little extra performance by enabling the disk cache on each physical disk but take the risk of data corruption if one of the disks fails during a write operation. Most customers make a few performance tests before deciding how to deal with the disk cache. Again, everything above is related to hardware. The second element is the Windows cache which, basically does the same thing albeit slower and at a larger scale (keeps data into memory until it can be committed to disk). This is why, when you copy large amounts of data, you see the copying operation start very fast (as it is cached in the memory) and then slowing down as it needs to be committed to disk. My personal opinion is that Windows caching has very little impact on Rapid Recovery performance and the byproduct of saving a lot of memory when caching is disabled, it is well worth a minimal loss in performance. (By the way, to check if the caching policy is set to disabled, please check if HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Repositories\<RepositoryID>\FileConfigurations\<ExtentNumber>\Specification\WriteCachingPolicy = 3
where <REpositoryID> = a Guid and <ExtentNumber> = an integer (in your case it is 0)

These being said, I would like to ask you to check if SecureBoot is enabled (and disable it if it is). To do so, please run msinfo32.exe and scroll down to "Secure Boot State" in the System Summary. The reason is that the aavdisk driver does not run if secure boot is enabled. Although aavdisk is related to mounting volume there may be a check that is performed in relation with it.

If the issue persists, please open a case with support and we will try to determine together what is the cause of the issue you are dealing with.

What is the sector size of the storage you are using? Are you accepting the default sector size for the repository when the core software goes to create a new one?

This has been identified as product defect RR-102507 and will be fixed in a future release.

I have existing large Repo's (40+TB) that were created in an earlier version of the software, the new version will not let me add new large storage locations to these existing Repo's, unless I disable the cache first. I disabled cache, then I added the large storage locations to my Repo and re-enable cache.

I found the problem mentioned here:
support.quest.com/.../227257