Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 14298 views
  • Users 0 members are here
Options
Suggested
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

ASG backup & restore, does not err backup & restore

AdrienBelcourt
Hi Gents and Lady,

We have an ACC with a sick ASG with limping and inadequate hardware.  Tried the obvious thing - new hardware, install ASG ISO, restore backup, unplug old, plug in new - but ACC did not recognise the new "old" machine and all the ACC based definitions (hosts, PF rules, etc.) were missing on the restored machine. Result put old machine back in with its regular crashes and fails.  

Anyone any experience of doing something like this, please?   I have tried RTFM but it does not seem to cover things like this.  

I was gob-smacked that the ASG backup & restore does not seem to, well, backup and restore in an ACC environment.   

Have we just missed something obvious?

Thanks in advance,

Adrien.


This thread was automatically locked due to age.
Parents
  • 0
    Yes... and it's one of my few gripes with ACC in general:  If you replace an ASG, and restore a backup, it will not automatically take it's rightful place in the ACC inventory --- for some reason, the guid of the ASG installation that the ACC uses to identify an ASG is not part of the backup, so a new unit, even with a restored backup, shows up as another system that you have to reconfigured, at least for the ACC-pushed bits, like the central configurations, access control, etc.

    Not sure why it's designed that way, but that's how it's worked from day 1.

    BTW, the definitions, etc. that were deployed previous to your failure should at least be present in the restored config --- the only thing that happens is that they are "orphaned" and are no longer manageable by the ACC, you have to re-deploy them.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Reply
  • 0
    Yes... and it's one of my few gripes with ACC in general:  If you replace an ASG, and restore a backup, it will not automatically take it's rightful place in the ACC inventory --- for some reason, the guid of the ASG installation that the ACC uses to identify an ASG is not part of the backup, so a new unit, even with a restored backup, shows up as another system that you have to reconfigured, at least for the ACC-pushed bits, like the central configurations, access control, etc.

    Not sure why it's designed that way, but that's how it's worked from day 1.

    BTW, the definitions, etc. that were deployed previous to your failure should at least be present in the restored config --- the only thing that happens is that they are "orphaned" and are no longer manageable by the ACC, you have to re-deploy them.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Children
  • 0 in reply to BrucekConvergent
    Hi Adrien and Bruce,

    it is true that the guid is not part of the backup. This was rather
    coincidence than design. Since V8.2 it is not easy to make it part
    of the backup as it is now possible to restore a backup on a machine
    other than the machine the backup was created on.

    @Adrien
    there is a workaround for your issue:


    • login to your asg per ssh
    • find out which guid it has now: 
      cat /etc/guid

    • find out which guid it had previously 
      psql -U acc -P pager=off -c "select * from device_info;"

    • on the asg replace the new guid by the old guid in the file /etc/guid
    • disable and enable again central management on the asg
    • now the ACC should recognize the old asg and should automatically
      deploy the objects
    • the remaining asg object with the undesired guid shoul appear as offline
      in the dashboard, you can just delete it under Mamagement -> Registration


    Regards, Hakan
  • 0 in reply to Hakan Yueksel
    Hakan... are there any plans to make guid as part of the backup?  Sure would make replacing bad appliances, etc. easier on the management end -- would also make major firmware updates on software appliances less troublesome (the ones that require a reload from ISO).

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Unfiltered HTML