Results 1 to 4 of 4

Thread: [SOLVED] Alter location of user messages

  1. #1
    Join Date
    Apr 2009
    Rep Power

    Default [SOLVED] Alter location of user messages


    I'd like to know how i can change the location of my messages...
    The default location is /opt/zimbra/store and /opt/zimbra/index and yet the mysql data, is correct?
    Then i want change to other partition of my hard disk...
    Any ideas?

  2. #2
    Join Date
    May 2006
    Rep Power


    There's you admin console > server > volumes tab, make sure you have permission to write to the target location. CLI zmvolume - Zimbra :: Wiki
    Helpful commands:
    zmvolume -l
    zmvolume -dc
    mysql> select * from zimbra.volume;
    Solution1: Same Contents
    If you want new store2 to hold the contents of the old store in entirely as well - just move the blobs with zimbra stopped first.
    Then point the message1 path at /mount/store2.(Don't forget to check file permissions after the move.)
    Solution2: Old as subdirectory of new
    If you've already created store2 and been using both for a while, just make the old store1 a subdirectory of the new store2 on the new storage device:
    /mount/store/oldstore1 (previously /opt/zimbra/store - change the path in zmvolume)

    Solution2: Another method that can be used is updating the DB itself.

    There's a volume_id column in the mail_item table in every mboxgroup database - after moving the blobs themselves you could run something like: mysql> for (N = 1 through 100) {UPDATE mboxgroupN.mail_item SET volume_id = IDofNew WHERE volume_id = IDofOld;}

    The first N is talking about the mailbox group (id divided by 100) for which there's 100max groups. Account mailbox database structure - Zimbra :: Wiki


    Of course using LVM to expand /opt/zimbra, /opt/zimbra/store, or /opt/zimbra/index is another easy route - if you've deployed LVM.

    If you wanted to poke around, some basic structure:
    su - zimbra
    show databases;
    use mboxgroupN
    show tables;
    select * from mail_item where volume_id=1; (would get you all the items in volume 1)
    That's a BIG query btw! So probably better if you selected by mailbox_id or id - narrow this down and try stuff on a test account or individual msg - better yet a test harness machine before you run any update/set/alter commands across every account on your production system.

    CLI zmvolume - Zimbra :: Wiki
    zmvolume -l
    zmvolume -dc
    mysql> select * from zimbra.volume;

    MySQL commands: Technical Reference Site

    Solution4: Use HSM to move the blobs after x time from store1 > store2.


    re you saying LVM to size volume groups/pools by absorbing new physical disks/volumes to present to the system as one instance?

    As far as Zimbra is concerned:
    -Using LVM to expand /opt/zimbra, /opt/zimbra/store, or /opt/zimbra/index you don't have to do anything else.

    -Haven't implemented LVM etc? Don't worry, you can still create 'expanding mail storage' even if not presented to the system as one big unit. If your creating an /opt/zimbra/store2, /mnt/device/zimbra/store2, or /mnt/device/zimbra/index2 that's separate - in order to get Zimbra to start putting blobs there you need to point the current message/index or volume there.

    Just realize blobs are NOT moved in this process, you're only pointing at the location to store any NEW data. (See below explanation.)

    Thus you shouldn't remove the old store, but alternatively if you want new store2 to hold the contents of the old store as well - just move the blobs first as in 1A.

    Note: Each Zimbra mailbox server is configured with one current index & message (NE can add secondary HSM volumes).

    Good links:

    Further Explanation:
    Each Zimbra mailbox server is configured with one current index & message (NE can add secondary HSM volumes).

    When a new message is delivered or created, the message is saved in the current message volume. Additional message volumes can be created, but only one is configured as the current volume where new messages are stored. When the volume is full, you can configure a new current message volume. The current message volume receives all new messages. New messages are never stored in the previous volume. A current volume cannot be deleted. If there are accounts with messages referencing a volume it should not be deleted until you point the volume path to wherever you've now moved the items.

    Each mailbox is assigned to a permanent index directory on the current index volume. When an account is created, the current index volume is automatically defined for the account. You cannot change which index volume the account is assigned. As volumes become full, you can create a new current index volume for new accounts. When a new index volume is added as current, the older index volume is no longer assigned new accounts. Index volumes not marked current are still actively in use as the index volumes for accounts assigned to them. Any index volume that is referenced by a mailbox as it's index volume cannot be deleted.

    The Network Edition has HSM (Hierarchical Storage Management) which involves moving data to other storage locations automatically after x amount of time. Messages and attachments are moved from a primary volume to the current secondary volume based on the age of the message; completely transparent to the user.

    For instance: After 30 days messages move from your fast (and usually more expensive) SCSI disks, to a SATA array so that you can keep storage costs down. (But you could also use this concept to move between volumes.)

    For the future:
    Bug 35142 - volume migration tool
    Bug 23472 - Ability to move/consolidate messages from one message store to another.
    Bug 18850 - multiple "current" primary, secondary, index zmvolumes
    Bug 18720 - Add support for more than one current secondary storage volume in HSM
    Bug 32719 - Add ability for admins to configure what blobs get migrated with HSM

    If your merging two systems it may be better to use zmmailboxmove so you don't cross user 'folders' ie on the filesystem will go into the 'current'/ you don't want to share user level dirs. To solve this we really should append a zimbraId string to each users blob folder path (after the 100 group number), or even make it entirely like we do for backups.
    Last edited by mmorse; 04-28-2010 at 01:47 PM.

  3. #3
    Join Date
    Apr 2009
    Rep Power

    Default Alter location of user messages

    Thanks, works fine...

  4. #4
    Join Date
    Feb 2008
    Rep Power


    I want to do this to consolidate both multiple mailstores and multiple indexes. I have figured out how to do Solution2 with mysql db updates, but was wondering if it is possible to do something similar to move indexes into a single instance?

    You mentioned that "You cannot change which index volume the account is assigned.", does you can't easily change it, or there is no way to change it without backing up and recreating the account?


Similar Threads

  1. [SOLVED] Re-creating the spam training e-mail account
    By richard-hdd in forum Administrators
    Replies: 21
    Last Post: 03-20-2012, 07:34 AM
  2. Replies: 21
    Last Post: 02-04-2010, 09:06 AM
  3. [SOLVED] Zimbra logwatch.
    By nishith in forum Administrators
    Replies: 5
    Last Post: 06-10-2009, 04:42 PM
  4. Post instsallation problems
    By Assaf in forum Installation
    Replies: 14
    Last Post: 01-29-2007, 10:38 AM
  5. Services stopped working
    By lilwong in forum Administrators
    Replies: 4
    Last Post: 08-15-2006, 09:19 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts