Interesting idea.  I am not sure just how to go about that.  Just deleting the files from the cur directory still leaves the various indexes unchanged.  I don't see any way in doveadm to clean that up.  I believe doveadm backup will build a new user that can be used to play around with.  I don't want to delete anything from the real user's mailbox.  Unfortunately, I have captured all the transmissions between the two systems.  It doesn't show anything of value since everything is encrypted.  I tried using the tcp transfer, but couldn't get it to work.

-- Doug

On Dec 10, 2022, at 11:09 AM, John Tulp <johntulp@tulpholdings.com> wrote:



On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
On Dec 4, 2022, at 1:42 PM, Doug Hardie <bc979@lafn.org> wrote:

On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> wrote:

I started to investigate using doveadm backup to backup my mail
system.  I have a small number of users and the mail store is not
large.  It uses maildir format.  I setup a test system that is not
connected to the internet and started up dovecot.  I used the
following command to backup one user:

doveadm backup -u ben remote:test

ben is the user is in the mail store.  Test is the actual server
name.  That worked just fine.  The maildir was copied completely
(as best as I can tell with ls).  Then I tried the second user:

doveadm backup -u jean remote:test

This gives 2 error messages:

doveadm(jean)[]<McRYOFI0jGN1MwAAmC+70w>: Error: Mailbox INBOX:
Failed to get attribute
vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox
attributes not enabled

doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command
returned error 65: ssh test doveadm dsync-server -ujean -U

In addition, the maildir directories are created, but there are no
emails in any of them (e.g., cur).  What is the problem with the
2nd and why does it behave differently from the first?

I managed to resolve most of the issue.  I use pigeonhole on the
primary server.  Apparently not having pigeonhole installed on the
test machine caused the errors above.  The test machine was never
intended to receive mail hence, no need to install pigeonhole as the
LDA would never be used.  However, when the backup was running, it
choked on transferring the sieve file.  I have no idea where the
mentioned file resides as I couldn't find it anywhere on the primary
server.  Installing pigeonhole resolved the issue for all but one
user. With that user, I get the following error messages:

doveadm(doug)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file
istream-seekable.c: line 238 (read_from_buffer): assertion failed:
(*ret_r > 0)
Abort

doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed:
EOF (last sent=mail, last recv=mail_request (EOL))

doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: Remote command
returned error 134: ssh test doveadm dsync-server -udoug -U

In addition, only a few cur files are transferred in INBOX.
Repeating the backup generates the same errors and no additional
emails are transferred.  I am wondering if the problem is something
in the INBOX.




I have pretty much reached a dead end.  I am unable to determine the
cause of this abnormal termination.  The logged messages don't give
much help.  I can't tell if it is the primary server or test machine
that is terminating ssh.  I have setup a second test machine.  Both of
the test machines are raspberry pi 4s.  The real backup machine is
intel.  On both the test machines, 2 of the three users are backedup
properly with no errors.  Only one use has the issue.  It builds the
directory structure correctly then starts transferring the INBOX cur
files.  Eight files are transferred correctly before it stop.  It is
the same set of 8 on both test machines.  That leads me to believe
there is something funny in one of the messages, but which one.  There
are over 100 messages in that directory.  The order of file transfer
is not by date.  


How do I get doveadm to tell me which file is being transferred when
the problem occurs?  

if the problem is in one of the messages, perhaps change the test set.
for convenience, can temporarily rename/move things to get them out of
the way. divide test set in half, then in half again, etc., to zero in
on the one causing the issue, that'll show if a particular message is
problem or not.

once you find a problem message, if the why isn't obvious, i'd try
looking at it in hex, check permissions, etc.

j