Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

18.5.2 MR2-Build380 ERROR(0x03): Failed to migrate reportdb. Disabling On-box reporting.

Upgrading my Sophos HyperV Firewall from SFOS 18.5.1 MR-1-Build326 to 18.5.2 MR2-Build380 

posted this error during update routine.

All works fine but trying to restart on-box-reports show this prompt

Sophos Firmware Version SFOS 18.5.2 MR-2-Build380
console> show on-box-reports
Local Reporting : off

console> set on-box-reports on
On-Appliance reporting is currently turned OFF. Failed to upgrade On-Appliance Cyberoam-iView. Please contact support.
console>

Creating a ticket and Sophos Support give me this three options to resolve the problem:

Option1
We can conduct database recovery by running maintenance. (No downtime expected)
We can run this from our end and check if this would resolve the issue.

Option 2
Restore the backup directly (Downtime is expected) (10 minutes)
You may generate a new backup and restore back so it would rebuild the database.

Option 3 Downtime expected to switch to new instance.
Since this is a VM instance, you may spin a new instance and restore the backup onto that instance.

So option 2 sounds for me for the easyest and fastest way to get this problem fixed.

Yesterday I backup my configure and import it to my running firewall.
Checking status of on-box-reports:

Sophos Firmware Version SFOS 18.5.2 MR-2-Build380
console> show on-box-reports
Local Reporting : off

And trying to start it:

console> set on-box-reports on
console> show on-box-reports
Local Reporting : on

Show a fine state.
After restart the firewall alert warning in WebAdmin is gone too.

Thank you Sophos for your support!



This thread was automatically locked due to age.
Parents
  • Hello FMMajo,

    Thank you for sharing what options were given to you to solve the issue. 
    I'm pasting the Options in this comment as well:

    Option1
    We can conduct database recovery by running maintenance. (No downtime expected)
    We can run this from our end and check if this would resolve the issue.

    Option 2
    Restore the backup directly (Downtime is expected) (10 minutes)
    You may generate a new backup and restore back so it would rebuild the database.

    Option 3 Downtime expected to switch to new instance.
    Since this is a VM instance, you may spin a new instance and restore the backup onto that instance.

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
Reply
  • Hello FMMajo,

    Thank you for sharing what options were given to you to solve the issue. 
    I'm pasting the Options in this comment as well:

    Option1
    We can conduct database recovery by running maintenance. (No downtime expected)
    We can run this from our end and check if this would resolve the issue.

    Option 2
    Restore the backup directly (Downtime is expected) (10 minutes)
    You may generate a new backup and restore back so it would rebuild the database.

    Option 3 Downtime expected to switch to new instance.
    Since this is a VM instance, you may spin a new instance and restore the backup onto that instance.

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?