Hi everyone.

I’d like to revisit the topic of secondary paths

Specifically, the problem remains (unless changes in recent versions have escaped my notice) that if the secondary path becomes unavailable—either partially or completely (e.g., missing .grp files)—SmarterMail treats those items as deleted messages and removes them from the index. Restoring them requires a rebuild, which is not only a hassle to perform for every domain but also results in data loss (such as message labels).

Of course, I don't *plan* on having a secondary path go offline, but by its very nature, a secondary path might reside on an external mount or a non-redundant drive, meaning things can always go wrong.

This issue came back to mind because I am currently migrating to a new server in a different farm.

During the initial setup, I need to perform a first sync of the domain folders. The fastest approach at this stage was using backups, though restoring 4TB of data is certainly not a quick process. Fortunately, one of the backup repositories is located at the destination server farm, so the restore will take about 20 hours.

However, I started thinking about a disaster recovery scenario where I would have to restore from a remote cloud (Acronis)—a process that takes a very long time.

This led me to reconsider secondary paths: in this scenario, the drives would have equal reliability, but in the event of a disaster, I could recover the primary path drive first, followed by the secondary one.

The user experience would be: a disaster occurs, but we’ve restored operations with the last 90 days of messages; over the following days, older messages will gradually reappear. However, the fact remains that the partial or total absence of .grp files in the secondary SM path should not result in their removal from the index.

There is still a need for an index removal procedure that is left to the administrator's discretion.