Met de komst van OpenERP V6 heb ik geen problemen meer met het veiligstellen en terugzetten van databases.

Om wat meer feeling met OpenERP te krijgen ben ik het boek "Open ERP, a modern approach to integrated business management" aan het doornemen en gebruik hierbij de voorbeelden zoals deze worden beschreven.

Op blz. 81 - 7.5.8 backup database loop ik tegen het volgende probleem aan. Na backup van de database openerp_ch03 in openerp_ch03.dump probeer ik deze zoals beschreven te herstellen in de database testing. (via openerp-web client 5.0.6.)

Na restore van deze database in testing probeer ik als admin / admin in te loggen op de database testing maar wordt geweigerd ? Uiteindelijk heb ik de db testing verwijderd via drop db, met als gevolg dat de web-client in zijn geheel niet meer in het loginscherm komt. zie onderstaande Onderstaande foutmelding

Unrecoverable error in the server.
Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/CherryPy-3.1.2-py2.5.egg/cherrypy/_cprequest.py", line 541, in run
self.respond(pi)
File "/usr/lib/python2.5/site-packages/CherryPy-3.1.2-py2.5.egg/cherrypy/_cprequest.py", line 624, in respond
self.handle_error()
File "/usr/lib/python2.5/site-packages/CherryPy-3.1.2-py2.5.egg/cherrypy/_cprequest.py", line 746, in handle_error
self.error_response()
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/controllers/root.py", line 52, in _cp_on_error
message = errorpage.render()
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/controllers/error_page.py", line 61, in render
return self.__render(value)
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/tools/expose.py", line 204, in func_wrapper
res = func(*args, **kw)
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/controllers/error_page.py", line 79, in __render
maintenance = proxy.status()
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/rpc.py", line 389, in <lambda>
return lambda *args: self._session.execute("object", "execute", self._resource, name, *args)
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/rpc.py", line 350, in execute
return self.gateway.execute(obj, method, *args)
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/rpc.py", line 154, in execute
return self.__execute(obj, method, args)
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/rpc.py", line 140, in __execute
raise common.error(_('Application Error!'), err.backtrace)
File "/usr/lib/python2.5/site-packages/openerp_web-5.0.6-py2.5.egg/openerp/common.py", line 72, in error
raise TinyError(message=msg, title=title or _("Error"))
TinyError: Traceback (most recent call last):
File "/usr/lib/openerp-server/netsvc.py", line 244, in dispatch
result = LocalService(service_name)(method, *params)
File "/usr/lib/openerp-server/netsvc.py", line 73, in __call__
return getattr(self, method)(*params)
File "/usr/lib/openerp-server/service/web_services.py", line 583, in execute
res = service.execute(db, uid, object, method, *args)
File "/usr/lib/openerp-server/osv/osv.py", line 57, in wrapper
if not pooler.get_pool(dbname)._ready:
File "/usr/lib/openerp-server/pooler.py", line 81, in get_pool
pool = get_db_and_pool(db_name, force_demo, status, update_module)[1]
File "/usr/lib/openerp-server/pooler.py", line 29, in get_db_and_pool
db = get_db_only(db_name)
File "/usr/lib/openerp-server/pooler.py", line 72, in get_db_only
db = sql_db.db_connect(db_name)
File "/usr/lib/openerp-server/sql_db.py", line 243, in db_connect
return PoolManager.get(db_name)
File "/usr/lib/openerp-server/sql_db.py", line 227, in get
cls._pools[db_name] = ConnectionPool(ThreadedConnectionPool(1, cls.maxconn, cls.dsn(db_name)), db_name)
File "/usr/lib/python2.5/site-packages/psycopg2/pool.py", line 161, in __init__
self, minconn, maxconn, *args, **kwargs)
File "/usr/lib/python2.5/site-packages/psycopg2/pool.py", line 76, in __init__
self._connect()
File "/usr/lib/python2.5/site-packages/psycopg2/pool.py", line 80, in _connect
conn = psycopg2.connect(*self._args, **self._kwargs)
OperationalError: FATAL: database "testing" does not exist

Met de GTK client heb ik de db testing opnieuw aangemaakt, waarna de web-client weer gewoon werkt, daarna ingelogd op db openerp_ch03.

Hoewel ik de werkwijze zoals beschreven, heb gevolgd is een succesvolle backup & restore van een db nog niet gelukt. Voordat ik OpenERP als productie db kan gebruiken is het wel belangrijk de backup & restore procedure werkend te krijgen.

Wellicht zie ik iets over het hoofd of heeft iemand soortgelijke problemen ondervonden (en opgelost). Help, tips & trucs zijn meer dan welkom om een werkende db via backup & restore te krijgen.

Dag Paul,

zelf gebruik ik de webclient erg weinig, er zitten nog weleens fouten in welke in de GTK client niet voorkomen.
Voor beheerstaken gebruik ik eigenlijk alleen de GTK-client.

M.b.t. backup van de database, is de backup mogelijkheid van OpenERP zelf niet geschikt. Leuk om eenmalig snel even een backup te maken en deze mag dan niet al te groot zijn anders krijg je weer time-out errors op de client.
Voor productieomgevingen gebruik je pgdump en pgrestore van postgres zelf.
Deze kan je ook in een cronjob zetten waardoor je zonder menselijk interactie verzekerd bent van backup. Via een rsync kan je dan de gemaakte backup weer naar een andere server overzetten.

Hallo Jan,

Wederom bedankt voor je snelle reactie.

Ik ben nog niet zo lang overgestapt van "windhoos" naar Linux (Ubuntu) en heb intussen al veel geleerd. Sommige dingen echter vergen wat meer tijd voor iemand die gewend is om click, click, click en click te doen om zaken voor elkaar te krijgen op zijn PC & server.

pgdump & pgrestore zeggen mij dus niet zo veel maar ben het verder aan het uitzoeken. In het forum wordt verwezen naar http://openobject.com/forum/topic13335.html zijnde een auto-backup addon in trunk-exta-addons.

Heb jij wellicht ervaring hiermee? En is het aan te raden voor een productieomgeving?

auto-backup addon in trunk-exta-addons heb ik geen ervaring mee. Gezien de comments over fouten zou ik persoonlijk hier ook niet mee beginnen.
Een cronjob direct van linux aangestuurd is toch weer een stuurlaag minder en geeft meer zekerheid.
Ik zou zelf een backup-scriptje schrijven, dan kan je deze ook volledig aan je eigen wensen aanpassen, na backup rsyncen naar een andere machine, een succesvol emailtje laten sturen, etc.
Er is veel informatie over te vinden op internet. pg_dump en pg_restore zijn de tools van postgres zelf, rsync en cronjob is even zoeken op internet.

Een back up en restore met behulp van grafisch werkende toepassing pgAdim werkt bij mij perfect. Zowel in Windows 7 als ook in XP.

@ton123, voor een produktie omgeving is pgadmin niet geschikt om automatisch backups te maken.
Wat doe je b.v. met je documenten directory waarin b.v. je PDF facturen zijn opgeslagen? Die neem je met pgadmin niet mee!

@janneman je hebt helemaal gelijk. Maar ik ben nog in de leerfase en testcase. Voor productie moet dit inderdaad geautomatiseerd zijn via script of iets dergelijks. Met betrekking tot de documentendirectorie zeg je iets interessants voor me. Ik heb elders in het forum een vraag gesteld over hoe kennismanagement / documentmanagement te implementeren. Met databasestore of met filestore. In mijn testen startte ik met filestore omdat ik dan meer grip heb. In tweede testen gebruikte ik databasestore omdat dan alles zo lekker geïntegreerd is. Nu blijkt dat grote files errors geven en niet meer zijn te verwijderen, kom ik weer terug op filestore....