Hi UM1, in short - make sure to update to the latest version you're entitled to and/or apply any available hotfixes for the installed version. If the Recording Server is unable to stop gracefully, or takes more than a few minutes for the service to stop, it's something we should look at as a support case. It's possible that it could be caused by a storage system, and we can help you to determine whether or not that is the case.
Within the last year there has been an issue resolved where on some systems the Recording Server could to fail to successfully write the archives_cache.xml file when the service stops. Without a valid archives_cache.xml, the Recording Server will need to enumerate the contents of the media database on startup and this can take a lot of time depending on the amount of data and the storage system.
The message you see during startup while the media database index is rebuilding where it's suggested that the Recording Server could not connect to the database is a result of the Recording Server periodically asking the embedded media database service "What's the status of storage X?" and the media database service hasn't "mounted" that storage bank yet because it still needs to be reindexed, so it responds with "I don't know". So it doesn't indicate a problem connecting to the drive at the storage level -- just that the media database isn't ready yet at the application level.
With regard to the debate of having a single large drive, or a live drive with a separate archive drive - at the most simple level, archiving is work and having a single storage configuration with a single path to store all recordings means less work for the Recording Server. There is nothing wrong with this design, but there may be legitimate reasons why it's not the right design for a particular site.
Namely, if a re-index is necessary, the Recording Server (in current versions) will not start until all live drives are online. If it takes 6-12 hours to rebuild the index for a 60TB live drive, that means no live video or recording during that time frame unless you have a failover recording server available.
On the flip side, if you have a small live drive with a separate archive, a reindex may only take 5 minutes and then you'll have live/recording ability in a short time without the need of a failover recording server. But if the archive drive needs to be re-indexed too, it won't be able to receive data from the live drive until that is completed. In this case, there is a risk that the live drive will reach capacity before it can complete an archive session. When that happens, data will be dropped from the live drive in a first-in first-out fashion until archiving is possible.
There are other design considerations like hard drive expense -- small fast drives for live, big slower, less expensive drives for archive. Some storage vendors will spin down disks while not in use. The energy savings and eco-friendliness of that may make it attractive to separate archives from the live drive.
