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
Folks,
Following Willy Offermans' recent response to this thread, I've decided
to jump in, but wish to quote a bit more of Patrick's original message
(below), hence the out-of-sequence reply.
I'd like to address Patrick's issues in pretty much the order they're
presented here. Firstly, howev
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 restore (probably
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 restore (probably nobody did so far)
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
> you that all metadata is av
Hello Patrick and Cyrus friends,
On Tue, Dec 09, 2014 at 02:27:09PM -0600, Patrick Goetz wrote:
> On 12/09/2014 09:36 AM, Bron Gondwana wrote:
> >> Is there nobody with a good suggestion?
> >
> > Not really. Most people seem to be using LVM snapshots.
>
> OK, I'll bite. Since a couple of times
On 12/09/2014 09:36 AM, Bron Gondwana wrote:
>> Is there nobody with a good suggestion?
>
> Not really. Most people seem to be using LVM snapshots.
OK, 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
poin
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
Am Mittwoch, den 10.12.2014, 02:36 +1100 schrieb Bron Gondwana:
> On Wed, Dec 10, 2014, at 02:03 AM, Willy Offermans wrote:
> > Hello Cyrus Friends,
> >
> > On Sun, Dec 07, 2014 at 01:01:52PM +0100, Willy Offermans wrote:
> > > Dear Cyrus friends,
> > >
> > > I want to simulate a possible crash o
On Wed, Dec 10, 2014, at 02:03 AM, Willy Offermans wrote:
> Hello Cyrus Friends,
>
> On Sun, Dec 07, 2014 at 01:01:52PM +0100, Willy Offermans wrote:
> > Dear Cyrus friends,
> >
> > I want to simulate a possible crash of the company's mail server.
> > At the moment the server works smoothly, but
Hello Cyrus Friends,
On Sun, Dec 07, 2014 at 01:01:52PM +0100, Willy Offermans wrote:
> Dear Cyrus friends,
>
> 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 possibi
Dear Cyrus friends,
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 appointed to be one of the critical data.
So I
22 matches
Mail list logo