[BlueOnyx:26802] Re: Large cme-mailspool

[Robert Fitzpatrick]

Thanks as always, Michael. You always remind me of Easy Migrate and I do 
plan to use that for migration. Can it be used for backup since it pulls 
from another BO server? I could setup another BO server to pull from 
other various servers or have duplicate servers setup, but you never 
expect one to go down and I've always just had one standby server to CMU 
import whatever server may go down from the backup NAS source.

The job did finish eventually by this morning. However, the raqbackup 
notification came in at 10pm the night before, I guess it just hands off 
the pigz jobs and moves on to finish? Also, when you say delete 
~dcoolidge/mbox, you're referring to the users mailbox or some other 
backup location? I'm afraid there would not be anything to export if I 
delete the users mailbox.

I totally agree the size of the mailbox is abusive, I plan to talk to 
the user. Any suggestions for a way to archive mail on the server for a 
user who wants to use IMAP and keep all mail for eternity? Personally, I 
let my mail client do archiving locally.

> Michael Stauber via Blueonyx <mailto:blueonyx at mail.blueonyx.it>
> Thursday, March 07, 2024 7:50 PM
> Hi Robert,
>
>
>
> At this point my recollection about how CMU works is a bit rusty, as 
> it has pretty much been deprecated by Easy-Migrate and Easy-Backup. 
> But from what I seem to recall CMU does have a checksum for the export 
> files in its XML.
>
> So if you abort it while it is still exporting and then try to import 
> the (partial) CMU-Export somewhere? It may fail. At least for those 
> files that didn't export completely. It also may not have written out 
> the complete cmu.xml if you aborted it prematurely.
>
> That part is where I'm not entirely sure, as I haven't used CMU in 
> quite a while, nor have I aborted an export run of it recently.
>
> From what I can see in your process list it appears that it's still 
> exporting and using "pigz" to compress 4.users-dcoolidge-private.tar.gz.
>
> Means: It already has split the large tarball into four pieces so far 
> (there might be more) to make it more manageable. But compressing 46GB 
> with "pigz" will sure take a long time. It's optimized for smallest 
> possible file size and not for speed.
>
> I for sure would go in an nuke ~dcoolidge/mbox, because nobody needs a 
> 46GB mbox file. That's abusively excessive.
>
> My recommendation: Either wait for it to finish. Or kill the export, 
> delete ~dcoolidge/mbox and then export again.
>
> Robert Fitzpatrick via Blueonyx <mailto:blueonyx at mail.blueonyx.it>
> Thursday, March 07, 2024 5:29 PM
> Hi,
>
> On a 5209R I see a 43GB cum-mail spool created for a user box file of 
> the same size. I noticed the modified date of just a couple of hours 
> prior when the daily crackup finished successfully last night about 
> 10pm. I see still in the process:
>
> 18842 ?        S      1:07 /use/bin/perl /usr/cmu/scripts/5209Rscanout.pl
> 25360 ?        S      0:00 sh -c tar cf - 
> --files-from=/tmp/cmu-files.dat | pigz > 
> /backup/data/4.users-dcoolidge-private.tar.gz
> 25361 ?        S      0:30 tar cf - --files-from=/tmp/cmu-files.dat
>
> The 4 file was the last file for the user that appears to have 
> completed in the backup log with no errors and a reported size of 
> 32427539843. Did this not finish due to size? Is it safe to kill the 
> process and nuke the file?
>
> -- 
> Robert
>
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx

-- 
--
Robert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20240308/519276fd/attachment.html>