Imsbackup - imsrestore- mboxutil-reconstruct

i am using iplanet messaging server 5.2 patch 2 on windows 2003 Server. Please help me how can i run the following commands
-imsbackup
- imsrestore
- mboxutil
-reconstruct
from dos prompt. These are very important commands without them i am not able to take backup, maintanance & recovery on windows system.
i found imsbackup.sh and imsrestore.sh files in msg-*/bin directory.
thanx in advance.

Thanx a lot jay for this information. actually i am a
new user of Iplanet in Windows plateform. i found
all utilities (.exe) in these folders
server-root/bin/msg/admin/bin
and
server-root/bin/msg/store/bin Yeah, I no longer have a Windows install of 5.2. I'm all on 6.2, now, and Solaris X86....
>
Can i use iPlanet Console for taking backup of all
messages as i can take backup of directory server
from console itself.No, that functionality has never been part of Console, for Messaging Server. Messaging Server is not a GUI-based application...
>
and is it possible for getting reports of disk quota
usage of all users from console or any web based
utility.
i have used No. Mboxutil will give you such reports, but that's more command-line...
>
quotacheck.exe -i
comand line utility.Yeah, that, too.
Actually, very few people run Messaging Server in production on Windows. Since 6.xx has been released on Solaris X86, most PC-based systems seem to be moving in this direction. Solaris is free, and Messaging works very, very well on Solaris (Linux is also available for 6.xx).
I would not personally try running Messaging 6.2 on Windows, even though it's released. This is our first 6.x release for Windows, and I'd consider it suitable for testing and demonstration. On the other hand, I've been running 6.1 and 6.2 on Solaris for over a year, and am very pleased with the stability.

Similar Messages

Mail Missing From Restore

Hello, We are having some issues with missing mail (mainly in Inbox, Sent and Trash) from a restore process. Several users' mail was inadvertently deleted on the mail server. We figured out who the users were and set about restoring their mail from our Tivoli backups.
A "reconstruct" was done once the restore was complete, and everything appeared consistent. However, users are missing mail in their desktop client (thunderbird). But we can see the mail (message count) on the server.
The problem seems to be that after a mailbox has been restored from tape, the iPlanet reconstruct command does not like the store.idx file and deletes most of the messages.
Is there a piece we're missing? We've restore mail folders for users in the past with no problems of this sort. I don't think we've ever had to restore the full mail for a user.
We're running an old version ... waiting for a migration this spring.
Planet Messaging Server 5.2 HotFix 2.01 (built Aug 26 2004)
libimta.so 5.2 HotFix 2.01 (built 11:07:49, Aug 26 2004)
SunOS inflow 5.9 Generic_122300-42 sun4u sparc SUNW,Sun-Fire-V240
Any ideas would be greatly appreciated.
Thanks!
Karol

kdpittman wrote:
Hello, We are having some issues with missing mail (mainly in Inbox, Sent and Trash) from a restore process. Several users' mail was inadvertently deleted on the mail server. What do you mean by "inadvertently delete"?
Did the users delete the emails using an email client (e.g. Thunderbird or Messenger Express) or did they "magically" disappear due to some kind of system level corruption?
A "reconstruct" was done once the restore was complete, and everything appeared consistent. However, users are missing mail in their desktop client (thunderbird). But we can see the mail (message count) on the server. You cannot restore previously deleted/expunged individual *.msg files back into the original mailbox and expect them to show up. You need to restore the emails into a completely new folder.
For example, you can create a "recovered" folder (./mboxutil -c user/<uid>/recovered) then restore the emails to the directory created by that command.
Running reconstruct of this new folder will then cause the restored emails to show up and the user then just needs to subscribe to the folder in their IMAP client.
If you were using imsbackup/imsrestore this problem wouldn't have occurred as imsrestore marks the emails as "new".
The problem seems to be that after a mailbox has been restored from tape, the iPlanet reconstruct command does not like the store.idx file and deletes most of the messages.If you restore a folder, and the backup was taken after the email had already been marked-as-deleted by the email client then the email will remain "deleted". The *.msg files aren't cleaned up until the daily imexpire run.
Later versions of Messaging Server have an option to "undelete/expunge" messages that have been deleted by the client by not removed off disk.
Regards,
Shane.

How to subscribe users folders

Hi,
I have got a problem trying to subscribe users folders.
Here is my case.
I migrate from Netscape sun messaging server to JES2005Q1.
I transfert mailboxes from the old server to the new one.
I d'like to subscribe all user to their folder, so that they are not affected by migration.
To do so I use
mboxutil -l > mboxlist
I extracted a list of all folders and for each login I created login.sub in each mailbox
Here is an example of store.sub for rbaud user :
user/rbaud
user/rbaud/Exemple
user/rbaud/Sent
user/rbaud/Trash
user/rbaud/r�ponse
user/rbaud/test
Then I reconstruct -r -f and every thing was right except for "r�ponse" folder because of accent.
Some users complain about diseaperance of all folders with accent.
Trying to fix the case I notice that I should have encode folders name like :
r&AOk-ponse
It looks like utf7-imap encoding
So my question is :
Is there a command to subscribe any folder for every users
Or how can I translate "r�ponse" in "r&AOk-ponse"
I hope my explanation was clear enough.
Thanks for your help.

You 're right, my users used the "subscribe" function
in their mail clients, for folders with accent.
But I will have to do other migrations and I was
asked to find a solution so that users need not to
subscribe their folders after migration.
I used "rsync" to download
old_server/.../primary/=user/* in new
server/.../primary/=user/Right. You missed the mboxlist directory. You should include that in your migration. Subscriptions and such are stored there.
Simply moving the partitions over isn't sufficient. You can recover much of the data with
reconstruct -m
reconstruct -r
but that doesn't get it all. Moving the mboxlist database is important....
>
There is no store.sub in their mailboxes. So I tried
to build them, before creating databases with
reconstruct -r -f
relinker
start-msgOk, that's not quite the correct process.
First, the store process MUST be running whenever you do any reconstruct.
Second, you needed to run reconstruct -m FIRST, before the reconstruct -r, as the database had no entries for any folders.
>
You said "When I did this same migration, all my
subscriptions came along with the mail", but how did
you do without store.sub in mailboxes ? Easily.
There are SUPPORTED methods, unlike the one you chose.
imsbackup/imsrestore is the route I elected to take. That gets everything.
MoveUser is another route that works well. Again, it gets everytihngs.
If you had taken the database, too, you likely would have had no problem.
If you had run reconstruct -m first, likely you would have had no problem.
>
Thanks Jay.

Migration to JES4 Best Practices

We are migrating users from our iMS52hf2.12 systems to our new JES4 systems with T118207-52 imstalled.
We are looking at putting the account on hold,copying the mailbox updating LDAP attributes (store and partition).
What are the commands and sequence to the migrated mailboxes to properly set them up in the new store. Right now we have:
reconstruct -p primary -u uid -m
reconstruct -f -r user/uid
Should we have an mboxutil -c first?

If you're using imsbackup/imsrestore, you won't need to do any reconstruct or mboxutil at all. Please consider this route.
If you're doing straight filesystem backup, then:
reconstruct -m will create all the folders. If you use mboxutil -c for all folders, you do not need to reconstruct -m.
reconstruct -r user/userid/INBOX is needed after.

Messaging server 7 duplicate folders

Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)
libimta.so 7.3-11.01 64bit (built 19:54:45, Sep 1 2009)
Using /opt/sun/comms/messaging64/config/imta.cnf (compiled)
SunOS 5.10 Generic_142900-03 sun4v sparc SUNW,SPARC-Enterprise-T5120
After installling messaging server 7 and restoring data (imsrestore), webmail client shows me a draft folder and a Borradores (spanish) folder.
The messenger express client shows both as "Borradores" and just one keeps old messages, but new ones are save in the other one.
The same issue for Sent (Enviados) and Trash (Basura).
Not all users present this problem, and have not found the characteristic that makes the diference.
The ldap entry atributes (related with folder configuration) for a right user (no duplicate folders) is like this:
nswmExtendedUserPrefs: meDraftFolder=Drafts
nswmExtendedUserPrefs: meSentFolder=Sent
nswmExtendedUserPrefs: meTrashFolder=Trash
nswmExtendedUserPrefs: meInitialized=true
And for a wrong user:
nswmExtendedUserPrefs: meSentFolder=Enviado
nswmExtendedUserPrefs: meInitialized=true
nswmExtendedUserPrefs: meDateFormat=0/
nswmExtendedUserPrefs: meColorSet=5
nswmExtendedUserPrefs: mePrevTrash=Papelera
nswmExtendedUserPrefs: meExpungeOnExit=true
nswmExtendedUserPrefs: meViewSize=100
nswmExtendedUserPrefs: meAutoSpell=true
nswmExtendedUserPrefs: meDraftFolder=Drafts
I have tryied changing nswmExtendedUserPrefs attribute from "meSentFolder=Borradores" to "meSentFolder=Draft" without success.
I am not sure where is the problem, messaging configuration or it is a ldap issue.
Any idea will be apreciated, thanks.

adding to what Shane said...
doing this via IMAP is the best bet. If you are moving messages between folders in the same account, you can do that via IMAP and the Message Store will end up doing it all via hard links in the file system rather than actually copying the data. So it should be nice and fast and low impact on your disk space and system. In IMAP, "move" consists of COPY to the destination folder and then flagging the originals as deleted and doing expunge. That will update store.* files and create hard links for the messages in the destination folders, but not copy the message data. You will not need to do any reconstructs.
imsbackup/imsrestore could do it, but will end up copying the data - unless you enable real time relinker - so this method is more load on the system.
And manually moving the files around in the store would require reconstruct and is generally not as good an idea as doing it via IMAP. If you have only a few folders to do this to, then you could do the IMAP commands by hand as easily as you could hack on the store files directly.

Can I copy store folder to use in another machine

I have installed new directory server on new machine and already add all users. Then I install messging server 6.0 on new machine. I want to migrate mail box to new server, can I copy store folder on old messaging server (6.0) to use on new server.

You can do an imsbackup/imsrestore. This will take care of everything. It's how I migrated from 5.1 to 5.2 on a new machine.
You could also try using tar and then running a reconstruct -m. In theory, that should work. But I haven't tested it.
HTH,
Roger S.

Restore emails

I tried to restore user's emails but failed to keep the emails already in the inbox. The users are recreated and they have been using the email for several days so there are some emails in their mail boxes. When I restored the old emails from tar file, only old emails I restored listed in the indox.
Here is how I restored the emails:
tar user's old mail fold on old server
cd /primary/=user/72/47/=436209793504641
tar cvf /home/436209793504641.tar .mv 436209793504641.tar to new server
untar user's old mail fold to user's new fold on new server
cd /secondary/=user/72/47/=436209793504641
tar xvf /home/436209793504641.tar
/mail/sbin/reconstruct -p secondary -u 436209793504641 -mThe server version is:
imsimta version
Sun Java(tm) System Messaging Server 6.2-3.04 (built Jul 15 2005)
libimta.so 6.2-3.04 (built 01:43:03, Jul 15 2005)
SunOS mimas 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-V890
Thanks,
Ben

bwang wrote:
I tried to restore user's emails but failed to keep the emails already in the inbox. The users are recreated and they have been using the email for several days so there are some emails in their mail boxes. When I restored the old emails from tar file, only old emails I restored listed in the indox.You should be using imsbackup/imsrestore instead of "tar". The imsrestore command will not overwrite existing messages and will keep email flags (read/deleted/flagged etc.)
imsimta version
Sun Java(tm) System Messaging Server 6.2-3.04 (built Jul 15 2005)
libimta.so 6.2-3.04 (built 01:43:03, Jul 15 2005)
SunOS mimas 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-V890This is a very old version of Messaging Server -- you should be patching to a minimum of 118207-63
Regards,
Shane.

Best Approach for a partial domain migration?

The company is splitting and needs to migrate about half of their users from a.com to b.com. Current users are in a 6.3 environment and we are building a completely independent new environment for the migrated users using the latest messaging 7x release.
My plan is to create both domains for a.com and b.com in the new environment.
Use imsbackup / imsrestore to migrate the users to a.com in the new environment.
Use MoveUser to migrate the users in the new environment from a.com to b.com.
Delete domain a.com from new environment
Add mailrouting to the a.com entries of the migrated users in the old environment.
Does this sound like a sane approach?
-Ray

Ray_Cormier wrote:
The company is splitting and needs to migrate about half of their users from a.com to b.com. Current users are in a 6.3 environment and we are building a completely independent new environment for the migrated users using the latest messaging 7x release.
My plan is to create both domains for a.com and b.com in the new environment.I wouldn't. The new environment should have no knowledge about a.com except for perhaps a custom MTA rewrite rule/channel so you can direct all a.com bound email to the a.com MTA directly.
The question you need to address is how are users going to deal with the change given that client-side setting will need to change.
Use imsbackup / imsrestore to migrate the users to a.com in the new environment.Is a.com a "hosted" domain or the "default" domain in Messaging Server i.e. are the store accounts in "user/uid/mailbox" or "user/[email protected]/mailbox" format:
-bash-3.00# ./mboxutil -lp user/shjorth/INBOX
msgs Kbytes last msg partition quotaroot mailbox
30 3087 2010/05/17 15:50 primary 9766 user/shjorth/INBOX
Use MoveUser to migrate the users in the new environment from a.com to b.com.MoveUser also migrates the email and using this tool with non-replicated directories is tricky.
Does this sound like a sane approach?Another approach is:
=> Create brand new accounts in the new system for all the to-be-migrated b.com users.
=> At a specific date, advise the user that they are going to be migrated along with instructions on how to change client settings to access the new system and what their new email address is going to be. The old email address will be forwarded for X time.
=> Script the migration of the users LDAP settings e.g. sieve rules, address-book entries, email signatures, password then redirect email for [email protected] to [email protected] on the a.com system (mailroutingaddress: [email protected])
=> Disable client access on the a.com system (e.g. mailallowedserviceaccess: -ALL:ALL) for the user to stop them accessing their old account.
=> Use imsbackup -> imsrestore on the a.com -> b.com system to migrate the old email.
=> At some point down the track remove the users old email from a.com system once you are happy the migration has succeeded and also remove the users LDAP entry (to stop forwarding of the old a.com email address).
The advantage of this approach is that you can migrate users one-at-a-time (starting with the more technical users to iron out any bugs) and test the migration yourself to ensure you have everything working. You may also want to use this as an opportunity to switch to Convergence for the webmail client (assuming you are using Messenger Express or UWC/CE now).
Regards,
Shane.

How to migrate from a standard store setup in a splitted store (msg - idx) setup

How can I migrate from a standard store setup in a splitted setup described in
https://wikis.oracle.com/display/CommSuite/Best+Practices+for+Messaging+Server+and+ZFS
can a 'reconstruct' run do the migration or have I do a
imsbackup - imsrestore ?

If your new setup would use the same filesystem layout as the old one (i.e. directory paths to the files would be the same when your migration is complete) you can just copy the existing store into the new structure, rename the old store directory into some other name, and mount the new hierarchy instead of it (zfs set mountpoint=...). The CommSuite Wiki also includes pages on more complex migrations, such as splitting the user populace into several stores (on different storage) and/or separate mailhosts. That generally requires that you lock the user in LDAP (perhaps deferring his incoming mail for later processing into the new location), migrate his mailbox, rewrite the pointers from LDAP, reenable account. The devil is in the details, for both methods. For the latter, see Wiki; for the former I'll elaborate a bit here
1) To avoid any surprises, you should stop the messaging services before making the filesystem switch, finalize the data migration (probably with prepared data already mostly correct in the new hierarchy before you shut down the server, just resync'ing the recent changes into new structure), make the switch and reenable the server. If this is a lightly-used server which can tolerate some downtime - good for you If it is a production server, you should schedule some time when it is not very used so you can shut it down, and try to be fast - so perhaps practice on a test system or a clone first.
I'd strongly recommend taking this adventure in small reversible steps, using snapshots and backups, and renaming old files and directories instead of removing them - until you're sure it all works, at least.
2) If your current setup already includes a message store on ZFS, and it is large enough for size to be a problem, you can save some time and space by tricks that lead to direct re-use of existing files as if they are the dataset with a prepopulated message store.
* If this is a single dataset with lots of irrelevant data (i.e. one dataset for the messaging local zone root with everything in it, from OS to mailboxes) you can try zfs-cloning a snapshot of the existing filesystem and moving the message files to that clone's root (eradicating all irrelevant directories and files on the clone). Likewise, you'd remove the mailbox files on the original system (when the time is right, and after sync-ing).
* If this is already a dedicated store dataset which contains the directories like dbdata/ mboxlist/ partition/ session/ and which you want to split further to store just some files (indices, databases) separately, you might find it easier to just make new filesystem datasets with proper recordsizes and relocate these files there, and move the partition/primary to the remaining dataset's root, as above. In our setups, the other directories only take up a few megabytes and are not worth the hassle of cloning - which you can also do for larger setups (i.e. make 4 clones and make different data at each one's root). Either way, when you're done, you can and should make sure that these datasets can mount properly into the hierarchy, yielding the pathnames you need.
3) You might also look into separating the various log-file directories into datasets, perhaps with gzip-9 compression. In fact, to reduce needed IOPS and disk space at expense of available CPU-time, you might use lightweight compression (lzjb) on all messaging data, and gzip on WORM data sets - local zone, but not global OS, roots; logs; etc. Structured databases might better be left without compression, especially if you use reduced record sizes - they might just not compress enough to make a difference, just burning CPU cycles. Though you could look into "zle" compression which would eliminate strings of null bytes only - there's lots of these in fresh database files.
4) If you need to recompress the data as suggested in point (3), or if you migrate from some other storage to ZFS, rsync may be your friend (at least, if your systems don't rely on ZFS/NFSv4 ACLs - in that case you're limited to Solaris tar or cpio, or perhaps to very recent rsync versions which claim ACL support). Namely, I'd suggest "rsync -acvPHK --delete-after $SRC/ $DST/" with maybe some more flags added for your needs. This would retain the hardlink structure which Messaging server uses a lot, and with "-c" it verifies file contents to make sure you've copied everything over (i.e. if a file changes without touching the timestamp).
Also, if you were busy preparing the new data hierarchy with a running server, you'd need to rsync old data to new while the services are down. Note that reading and comparing the two structures can take considerable time - translating to downtime for the services.
Note that if you migrate from ZFS to ZFS (splitting as described in (2)), you might benefit from "zfs diff" if your ZFS version supports it - this *should* report all ofjects that changes since the named snapshot, and you can try to parse and feed this to rsync or some other migration tool.
Hope this helps and you don't nuke your system,
//Jim Klimov

Migrating Mailboxes from ims5.2 to 6.2

Hello again,
Our test/migration 6.2 system is at the following:
Sun Java(tm) System Messaging Server 6.2-3.04 (built Jul 15 2005)
libimta.so 6.2-3.04 (built 01:43:03, Jul 15 2005)
Testing an in-place migration. Have done a small test using imsbackup/imsrestore
with just a few users on a different box. Went through the upgrade scripts, restored
the users, and that worked okay.
My testing now is different. We cloned one of our 300G mail partitions from the
current 5.2 production system. It contains close to 5000 accts and is about 95G of actual
data. I attached and mounted the clone on our test system and can see the 5.2 mail data.
Went through the upgrade scripts (mta, configutil, mboxlistdb). I had previously copied
the 5.2 mbox/config information to the 6.2 system and used as input.
The scripts ran with no problems. The problem I am having is that once I start up 'stored'
so I can check the database, the *.db files aren't what they used to be - looks like the
originals moved to a directory called 'removed'. Now, it's like a brand new db.
The upgrade changes introduced several partitions, of which only two would actually be
there (the primary & the one 300G clone). I am wondering if stored didn't like something
about the physical store and re-initialized.
At this point, I went ahead and ran 'reconstruct -m', which ran really fast for the 95G
of actual data that was there, so that's encouraging. The mailbox db looks good.
Would like to know why the db info would disappear. Is there a startup log that
may provide insight to this? Would like to know what I did wrong.
Thanks for your input.
Keith

kmrnm10 wrote:
Sun Java(tm) System Messaging Server 6.2-3.04 (built Jul 15 2005)
libimta.so 6.2-3.04 (built 01:43:03, Jul 15 2005)You should be patching up to the latest 6.2 (118207-63) prior to attempting the migration - there were a few bugs fixed with the UpgradeMsg5toMsg6.pl migration script with the later patch.
Also you may want to consider going straight to 6.3 (once again make sure you use the latest patch-level).
http://www.sun.com/bigadmin/hubs/comms/files/ms52-ms6-upgrade.html
The scripts ran with no problems. The problem I am having is that once I start up 'stored'
so I can check the database, the *.db files aren't what they used to be - looks like the
originals moved to a directory called 'removed'. Now, it's like a brand new db.Did you copy the entire store mailbox directory or just the *.db files?
The upgrade changes introduced several partitions, of which only two would actually be
there (the primary & the one 300G clone). Not quite sure what you mean by this. What were the actual changes?
I am wondering if stored didn't like something
about the physical store and re-initialized.Entirely possible. Review the default log file (/opt/SUNWmsgsr/log/default).
At this point, I went ahead and ran 'reconstruct -m', which ran really fast for the 95G
of actual data that was there, so that's encouraging. The mailbox db looks good.Worst case scenario you can use this method. Although this method won't give you the same results as the on-disk copies of the data (store.* files) aren't necessarily 100% up-to-date so users may notice some read/deleted email comes back.
Would like to know why the db info would disappear. Is there a startup log that
may provide insight to this? Would like to know what I did wrong.default log file as mentioned previously.
Regards,
Shane.

Modify user idI

is it possible to modify a user's id with commadmin - or any other method?

You're asking, "can I change a users UID"?
If all you're talking about is Messaging, and you're talking about current product, then mboxutil should be able to do that for you, but......
If you're also talking about Calendar, then trying to change a UID is a "Really, Truly Bad Idea".
There are many things in both Messaging and Calendar that are tracked by UID, and making such a change rarely gets everything. You typically end up with a real mess.
You can change the DN, mail address, and everything else, easily. I would consider UID to be something that should NEVER be changed.
Better to create a new UID, use MoveUser or imsbackup/imsrestore to move the messages over, and then delete the old UID. Of course, that won't move the PAB, and you still need to export Calendar entries, and import to the new user, and all that stuff......

Shared folder problem

Dear All,
We are upgrading iPlanet Messaging Server 5.2 to Sun Java(tm) System Messaging Server 7.0-5.01. And use imsexport and imsimport to move users' data. However, the relationship of shared folders on old system does not move to the new one. Is there any way to fix this problem?
Best Regards,
Steve

SteveHibox wrote:
We are upgrading iPlanet Messaging Server 5.2 to Sun Java(tm) System Messaging Server 7.0-5.01. And use imsexport and imsimport to move users' data. However, the relationship of shared folders on old system does not move to the new one.Why are you using imsexport/imsimport vs. imsbackup/imsrestore?
With regards to shared folders, there are two parts to this. The first part is the folder ACL information (i.e. who is allowed to access a folder) and then there is the subscription information (i.e. who is trying to access the folder).
The subscription information is not kept by imsbackup/imsrestore (bug #6753646 - "subscriptions list are not kept when imsbackup/imsrestore").
Using imsbackup/imsrestore "should" keep the ACL information. I say "should" because you are using a very old version of Messaging Server (5.2).
For the subscription side of the equation, the end-user would need to re-subscribe to the shared folders.
Regards,
Shane.

Speeding up migration of mailbox data

I am getting ready to perform a migration of mailbox data from an iMS 5.2 HotFix 1.21 system to a SJS 7u2-7.02 64bit system by using imbackup on the old system and piping through rsh and imsrestore on the new system. I'm trying to get the best performance out of this. I have set noatime on all mailstore partitions and I am using a 128 blocksize but it seems pretty slow to me. The total amount of data I am transferring is ~276GB. The old system has 4 mailstore partition and the new one has a single partition. I am using backup groups as follows:
groupa=a*
groupb=b*
groupc=c*
etc..
My plan was to run multiple iterations of the imsbackup/imsrestore at once. In my tests while multiple iterations are running (I've tried 4 so far) I don't see much CPU utilization. RAM usage is fine and there is very little %wio. I'm getting less than 20GB transferred per hour. I would expect to see more and I don't see many resources being used on either system. During my tests I only have the watcher and store daemons running.
Does anyone have any tips on increasing the performance of this type of migration other than what I am already doing?

sheger77 wrote:
I am getting ready to perform a migration of mailbox data from an iMS 5.2 HotFix 1.21 system to a SJS 7u2-7.02 64bit system by using imbackup on the old system and piping through rsh and imsrestore on the new system. I'm trying to get the best performance out of this. I have set noatime on all mailstore partitions and I am using a 128 blocksize but it seems pretty slow to me.Have you set "store.dbtmpdir" to a memory mapped file-system on both the iMS5.2 and MS7u2 systems?
You should also upgrade your MS5.2 system to the latest hotfix (iMS5.2hf2.18) to address two backup related bugs:
bug #6525771 - "imsbackup does not backup acl"
bug #6202176 - "imsbackup does not backup user defined flags (keywords)"
MS7u3 will have a fix for RFE# 6669661 - "imsrestore should cache peruser flag updates" which should help to improve restore performance by reducing DB updates. You may want to wait a month or so for this release to become available.
My plan was to run multiple iterations of the imsbackup/imsrestore at once. In my tests while multiple iterations are running (I've tried 4 so far) I don't see much CPU utilization. RAM usage is fine and there is very little %wio.Do you see much in the way of %b (block on I/O - use "iostat -x"), for example when using the same procedure on my own test systems (iMS5.2 backup => rsh pipe => MS7u2 restore) I see the following:
extended device statistics
device r/s w/s kr/s kw/s wait actv svc_t %w %b
cmdk0 0.7 164.3 22.1 10519.6 0.0 0.9 5.5 0 89
cmdk1 0.0 9.9 0.0 810.0 3.8 0.5 434.5 24 25
The bottleneck in this case is "cmdk0" (a virtual disk).
I'm getting less than 20GB transferred per hour. I would expect to see more and I don't see many resources being used on either system. During my tests I only have the watcher and store daemons running.Try also starting the "ens" daemon (./start-msg ens)
Does anyone have any tips on increasing the performance of this type of migration other than what I am already doing?The main bottleneck for this procedure is I/O. If you are performing multiple simultaneous restores make sure they are destined for different LUN's (disks) so you can spread the I/O load as much as possible.
Regards,
Shane.

Comms 6 upgrade help

Greetings all,
I'm needing some advice on how I should proceed with an Upgrade of Comm's.
We currently have a small setup with a backend cluster and a couple front ends running the multiplexor. Everything Comms 5
Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)
libimta.so 6.3-8.03 (built 18:51:22, Apr 24 2009; 32bit)We just acquired new hardware and are ready to upgrade the System to Comm Suite 6, with convergence, etc...
My question is this, what would be best to do with a completely new system?
Some considerations.
1. All new hardware for each component, no need for using older hardware, new DS, BE, FE, WEB, etc...
2. Have to be able migrate a few users at a time without disrupting the current service.
3. *This isn't a must have, but I'd like for users of the current system and the new system to be able to access they're mail, during the migration through the same addresses they use now, essentially, being able to front end both the new and old systems with the same boxes.
Should I replicate the new directory servers with the old (current) DS servers and essentially build onto the existing sytem, and if I do that, can I effectively replace the current front ends with Coms Suite 6 and they still connect to the Comms Suite 5 Back ends, at least until everyone has been moved?
OR
Should I built a completely seperate system, LDAP and all, and move users and mail from the old to new? I don't think I can even do this (migrate mail), at least easily, and I highly doubt there would be any way front end both systems with a single entry point very easily.
I'm leaning more towards the first option, but I'm not 100%.
Any gotchas or insight would be much appreciated as well.
Thanks in advance.

jeremycrussell wrote:
We currently have a small setup with a backend cluster and a couple front ends running the multiplexor. Everything Comms 5Are you providing just mail services or mail, calendar and/or instant messaging?
Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)
libimta.so 6.3-8.03 (built 18:51:22, Apr 24 2009; 32bit)We just acquired new hardware and are ready to upgrade the System to Comm Suite 6, with convergence, etc...
My question is this, what would be best to do with a completely new system?Do you have new systems for both the front-end and back-end systems?
One approach would be to build up new comm-suite-6u2 (or 7, which is coming out in a month or so) front-ends (MMP, Convergence, mshttpd, UWC/CE, MTA) with the same host-name but a different IP address etc. to the old-front-end then switch the IP addresses during an small outage window.
The users should see no difference as they will continue to use UWC/CE. Get a few test users to then try out Convergence (different URL) and once you are happy "announce" the availability to everybody else.
The back-end systems can be migrated transparently one-user at a time using imsbackup/imsrestore and setting the mailhost/mailuserstatus appropriately.
Regards,
Shane.

Start-msg: could not get server configuration in ldap

Hello,
I am trying to get iPlanet Messaging Server 5.2 Patch 1 running, but when I run start-msg
I get the following error message:
General Warning: could not get server configuration in ldap, using cached configuration information
Note: I created this system using a ufsdump and ufsrestore combination on the instance directory.
Other file systems were not copied over.
My guess is that something else may be missing?
I ran ns-slapd first before starting the messaging server.
Thanks in advance.
Tim

Thanks for the response. I have some followup
questions:
> I have done this with Messaging Server.
Several
things to do:
1. Go into Console, and change it there. Youneed
to change hostname and ip for admin server,Directory
server, and messaging server.
When I bring up the console, it asks for a user nameThe default user's name is "admin". The password was assigned during installation. You can also use, "cn=Mirectory Manager", but again, the password was assigned on install.
>
and password. Well, the admin quit and left no
documentation, so I don't have any idea on what to
use. Any ideas?
>
2. Edit your mappings file, to reflect the new ip
address.
Where is this mappings file?<install directory>/msg-<name of your server>/imta/config
>
> 3. Change the setting for "mailhost" for every
user
to reflect the new hostname. If you don't dothis,
nobody will get any mail.>
I interpret this to mean:
(1) use db2ldif and then use and editor to do a
global
search and replace on the mail hostname.yes
>
> It may turn out to be easier to "migrate" your
data,
rather than "fix" by changing hostname/ip.
to migrate:
install new application on new box, with correct
hostname/ip
Unfortunately, I tried this and did not have much
success. I gave up and went with
ufsdump/ufsrestore.That's very much the hard way. . .
>
> Use MoveUser to migrate users and mailboxes from
old
to new, or
Use imsbackup/imsrestore to move the mailboxes.
Export the data from ldap in ldif format, then usea
a text editor to change the mailhost value for all
the users, and then import that new data to thenew
directory server
I think I will have to do this anyways, right.
Assuming my new box is offline for a while and
users are still using the old box.You can certainly use imsbackup/imsrestore to move all new mails. . .

Imsbackup - imsrestore- mboxutil-reconstruct

Similar Messages

Maybe you are looking for