Did anyone encounter this kind of problem?
C150 was accidentally powered off ( power cable was unplugged accidentally).
The result was, the database was corrupted.
I was wondering if this was addressed on the latest version of asyncos 6.0
Im running asyncos 5.5
Your corruption is normal following a improper reboot of the appliance. At this time there is no mechanism in place to correct the databases in the event of a situation such as this.
kira_yamato, you will be unable to recover the data, so it is always important to use the reports daily, weekly and monthly. But you can repair and reopen the bank with the steps below:
Choose the operation you want to perform:
-- RAID - Verify Disk Utility.
-- DISK_USAGE - Check Disk Usage.
-- NETWORK - Network Utilities.
-- REPORTING - Reporting Utilities.
-- TRACKING - Tracking Utilities.
The reporting system is currently enabled.
Choose the operation you want to perform:
-- DELETEDB - Reinitialize the reporting database.
-- DISABLE - Disable the reporting system.
Thank you..but what happened to the reports that were generated before it got corrupted..theyre gone? no other way i can retrieve them?
I am new in ironport.
I would like to know how to check ironport had accepted the email or not?
What will happen if ironport had accepted the email before the power failure? or What will happen if ironport had not accepted the email before the power failure? or What will happen if ironport had accepted the email after the power failure and power up the ironport again?
The IronPort should never lose a mail message during a power outage.
Once the system has accepted the message it's written to disk, which obviously will survive the power outage, and the system will deliver it when the power returns.
If the message was part-way through being delivered to the IronPort when the outage occurs then it becomes the responsibility of the sending system to retry the message. As the IronPort will not have acknowledged the message the remote system will know that it has to re-send, and will either send it to another MX or wait until the IronPort is available again.
This is a fundamental part of the SMTP protocol, and the IronPort will do everything that it can to avoid messages ever being lost.
It probably bears mentioning here that a good UPS and cable routing/labeling strategy should not be overlooked.
It's amazing what a $0.25 wire tie and a Brother P-Touch labeler can do for you. :)
If your rack kit includes cable management arms use them. :) I've found so many people just setting them aside and not using them. If installed properly, there are only two ways you can un-plug the power cable.
Otherwise I try to loop the power cable around and zip-tie it to the appliance/server so that there will be some inward pressure that will resist a tug or pull on the opposite end of the power cable.
I also label the far end of the power cable with the server/appliance name so if someone is removing a server, they know which cable to unplug or more importantly NOT unplug.
Some SMBs/SMEs do not invest in UPSs and it's a shame. A simple $45 500W can be enough to protect a more valuable investment. However a proper server grade UPS is always preferred, especially one that can be monitored remotely to alert you of power outages so that you may properly shutdown your servers / appliances.
For info, we suffered a corrupt reporting database after a clean shutdown on one of our X1050s (6.1.0-304). This went unnoticed at first (we don't us the on-box reporting tools) but within 18 hours the SMTP listner became really unresponsive and the GUI almost ground to a halt. Deleting the database fixed the problem.
We also had a database corruption problem using 5.5.1-011 and the gui and cli became so unresponsive it prevented us from commiting any changes. Due to the reporting and the reporting queue corruption it was backing up all the changes on the box. Email in/out was not affected though. The only solution given for this problem was to delete the database.
We also had a box reboot by itself. We were told this was caused by Defect #39930 which is related to freebsd and sysctl interaction. AsyncOS queries sysctl for status values, and that polling can result in a lockup.
I guess you really don't need a power failure for a box to go down.