secondary path

Problem reported by Sabatino - 11/27/2025 at 4:29 AM

Submitted

I'm testing.

But what if I wanted to change the position of the secondary path?

Currently, there's only a disable secondary path, which from what I can see is moving all messages back to the main path.

A move or detach attach of the secondary path would be necessary.

Update:

Disabling the secondary path doesn't move the primary path. It simply stops moving them. The ones that are there remain there; it's no longer possible to modify or re-enable the secondary path.

Basically, you have to do everything manually on the JSON :-(

Sabatino Traini
Chief Information Officer

Genial s.r.l.
Martinsicuro - Italy

7 Replies

Reply to Thread

Sabatino Replied

11/27/2025 at 4:51 AM

Another question.

In which log does it write the moves?

How do I know if it's moving something?

What if the server/service is restarted while it's moving? Will everything remain consistent?

Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy

Gabriele Maoret - SERSIS Replied

11/27/2025 at 7:21 AM

mmmmh... It doesn't seem very reliable to me, at the moment...

Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)

Sabatino Replied

11/27/2025 at 9:18 AM

Hi Gabriele.

Let's just say they need to clarify how they set things up.

If you take a copy from the source and then delete it, the problem shouldn't even arise.

At worst, you'll end up with a double day (messages older than 365 days).

Furthermore, the message index is kept on the primary path.

Basically, it only moves the message files to the secondary path but keeps everything else on the primary path.

I also tried unlinking the secondary path on the fly to see what happens.

You simply don't see the message content, but you can see it in the list.

As soon as you restore, everything works again.

So let's say it's a nice feature because I can put potentially older messages on a secondary disk, which is slower, maybe not even mirrored, which costs me a lot less.

If you have reliable backups, since the messages are old, I think the problem isn't there.

What needs to be resolved and clarified is:

1) In my opinion, other options should be added to the available options, such as >2 years.

2) Understand how to change the secondary path.

edit:

I spoke too soon.

If the secondary path is lost, the emails disappear.

Only a rebuild will make them reappear.

But obviously, that's not a viable solution.

In my opinion, the secondary path should be the repository for .grp files only.

The indexes and email lists should remain on the primary path, and the lack of a secondary path or an associated .grp file should have no effect other than the inability to see the content of the specific email.

For the secondary path to be useful, we need to be able to use slower disks, as well as non-mirrored disks or disks that might be offline for any reason.

I'll open a ticket to discuss this with the developers.

Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy

Derek Curtis Replied

12/3/2025 at 7:50 AM

Employee Post

Hi, Sabatino

Thanks for this -- it's a good refresher on secondary storage. Just to clear a couple of things up:

"In my opinion, the secondary path should be the repository for .grp files only. The indexes and email lists should remain on the primary path, and the lack of a secondary path or an associated .grp file should have no effect other than the inability to see the content of the specific email."

This is, actually, how Secondary storage works. It only contains the GRP files -- indexes and CFGs stay on the primary path. Regarding availability of a message stored on a secondary path, and that path becoming inaccessible, yes the message will still appear in the messages list but will eventually be removed as SmarterMail can't find the actual message itself. If there is no message content, why display the message?

It's really a double-edged sword, though: if the message stays but the content is gone, that's a problem for the user, but if the message is removed, that, too, is a problem as the user will wonder where it went.

"For the secondary path to be useful, we need to be able to use slower disks, as well as non-mirrored disks or disks that might be offline for any reason."

This, too, is how secondary storage was designed: to be used to offload older emails to slower, less expensive storage. As for "disks that might be offline for any reason", that's a business decision, really. But if your secondary storage acts as an archive, more or less, why would you want/need to take those disks offline for an extended period of time?

Derek Curtis COO SmarterTools Inc. www.smartertools.com

Sabatino Replied

12/3/2025 at 11:08 AM

Hi Derek.

Thanks for the reply.

I don't think I'll keep the secondary path offline. I just don't want to worry about its reliability.

Of course, if it goes offline, I'll restore it as quickly as possible, but if messages are removed from the index in the meantime, I'll have to do a rebuild, which will lose some pieces, not to mention having to do it manually for each user and primary path.

I'd say the admin should decide whether to clear the index of messages that are no longer visible.

In addition to what I've said, if the index isn't touched, we can also detach the secondary path and attach it to another path, making the move easy.

Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy

Sabatino Replied

12/9/2025 at 12:53 AM

Hi Derek,

I've had a few days to think about it.

I'm reiterating the need to leave the message index untouched if the secondary path becomes unavailable.

Let me give you another reasoning.

If something goes wrong on the primary path, it can happen; it shouldn't, but it could.

Okay, the mail server stops, it's fixed, and everything restarts without data loss if the problem was simply a storage accessibility issue.

But if this happens to the secondary path... tragedy... all the indexes that go to the secondary path are lost, requiring a rebuild of all accounts, for every primary folder, with information loss due to the rebuild.

Therefore, if the secondary path becomes unavailable, the index must remain untouched, and a garbage collector must be started by the administrator.

Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy

Sabatino Replied

12/12/2025 at 1:50 AM

Hi Derek

I was waiting for your comment.

Add to that the fact that you have added the built-in volume mount feature and that you suggest it for secondary paths.

But think about it, who can guarantee that the mount will be successful after a reboot?

And if there is a secondary path on that mount.

As you can see, we always return to the case described.

The index should not be touched

Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text