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

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.

0 BrucekConvergent over 12 years ago

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.
Cancel
Vote Up 0 Vote Down

Cancel
0 Hakan Yueksel over 12 years ago 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
Cancel
Vote Up 0 Vote Down

Cancel
0 BrucekConvergent over 12 years ago 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.
Cancel
Vote Up 0 Vote Down

Cancel
0 AdrienBelcourt over 12 years ago

Hi Hakan,

Thankyou for the detailed response.   Would I be right in thinking that the method to swap hardware then is

1. Install from ISO
2. Restore backup
3. Without connecting Astaro to network
    a) find out the GUID it should have by
    "www.astaro.org/.../39793-asg-backup-restore-does-not-err-backup-restore.html
    b) replace the GUID in /etc/guid by "vi /etc/guid"
4. Then connect the new Astaro to the network and ACC should pick it up.

I suspect I may have missed out some steps, but is this generally okay?

Thanks in advance,

Adrien.
Cancel
Vote Up 0 Vote Down

Cancel
0 Hakan Yueksel over 12 years ago in reply to AdrienBelcourt

Hi,

@Adrien
It's OK.

@Bruce
We haven't had such plans yet. As I mentioned, since V8.2 it is possible
to restore a backup on a machine other than the backup was created
on. ACC's backup management makes use of this feature. You can create
a backup on a particular ASG and roll it out on several other ASG's.

In this case a backup with guid included would reduce the actual meaning
of a guid, i.e. being a unique identifier, to absurdity. Therefore we would
need to thoroughly plan a concept for this.

Feel free to suggest it on feature.astaro.com.

Regards, Hakan
Cancel
Vote Up 0 Vote Down

Cancel
0 BrucekConvergent over 12 years ago in reply to Hakan Yueksel

Hakan, it's simple -- include a checkbox, etc. on the ACC and / or ASG to allow the import of the GUID during backup restore (or not), similar to the feature now that allows one to strip the hostnames, certs, etc.

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.
Cancel
Vote Up 0 Vote Down

Cancel
0 AdrienBelcourt over 12 years ago in reply to BrucekConvergent

Thankyou. This worked very well. We are running on the new VM, without the drama of a reconfiguration.

Best Regards,
Cancel
Vote Up 0 Vote Down

Cancel