Login  Register

Re: Restore 3.1.0.6 backup

Posted by GLASS mailing list on Oct 30, 2018; 5:52pm
URL: https://forum.world.st/Restore-3-1-0-6-backup-tp5087691p5087969.html

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 four Abort    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



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass