[Glass] Restore 3.1.0.6 backup

[Dale Henrichs via Glass]

Dario,

In the tODE shell try running the following:

script --script=rebuildSys

If you get some walkbacks about missing directories go ahead press the 
terminate button ... most of the repair should be complete ... the 
repository paths will have to be repaired separately.

When I did a restore to a different machine I did notice that doing an 
`ls` in the tODE shell gave me an "odd" result, but I didn't see the 
issues that you were reporting ... rebuildSys should connect the tODE 
directory structure to the current GsDevKit_home directory structure ... 
if you copy over your git repositories to $GS_HOME/shared/repos then the 
missing repo directory errors might go away ---

If they don't I should be able to suggest additional things to try ... 
at the end of the day, we should be able to build up a repair script 
that properly repairs the tODE structures when you are restoring to 
completely different machine ... a use case that I had not planned for 
... but a use case that I think is important ...

Dale

On 10/30/2018 09:50 AM, Dale Henrichs wrote:
>
>
>
> On 10/24/2018 09:11 AM, Trussardi Dario Romano via Glass wrote:
>> Ciao,
>>
>> i have a deployment system based on stone 3.1.0.6 and gsDevKitHome.
>>
>> The system was installed in early 2015.
>>
>> Now i do some test to restored the database backup ( from this 
>> deployment system ) on another system  (  called emergency PC )
>>
>> This emergency PC is based on GsDevKit_home git ebc8e7b commit.
>>
>> On it i create the the stone with the command:  createStone base_3106 
>> 3.1.0.6
>>
>> A this point all works fine from tode command. ( ws  for example )
>>
>> Now from topaz session i successfully gave the commands:
>>
>> 1) SystemRepository restoreFromBackup: 
>> '/opt/GsDkB/GsDevKit_home/server/stones/base_3106/backups/backup_20181023.dbf.gz'
>>
>> 2) SystemRepository commitRestore
>>
>> But after when i login from tode and i do the:ws  command
>> the system sometimes answer with the error :
>>
>> *a InternalError occurred ( error 2261 ) , The object with object 
>> ID aTDSessionDescription is corrupt.*
>> *
>> *
>> *Reason 'store past end'*
>> *
>> *
>> in this case after 40 seconds the tode shell report:
>>
>> GciSessionNotLoggedInError: Session no longer logged in.
>> Check the gem log for error messages (look at the most recent gem log 
>> file: `ls $GS_HOME/server/stones/base_3106/logs/gemnetobject*.log`.
>> If your stone is running -and healthy (`cat 
>> $GS_HOME/server/stones/base_3106/logs/base_3106.log`), you can try 
>> again.
>> **
>>
>> sometimes answer the error:
>>
>> *a InternalError occurred ( error 2261 ) , The object with object ID 
>> *remoteNil is corrupt.**
>> *
>> *
>> *Reason 'store past end'*
>> In this case :
>> after fourAbort    button click the system open the workspace
>>
>> and the tode shell report :AUTOCOMMIT DISABLEDAbortered ......
>>
>>
>> and the tode 1 >     is red
>>
>> Some considerations ?
> Dario,
>
> Am I right in thinking that you are doing the restore from backup into 
> a stone on another system? If so you are likely missing some of the 
> disk structure that tODE expects to find. but first I would like to 
> see a full stack from the error that you are getting, because I would 
> like to understand the context in which the "corrupt" object errors 
> are occurring I will spend some time today and try to reproduce the 
> problem locally so that I can characterize the problem more thoroughly ...
>
> Dale
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20181030/96025f49/attachment.html>