On 12/19/2014 01:31 PM, Patrick Goetz wrote:
Super helpful -- thanks!
I only have one additional question:
On 12/19/2014 09:31 AM, Nic Bernstein wrote:
My current plan is to use imapsync for the migration and then
replication to another dummy server for backup, assuming I can figure
out how to
Super helpful -- thanks!
I only have one additional question:
On 12/19/2014 09:31 AM, Nic Bernstein wrote:
>> My current plan is to use imapsync for the migration and then
>> replication to another dummy server for backup, assuming I can figure
>> out how to set up replication.
>
> I strongly rec
On 12/19/2014 06:17 AM, Patrick Goetz wrote:
Nic,
Thanks for that detailed explanation. I still feel myself somewhat
stymied by either the documentation (or lack thereof) or perhaps an
unfortunate case of being somewhat feeble-minded. Here are some follow
up comments/questions:
On 12/18/2014
Nic,
Thanks for that detailed explanation. I still feel myself somewhat
stymied by either the documentation (or lack thereof) or perhaps an
unfortunate case of being somewhat feeble-minded. Here are some follow
up comments/questions:
On 12/18/2014 9:59 AM, Nic Bernstein wrote:
> I will say
7;re
presented here. Firstly, however, I would like to echo some confusion
as to the purpose of cyrdump. It seems to have been around since at
least 2.2.3, but documentation has appeared only fleetingly, and says
little about the program:
NAME
cyrdump - dump mailboxes to stdout
S
Hello Patrick and Cyrus friends,
I have used imapsync to transfer the imap data from computer1 to computer2.
Though this was more difficult than expected. The following worked:
/usr/local/bin/imapsync --host1 computer1.example.org --user1 MyName --port1
143 --password1 MASKED --tls1 --authmech1
On Tue, 2014-12-16 at 16:58 -0600, Patrick Goetz wrote:
> On 12/16/2014 01:42 PM, Andrew Morgan wrote:
> > I forgot about one additional thing we do - we dump the mailboxes.db to
> > a flat file once an hour via cron. That would allow us to (mostly)
> > recover from a corrupted mailboxes.db file.
On Tue, 16 Dec 2014, Patrick Goetz wrote:
> On 12/16/2014 01:42 PM, Andrew Morgan wrote:
>>
>> I forgot about one additional thing we do - we dump the mailboxes.db to
>> a flat file once an hour via cron. That would allow us to (mostly)
>> recover from a corrupted mailboxes.db file. Just like a
On 12/16/2014 01:42 PM, Andrew Morgan wrote:
>
> I forgot about one additional thing we do - we dump the mailboxes.db to
> a flat file once an hour via cron. That would allow us to (mostly)
> recover from a corrupted mailboxes.db file. Just like a full restore,
> we would need to run a reconstruc
On Wed, Dec 17, 2014, at 06:42 AM, Andrew Morgan wrote:
> I forgot about one additional thing we do - we dump the mailboxes.db to a
> flat file once an hour via cron. That would allow us to (mostly) recover
> from a corrupted mailboxes.db file. Just like a full restore, we would
> need to run
On Tue, 16 Dec 2014, Patrick Goetz wrote:
> On 12/16/2014 4:11 AM, Michael Menge wrote:
>> We also don't use snapshots or stop cyrus for backup.
>>
>> But as a complete restore of our mail storage with normal backuptools
>> would take fare too long, we uses cyrus sync for disaster recovery.
>> For
On 12/16/2014 4:11 AM, Michael Menge wrote:
> We also don't use snapshots or stop cyrus for backup.
>
> But as a complete restore of our mail storage with normal backuptools
> would take fare too long, we uses cyrus sync for disaster recovery.
> For the normal backup we use a combination of delayed
Quoting Andrew Morgan :
On Mon, 15 Dec 2014, Patrick Goetz wrote:
On 12/10/2014 03:47 AM, Willy Offermans wrote:
I'm not sure what you mean with ``all the metadata'', but there are user
flags saved into the cyrdump file as well. I never performed the whole
cycle of dump and re
On Mon, 15 Dec 2014, Patrick Goetz wrote:
> On 12/10/2014 03:47 AM, Willy Offermans wrote:
>> I'm not sure what you mean with ``all the metadata'', but there are user
>> flags saved into the cyrdump file as well. I never performed the whole
>> cycle of dump and
On 12/10/2014 03:47 AM, Willy Offermans wrote:
> I'm not sure what you mean with ``all the metadata'', but there are user
> flags saved into the cyrdump file as well. I never performed the whole
> cycle of dump and restore (probably nobody did so far), so I cannot tell
&g
I'll bite. Since a couple of times I've had to restore mail using
> reconstruct after having lost all the metadata, I'm wondering what the
> point is of either cyrdump or ctl_mboxlist list if you can't restore the
> mail spool from their outputs?
>
> What d
I'm wondering what the
point is of either cyrdump or ctl_mboxlist list if you can't restore the
mail spool from their outputs?
What does cyrdump do, anyway? I would expect it to also backup all the
metadata; else it amounts to tar'ing up ~/cyrus/user.
Cyrus Home Page: http://
On 12/09/2014 09:03 AM, Willy Offermans wrote:
>> Now I want to restore the data of user.$USER on a different server.
>>
>> How should I proceed?
To move a single user to a new server, in the past I've used imapsync to
good effect (http://imapsync.lamiral.info/):
imapsync --host1 my_old_se
t; > > I want to simulate a possible crash of the company's mail server.
> > > At the moment the server works smoothly, but you never know... It is best
> > > to be prepared for it and to have possibilities to restore critical data.
> > > E-mail info was appoint
moment the server works smoothly, but you never know... It is best
> > to be prepared for it and to have possibilities to restore critical data.
> > E-mail info was appointed to be one of the critical data.
> >
> > So I picked one user and cyrdump his data into a file.
>
d for it and to have possibilities to restore critical data.
> E-mail info was appointed to be one of the critical data.
>
> So I picked one user and cyrdump his data into a file.
>
> ``cyrdump -v user.$USER > /tmp/$USER.dump''
>
> If I make a quick scan of the file,
So I picked one user and cyrdump his data into a file.
``cyrdump -v user.$USER > /tmp/$USER.dump''
If I make a quick scan of the file, it looks like a dump of mails of the
user. Moreover, there is flag info per mail subfolder. There is info about
subfolders and there is info abo
Is there a flag for cyrdump (or a corresponding cyrload) that allows you
to reload mailboxes? The man page on cyrdump on my system is rather sparse:
CYRDUMP(8)
NAME
cyrdump - dump mailboxes to stdout
SYNOPSIS
cyrdump [-C ] [-v] [mboxpattern ...]
DESCRIPTION
A
can somebody tell me how I cant get cyrdump to dump me only the inbox ?
I can only dump the complete mailbos with chidren but I want only the
INBOX.
I tried cyrdump user/test/[EMAIL PROTECTED] but that doesn't work
and in the manpage there is no description about it.
I'm using c
Hello,
Is there a way re-inject the mails produced by cyrdump back into Cyrus ?
Cyrdump makes a good job at backing up the mails and I was wondering if
there is a complementary program that could just put them back.
tia,
mitu
On Wed, 25 Jun 2003, Alexandros Vellis wrote:
> My goal is to backup some pretty large mailboxes and then restore them
> to a brand new, clean Cyrus installation, and the cyrdump output seems
> ideal to this, as it has all the useful metadata.
You should just be able to take the mail
Greetings,
Since the documentation on cyrdump is lacking, I'd like to ask if there
is a way to restore the *contents* of a mailbox, as displayed in the
output of cyrdump ("multipart/related"), directly to a mailbox in Cyrus.
My goal is to backup some pretty large mailboxes and th
I was just curious about the status of thse two tools... they look very
useful... I tried compiling the cyrrestore in 2.1.11 but had no luck...
and I see nothing in the archives about these...
Much thanks,
jared
--
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT/S/B d- s-:+ a- C$ UL$
28 matches
Mail list logo
