<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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.<div><br><div>
<div>-- Doug</div>
</div>
<div><br><blockquote type="cite"><div>On Dec 10, 2022, at 11:09 AM, John Tulp <johntulp@tulpholdings.com> wrote:</div><br class="Apple-interchange-newline"><div><div><br><br>On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:<br><blockquote type="cite"><blockquote type="cite">On Dec 4, 2022, at 1:42 PM, Doug Hardie <bc979@lafn.org> wrote:<br><br><blockquote type="cite">On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> wrote:<br><br>I started to investigate using doveadm backup to backup my mail<br>system. I have a small number of users and the mail store is not<br>large. It uses maildir format. I setup a test system that is not<br>connected to the internet and started up dovecot. I used the<br>following command to backup one user:<br><br>doveadm backup -u ben remote:test<br><br>ben is the user is in the mail store. Test is the actual server<br>name. That worked just fine. The maildir was copied completely<br>(as best as I can tell with ls). Then I tried the second user:<br><br>doveadm backup -u jean remote:test<br><br>This gives 2 error messages:<br><br>doveadm(jean)[]<McRYOFI0jGN1MwAAmC+70w>: Error: Mailbox INBOX:<br>Failed to get attribute<br>vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox<br>attributes not enabled<br><br>doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command<br>returned error 65: ssh test doveadm dsync-server -ujean -U<br><br>In addition, the maildir directories are created, but there are no<br>emails in any of them (e.g., cur). What is the problem with the<br>2nd and why does it behave differently from the first?<br></blockquote><br>I managed to resolve most of the issue. I use pigeonhole on the<br>primary server. Apparently not having pigeonhole installed on the<br>test machine caused the errors above. The test machine was never<br>intended to receive mail hence, no need to install pigeonhole as the<br>LDA would never be used. However, when the backup was running, it<br>choked on transferring the sieve file. I have no idea where the<br>mentioned file resides as I couldn't find it anywhere on the primary<br>server. Installing pigeonhole resolved the issue for all but one<br>user. With that user, I get the following error messages:<br><br>doveadm(doug)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file<br>istream-seekable.c: line 238 (read_from_buffer): assertion failed:<br>(*ret_r > 0)<br>Abort<br><br>doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed:<br>EOF (last sent=mail, last recv=mail_request (EOL))<br><br>doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: Remote command<br>returned error 134: ssh test doveadm dsync-server -udoug -U<br><br>In addition, only a few cur files are transferred in INBOX.<br> Repeating the backup generates the same errors and no additional<br>emails are transferred. I am wondering if the problem is something<br>in the INBOX.<br></blockquote><br><br><br><br>I have pretty much reached a dead end. I am unable to determine the<br>cause of this abnormal termination. The logged messages don't give<br>much help. I can't tell if it is the primary server or test machine<br>that is terminating ssh. I have setup a second test machine. Both of<br>the test machines are raspberry pi 4s. The real backup machine is<br>intel. On both the test machines, 2 of the three users are backedup<br>properly with no errors. Only one use has the issue. It builds the<br>directory structure correctly then starts transferring the INBOX cur<br>files. Eight files are transferred correctly before it stop. It is<br>the same set of 8 on both test machines. That leads me to believe<br>there is something funny in one of the messages, but which one. There<br>are over 100 messages in that directory. The order of file transfer<br>is not by date. <br><br><br>How do I get doveadm to tell me which file is being transferred when<br>the problem occurs? <br></blockquote><br>if the problem is in one of the messages, perhaps change the test set.<br>for convenience, can temporarily rename/move things to get them out of<br>the way. divide test set in half, then in half again, etc., to zero in<br>on the one causing the issue, that'll show if a particular message is<br>problem or not.<br><br>once you find a problem message, if the why isn't obvious, i'd try<br>looking at it in hex, check permissions, etc.<br><br>j<br><br></div></div></blockquote></div><br></div></body></html>