From suporte at logicworks.pt Wed Feb 28 12:14:05 2018 Content-Type: multipart/mixed; boundary="===============9079057146075663981==" MIME-Version: 1.0 From: suporte at logicworks.pt To: users at ovirt.org Subject: [ovirt-users] Backup & Restore Date: Wed, 28 Feb 2018 12:10:59 +0000 Message-ID: <1044341911.20329570.1519819859027.JavaMail.zimbra@logicworks.pt> --===============9079057146075663981== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_20329569_1409874801.1519819859027 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit Hi, = I'm testing backup & restore on Ovirt 4.2. = I follow this doc https://www.ovirt.org/documentation/admin-guide/chap-Back= ups_and_Migration/ = Try to restore to a fresh installation but always get this error message: = restore-permissions = Preparing to restore: = - Unpacking file 'back_file' = Restoring: = - Files = Provisioning PostgreSQL users/databases: = - user 'engine', database 'engine' = Restoring: = FATAL: Can't connect to database 'ovirt_engine_history'. Please see '/usr/b= in/engine-backup --help'. = On the live engine I run # engine-backup --scope=3Dall --mode=3Dbackup --fi= le=3Dfile_name --log=3Dlog_file_name = And try to restore on a fresh installation: = # engine-backup --mode=3Drestore --file=3Dfile_name --log=3Dlog_file_name -= -provision-db --restore-permissions = Any Idea? = Thanks = -- = Jose Ferradeira = http://www.logicworks.pt = ------=3D_Part_20329569_1409874801.1519819859027 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable
H=3D i,

I'm testing backup & restore on Ovirt 4.2.
I follow this doc ht= tp=3D s://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/
T=3D ry to restore to a fresh installation but always get this error message:

restore-permissions
Preparing to restore:
- Unpacking file 'back_file'
Restoring:
- Files
Provisioning PostgreSQL us= =3D ers/databases:
- user 'engine', database 'engine'
Restoring:
FATAL: Can't connect to database 'ovirt_e= =3D ngine_history'. Please see '/usr/bin/engine-backup --help'.

On the = li=3D ve engine I run # engine-backup --scope=3D3Dall --mode=3D3Dbackup --fi= le=3D =3D3Dfile_name --log=3D3Dlog_file_name

And try to resto= re=3D on a fresh installation:
# engine-backup --mode=3D3Drestore --file=3D3Df= ile_=3D name --log=3D3Dlog_file_name --provision-db --restore-permissions

Any Idea?

Than= ks=3D


=

--
Jose Ferradeira
http:/= /w=3D ww.logicworks.pt

------=3D_Part_20329569_1409874801.1519819859027-- --===============9079057146075663981== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzIwMzI5NTY5XzE0MDk4NzQ4MDEuMTUxOTgxOTg1OTAyNwpDb250ZW50LVR5 cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGksIAoKSSdtIHRlc3RpbmcgYmFja3VwICYgcmVzdG9yZSBvbiBPdmlydCA0LjIuIApJ IGZvbGxvdyB0aGlzIGRvYyBodHRwczovL3d3dy5vdmlydC5vcmcvZG9jdW1lbnRhdGlvbi9hZG1p bi1ndWlkZS9jaGFwLUJhY2t1cHNfYW5kX01pZ3JhdGlvbi8gClRyeSB0byByZXN0b3JlIHRvIGEg ZnJlc2ggaW5zdGFsbGF0aW9uIGJ1dCBhbHdheXMgZ2V0IHRoaXMgZXJyb3IgbWVzc2FnZTogCgpy ZXN0b3JlLXBlcm1pc3Npb25zIApQcmVwYXJpbmcgdG8gcmVzdG9yZTogCi0gVW5wYWNraW5nIGZp bGUgJ2JhY2tfZmlsZScgClJlc3RvcmluZzogCi0gRmlsZXMgClByb3Zpc2lvbmluZyBQb3N0Z3Jl U1FMIHVzZXJzL2RhdGFiYXNlczogCi0gdXNlciAnZW5naW5lJywgZGF0YWJhc2UgJ2VuZ2luZScg ClJlc3RvcmluZzogCkZBVEFMOiBDYW4ndCBjb25uZWN0IHRvIGRhdGFiYXNlICdvdmlydF9lbmdp bmVfaGlzdG9yeScuIFBsZWFzZSBzZWUgJy91c3IvYmluL2VuZ2luZS1iYWNrdXAgLS1oZWxwJy4g CgpPbiB0aGUgbGl2ZSBlbmdpbmUgSSBydW4gIyBlbmdpbmUtYmFja3VwIC0tc2NvcGU9YWxsIC0t bW9kZT1iYWNrdXAgLS1maWxlPWZpbGVfbmFtZSAtLWxvZz1sb2dfZmlsZV9uYW1lIAoKQW5kIHRy eSB0byByZXN0b3JlIG9uIGEgZnJlc2ggaW5zdGFsbGF0aW9uOiAKIyBlbmdpbmUtYmFja3VwIC0t bW9kZT1yZXN0b3JlIC0tZmlsZT1maWxlX25hbWUgLS1sb2c9bG9nX2ZpbGVfbmFtZSAtLXByb3Zp c2lvbi1kYiAtLXJlc3RvcmUtcGVybWlzc2lvbnMgCgpBbnkgSWRlYT8gCgpUaGFua3MgCgoKCi0t IAoKSm9zZSBGZXJyYWRlaXJhIApodHRwOi8vd3d3LmxvZ2ljd29ya3MucHQgCgoKLS0tLS0tPV9Q YXJ0XzIwMzI5NTY5XzE0MDk4NzQ4MDEuMTUxOTgxOTg1OTAyNwpDb250ZW50LVR5cGU6IHRleHQv aHRtbDsgY2hhcnNldD11dGYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJp bnRhYmxlCgo8aHRtbD48Ym9keT48ZGl2IHN0eWxlPTNEImZvbnQtZmFtaWx5OiB0cmVidWNoZXQg bXMsc2Fucy1zZXJpZjsgZm9udC1zaXplOiA9CjEycHQ7IGNvbG9yOiAjMDAwMDAwIj48ZGl2IGRh dGEtbWFya2VyPTNEIl9fUVVPVEVEX1RFWFRfXyI+PGRpdiBzdHlsZT0zRCJmbz0KbnQtZmFtaWx5 OiBUaW1lcyBOZXcgUm9tYW47IGZvbnQtc2l6ZTogMTBwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRh LW1jZS1zdHlsPQplPTNEImZvbnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW47IGZvbnQtc2l6ZTog MTBwdDsgY29sb3I6ICMwMDAwMDA7Ij48ZGl2Pkg9CmksPGJyPjwvZGl2Pjxicj48ZGl2PjxzcGFu IHN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1pbmFsLD0KIG1vbmFj bzsiIGRhdGEtbWNlLXN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1p bmFsLCBtb25hY287PQoiPkknbSB0ZXN0aW5nIGJhY2t1cCAmYW1wOyByZXN0b3JlIG9uIE92aXJ0 IDQuMi48L3NwYW4+PGJyPjwvZGl2PjxkaXY+PHNwYW49CiBzdHlsZT0zRCJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOyIgZGF0YS1tY2Utc3R5bGU9Cj0zRCJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOyI+SSBmb2xsb3cg dGhpcyBkb2MgaHR0cD0KczovL3d3dy5vdmlydC5vcmcvZG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlk ZS9jaGFwLUJhY2t1cHNfYW5kX01pZ3JhdGlvbi88L3NwPQphbj48YnI+PC9kaXY+PGRpdj48c3Bh biBzdHlsZT0zRCJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW89Cm5h Y287IiBkYXRhLW1jZS1zdHlsZT0zRCJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJt aW5hbCwgbW9uYWNvOyI+VD0KcnkgdG8gcmVzdG9yZSB0byBhIGZyZXNoIGluc3RhbGxhdGlvbiBi dXQgYWx3YXlzIGdldCB0aGlzIGVycm9yIG1lc3NhZ2U6PC9zPQpwYW4+PGJyPjwvZGl2Pjxicj48 ZGl2PjxzcGFuIHN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1pbmE9 CmwsIG1vbmFjbzsiIGRhdGEtbWNlLXN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IHRlcm1pbmFsLCBtb25hYz0KbzsiPnJlc3RvcmUtcGVybWlzc2lvbnM8L3NwYW4+PGJyPjxz cGFuIHN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pPQpseTogdGVybWluYWwsIG1v bmFjbzsiIGRhdGEtbWNlLXN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRl cm09CmluYWwsIG1vbmFjbzsiPlByZXBhcmluZyB0byByZXN0b3JlOjwvc3Bhbj48YnI+PHNwYW4g c3R5bGU9M0QiZm9udC1zaXplOiAxMT0KcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNv OyIgZGF0YS1tY2Utc3R5bGU9M0QiZm9udC1zaXplOiAxMXB0OyBmb250PQotZmFtaWx5OiB0ZXJt aW5hbCwgbW9uYWNvOyI+LSBVbnBhY2tpbmcgZmlsZSAnYmFja19maWxlJzwvc3Bhbj48YnI+PHNw YW4gc3Q9CnlsZT0zRCJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9u YWNvOyIgZGF0YS1tY2Utc3R5bGU9M0QiZj0Kb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0 ZXJtaW5hbCwgbW9uYWNvOyI+UmVzdG9yaW5nOjwvc3Bhbj48YnI+PHNwYW4gPQpzdHlsZT0zRCJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOyIgZGF0YS1tY2Ut c3R5bGU9M0Q9CiJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNv OyI+LSBGaWxlczwvc3Bhbj48YnI+PHNwYW4gcz0KdHlsZT0zRCJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOyIgZGF0YS1tY2Utc3R5bGU9M0QiPQpmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOyI+UHJvdmlzaW9uaW5nIFBv c3RncmVTUUwgdXM9CmVycy9kYXRhYmFzZXM6PC9zcGFuPjxicj48c3BhbiBzdHlsZT0zRCJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaT0KbmFsLCBtb25hY287IiBkYXRhLW1jZS1z dHlsZT0zRCJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uPQphY287 Ij4tIHVzZXIgJ2VuZ2luZScsIGRhdGFiYXNlICdlbmdpbmUnPC9zcGFuPjxicj48c3BhbiBzdHls ZT0zRCJmb250LXNpemU9CjogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1pbmFsLCBtb25hY287IiBk YXRhLW1jZS1zdHlsZT0zRCJmb250LXNpemU6IDExcHQ7ID0KZm9udC1mYW1pbHk6IHRlcm1pbmFs LCBtb25hY287Ij5SZXN0b3Jpbmc6PC9zcGFuPjxicj48c3BhbiBzdHlsZT0zRCJmb250LXNpPQp6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1pbmFsLCBtb25hY287IiBkYXRhLW1jZS1zdHlsZT0z RCJmb250LXNpemU6IDExcHQ9CjsgZm9udC1mYW1pbHk6IHRlcm1pbmFsLCBtb25hY287Ij5GQVRB TDogQ2FuJ3QgY29ubmVjdCB0byBkYXRhYmFzZSAnb3ZpcnRfZT0KbmdpbmVfaGlzdG9yeScuIFBs ZWFzZSBzZWUgJy91c3IvYmluL2VuZ2luZS1iYWNrdXAgLS1oZWxwJy48L3NwYW4+PGJyPjwvZGl2 PQo+PGJyPjxkaXY+PHNwYW4gc3R5bGU9M0QiZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog dGVybWluYWwsIG1vbmFjbzsiIGQ9CmF0YS1tY2Utc3R5bGU9M0QiZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogdGVybWluYWwsIG1vbmFjbzsiPk9uIHRoZSBsaT0KdmUgZW5naW5lIEkgcnVu Jm5ic3A7IyBlbmdpbmUtYmFja3VwIC0tc2NvcGU9M0RhbGwgLS1tb2RlPTNEYmFja3VwIC0tZmls ZT0KPTNEZmlsZV9uYW1lIC0tbG9nPTNEbG9nX2ZpbGVfbmFtZTwvc3Bhbj48L2Rpdj48ZGl2Pjxz cGFuIHN0eWxlPTNEImZvbnQtc2l6PQplOiAxMXB0OyBmb250LWZhbWlseTogdGVybWluYWwsIG1v bmFjbzsiIGRhdGEtbWNlLXN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDs9CiBmb250LWZhbWlseTog dGVybWluYWwsIG1vbmFjbzsiPjxiciBkYXRhLW1jZS1ib2d1cz0zRCIxIj48L3NwYW4+PC9kaXY+ PGRpdj0KPjxzcGFuIHN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1p bmFsLCBtb25hY287IiBkYXRhLW1jZS1zPQp0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IHRlcm1pbmFsLCBtb25hY287Ij5BbmQgdHJ5IHRvIHJlc3RvcmU9CiBvbiBhIGZyZXNo IGluc3RhbGxhdGlvbjo8L3NwYW4+PGJyPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9M0QiZm9udC1z aXplOiAxMT0KcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOyIgZGF0YS1tY2Utc3R5 bGU9M0QiZm9udC1zaXplOiAxMXB0OyBmb250PQotZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOyI+ IyBlbmdpbmUtYmFja3VwIC0tbW9kZT0zRHJlc3RvcmUgLS1maWxlPTNEZmlsZV89Cm5hbWUgLS1s b2c9M0Rsb2dfZmlsZV9uYW1lIC0tcHJvdmlzaW9uLWRiIC0tcmVzdG9yZS1wZXJtaXNzaW9uczwv c3Bhbj48L2Rpdj0KPjxkaXY+PHNwYW4gc3R5bGU9M0QiZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogdGVybWluYWwsIG1vbmFjbzsiIGRhdGEtPQptY2Utc3R5bGU9M0QiZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogdGVybWluYWwsIG1vbmFjbzsiPjxiciBkYXRhLW1jZS09CmJvZ3Vz PTNEIjEiPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPTNEImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6ID0KdGVybWluYWwsIG1vbmFjbzsiIGRhdGEtbWNlLXN0eWxlPTNEImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1pbmFsPQosIG1vbmFjbzsiPkFueSBJZGVhPzxi ciBkYXRhLW1jZS1ib2d1cz0zRCIxIj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0KPTNE ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1pbmFsLCBtb25hY287IiBkYXRhLW1j ZS1zdHlsZT0zRCJmb250PQotc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IHRlcm1pbmFsLCBtb25h Y287Ij48YnIgZGF0YS1tY2UtYm9ndXM9M0QiMSI+PC9zcGE9Cm4+PC9kaXY+PGRpdj48c3BhbiBz dHlsZT0zRCJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOz0K IiBkYXRhLW1jZS1zdHlsZT0zRCJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiB0ZXJtaW5h bCwgbW9uYWNvOyI+VGhhbmtzPQo8YnIgZGF0YS1tY2UtYm9ndXM9M0QiMSI+PC9zcGFuPjwvZGl2 PjxkaXY+PHNwYW4gc3R5bGU9M0QiZm9udC1zaXplOiAxMXB0OyA9CmZvbnQtZmFtaWx5OiB0ZXJt aW5hbCwgbW9uYWNvOyIgZGF0YS1tY2Utc3R5bGU9M0QiZm9udC1zaXplOiAxMXB0OyBmb250LWZh bT0KaWx5OiB0ZXJtaW5hbCwgbW9uYWNvOyI+PGJyIGRhdGEtbWNlLWJvZ3VzPTNEIjEiPjwvc3Bh bj48L2Rpdj48ZGl2PjxzcGFuIHN0PQp5bGU9M0QiZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogdGVybWluYWwsIG1vbmFjbzsiIGRhdGEtbWNlLXN0eWxlPTNEImY9Cm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogdGVybWluYWwsIG1vbmFjbzsiPjxiciBkYXRhLW1jZS1ib2d1cz0zRCIx Ij48Lz0Kc3Bhbj48L2Rpdj48YnI+PGRpdj4tLSA8YnI+PC9kaXY+PGRpdj48aHIgc3R5bGU9M0Qi d2lkdGg6IDEwMCU7IGhlaWdodDogMnB4PQo7IiBkYXRhLW1jZS1zdHlsZT0zRCJ3aWR0aDogMTAw JTsgaGVpZ2h0OiAycHg7Ij5Kb3NlIEZlcnJhZGVpcmE8YnI+aHR0cDovL3c9Cnd3LmxvZ2ljd29y a3MucHQ8L2Rpdj48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4KLS0tLS0tPV9Q YXJ0XzIwMzI5NTY5XzE0MDk4NzQ4MDEuMTUxOTgxOTg1OTAyNy0tCg== --===============9079057146075663981==-- From didi at redhat.com Wed Feb 28 12:24:53 2018 Content-Type: multipart/mixed; boundary="===============4371279087828630563==" MIME-Version: 1.0 From: Yedidyah Bar David To: users at ovirt.org Subject: Re: [ovirt-users] Backup & Restore Date: Wed, 28 Feb 2018 14:24:50 +0200 Message-ID: In-Reply-To: 1044341911.20329570.1519819859027.JavaMail.zimbra@logicworks.pt --===============4371279087828630563== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2018 at 2:10 PM, wrote: > Hi, > > I'm testing backup & restore on Ovirt 4.2. > I follow this doc > https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migratio= n/ > Try to restore to a fresh installation but always get this error message: > > restore-permissions > Preparing to restore: > - Unpacking file 'back_file' > Restoring: > - Files > Provisioning PostgreSQL users/databases: > - user 'engine', database 'engine' > Restoring: > FATAL: Can't connect to database 'ovirt_engine_history'. Please see > '/usr/bin/engine-backup --help'. > > On the live engine I run # engine-backup --scope=3Dall --mode=3Dbackup > --file=3Dfile_name --log=3Dlog_file_name > > And try to restore on a fresh installation: > # engine-backup --mode=3Drestore --file=3Dfile_name --log=3Dlog_file_name > --provision-db --restore-permissions > > Any Idea? Please try adding to restore command '--providion-dwh-db'. Thanks. -- = Didi --===============4371279087828630563==-- From suporte at logicworks.pt Wed Feb 28 12:45:09 2018 Content-Type: multipart/mixed; boundary="===============5854441623495726282==" MIME-Version: 1.0 From: suporte at logicworks.pt To: users at ovirt.org Subject: Re: [ovirt-users] Backup & Restore Date: Wed, 28 Feb 2018 12:45:04 +0000 Message-ID: <1513265050.20337674.1519821904171.JavaMail.zimbra@logicworks.pt> In-Reply-To: CAHRwYXvD18f1WiciEcAoJw6kcSJrwJYsO6qeTTR30anKci-Jhg@mail.gmail.com --===============5854441623495726282== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_20337673_1603009670.1519821904170 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit Still no luck: = # engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur --pr= ovision-db --restore-permissions --provision-dwh-db = Preparing to restore: = - Unpacking file 'back_futur' = Restoring: = - Files = Provisioning PostgreSQL users/databases: = - user 'engine', database 'engine' = - user 'ovirt_engine_history', database 'ovirt_engine_history' = Restoring: = - Engine database 'engine' = FATAL: Errors while restoring database engine = I did a engine-cleanup, try it again but still the same error. = De: "Yedidyah Bar David" = Para: suporte(a)logicworks.pt = Cc: "ovirt users" = Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50 = Assunto: Re: [ovirt-users] Backup & Restore = On Wed, Feb 28, 2018 at 2:10 PM, wrote: = > Hi, = > = > I'm testing backup & restore on Ovirt 4.2. = > I follow this doc = > https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migratio= n/ = > Try to restore to a fresh installation but always get this error message: = > = > restore-permissions = > Preparing to restore: = > - Unpacking file 'back_file' = > Restoring: = > - Files = > Provisioning PostgreSQL users/databases: = > - user 'engine', database 'engine' = > Restoring: = > FATAL: Can't connect to database 'ovirt_engine_history'. Please see = > '/usr/bin/engine-backup --help'. = > = > On the live engine I run # engine-backup --scope=3Dall --mode=3Dbackup = > --file=3Dfile_name --log=3Dlog_file_name = > = > And try to restore on a fresh installation: = > # engine-backup --mode=3Drestore --file=3Dfile_name --log=3Dlog_file_name = > --provision-db --restore-permissions = > = > Any Idea? = Please try adding to restore command '--providion-dwh-db'. Thanks. = -- = Didi = ------=3D_Part_20337673_1603009670.1519821904170 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable
Still no luck:

# engine-backup --mode=3D3Drestore --file=3D3Dback_futu= r --lo=3D g=3D3Dlog_futur --provision-db --restore-permissions --provision-dwh-db
= Pr=3D eparing to restore:
- Unpacking file 'back_futur'
Restoring:
- Fil= =3D es
Provisioning PostgreSQL users/databases:
- user 'engine', database= =3D 'engine'
- user 'ovirt_engine_history', database 'ovirt_engine_history'= =3D
Restoring:
- Engine database 'engine'
FATAL: Errors while restori= =3D ng database engine

I di= d =3D a engine-cleanup, try it again but still the same error.

De: "Yedidyah Bar David" <didi(a= )red=3D hat.com>
Para: suporte(a)logicworks.pt
Cc: "ovirt us= er=3D s" <users(a)ovirt.org>
Enviadas: Quarta-feira, 28 De Fevere= ir=3D o de 2018 12:24:50
Assunto: Re: [ovirt-users] Backup & Restor= =3D e

On Wed, Feb 28, 2018 = at=3D 2:10 PM,  <suporte(a)logicworks.pt> wrote:
> Hi,
><= br=3D >> I'm testing backup & restore on Ovirt 4.2.
> I follow this = =3D doc
> https://www.ovirt.org/documentation/admin-guide/chap-Backups_an= =3D d_Migration/
> Try to restore to a fresh installation but always get = =3D this error message:
>
> restore-permissions
> Preparing t= =3D o restore:
> - Unpacking file 'back_file'
> Restoring:
> = =3D - Files
> Provisioning PostgreSQL users/databases:
> - user 'en= =3D gine', database 'engine'
> Restoring:
> FATAL: Can't connect to= =3D database 'ovirt_engine_history'. Please see
> '/usr/bin/engine-backu= =3D p --help'.
>
> On the live engine I run # engine-backup --scope= =3D =3D3Dall --mode=3D3Dbackup
> --file=3D3Dfile_name --log=3D3Dlog_file_= name
=3D >
> And try to restore on a fresh installation:
> # engine-b= =3D ackup --mode=3D3Drestore --file=3D3Dfile_name --log=3D3Dlog_file_name
&g= t; --p=3D rovision-db --restore-permissions
>
> Any Idea?

Please t= =3D ry adding to restore command '--providion-dwh-db'. Thanks.
--
Didi
------=3D_Part_20337673_1603009670.1519821904170-- --===============5854441623495726282== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzIwMzM3NjczXzE2MDMwMDk2NzAuMTUxOTgyMTkwNDE3MApDb250ZW50LVR5 cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKU3RpbGwgbm8gbHVjazogCgojIGVuZ2luZS1iYWNrdXAgLS1tb2RlPXJlc3RvcmUgLS1m aWxlPWJhY2tfZnV0dXIgLS1sb2c9bG9nX2Z1dHVyIC0tcHJvdmlzaW9uLWRiIC0tcmVzdG9yZS1w ZXJtaXNzaW9ucyAtLXByb3Zpc2lvbi1kd2gtZGIgClByZXBhcmluZyB0byByZXN0b3JlOiAKLSBV bnBhY2tpbmcgZmlsZSAnYmFja19mdXR1cicgClJlc3RvcmluZzogCi0gRmlsZXMgClByb3Zpc2lv bmluZyBQb3N0Z3JlU1FMIHVzZXJzL2RhdGFiYXNlczogCi0gdXNlciAnZW5naW5lJywgZGF0YWJh c2UgJ2VuZ2luZScgCi0gdXNlciAnb3ZpcnRfZW5naW5lX2hpc3RvcnknLCBkYXRhYmFzZSAnb3Zp cnRfZW5naW5lX2hpc3RvcnknIApSZXN0b3Jpbmc6IAotIEVuZ2luZSBkYXRhYmFzZSAnZW5naW5l JyAKRkFUQUw6IEVycm9ycyB3aGlsZSByZXN0b3JpbmcgZGF0YWJhc2UgZW5naW5lIAoKSSBkaWQg YSBlbmdpbmUtY2xlYW51cCwgdHJ5IGl0IGFnYWluIGJ1dCBzdGlsbCB0aGUgc2FtZSBlcnJvci4g CgoKRGU6ICJZZWRpZHlhaCBCYXIgRGF2aWQiIDxkaWRpQHJlZGhhdC5jb20+IApQYXJhOiBzdXBv cnRlQGxvZ2ljd29ya3MucHQgCkNjOiAib3ZpcnQgdXNlcnMiIDx1c2Vyc0BvdmlydC5vcmc+IApF bnZpYWRhczogUXVhcnRhLWZlaXJhLCAyOCBEZSBGZXZlcmVpcm8gZGUgMjAxOCAxMjoyNDo1MCAK QXNzdW50bzogUmU6IFtvdmlydC11c2Vyc10gQmFja3VwICYgUmVzdG9yZSAKCk9uIFdlZCwgRmVi IDI4LCAyMDE4IGF0IDI6MTAgUE0sIDxzdXBvcnRlQGxvZ2ljd29ya3MucHQ+IHdyb3RlOiAKPiBI aSwgCj4gCj4gSSdtIHRlc3RpbmcgYmFja3VwICYgcmVzdG9yZSBvbiBPdmlydCA0LjIuIAo+IEkg Zm9sbG93IHRoaXMgZG9jIAo+IGh0dHBzOi8vd3d3Lm92aXJ0Lm9yZy9kb2N1bWVudGF0aW9uL2Fk bWluLWd1aWRlL2NoYXAtQmFja3Vwc19hbmRfTWlncmF0aW9uLyAKPiBUcnkgdG8gcmVzdG9yZSB0 byBhIGZyZXNoIGluc3RhbGxhdGlvbiBidXQgYWx3YXlzIGdldCB0aGlzIGVycm9yIG1lc3NhZ2U6 IAo+IAo+IHJlc3RvcmUtcGVybWlzc2lvbnMgCj4gUHJlcGFyaW5nIHRvIHJlc3RvcmU6IAo+IC0g VW5wYWNraW5nIGZpbGUgJ2JhY2tfZmlsZScgCj4gUmVzdG9yaW5nOiAKPiAtIEZpbGVzIAo+IFBy b3Zpc2lvbmluZyBQb3N0Z3JlU1FMIHVzZXJzL2RhdGFiYXNlczogCj4gLSB1c2VyICdlbmdpbmUn LCBkYXRhYmFzZSAnZW5naW5lJyAKPiBSZXN0b3Jpbmc6IAo+IEZBVEFMOiBDYW4ndCBjb25uZWN0 IHRvIGRhdGFiYXNlICdvdmlydF9lbmdpbmVfaGlzdG9yeScuIFBsZWFzZSBzZWUgCj4gJy91c3Iv YmluL2VuZ2luZS1iYWNrdXAgLS1oZWxwJy4gCj4gCj4gT24gdGhlIGxpdmUgZW5naW5lIEkgcnVu ICMgZW5naW5lLWJhY2t1cCAtLXNjb3BlPWFsbCAtLW1vZGU9YmFja3VwIAo+IC0tZmlsZT1maWxl X25hbWUgLS1sb2c9bG9nX2ZpbGVfbmFtZSAKPiAKPiBBbmQgdHJ5IHRvIHJlc3RvcmUgb24gYSBm cmVzaCBpbnN0YWxsYXRpb246IAo+ICMgZW5naW5lLWJhY2t1cCAtLW1vZGU9cmVzdG9yZSAtLWZp bGU9ZmlsZV9uYW1lIC0tbG9nPWxvZ19maWxlX25hbWUgCj4gLS1wcm92aXNpb24tZGIgLS1yZXN0 b3JlLXBlcm1pc3Npb25zIAo+IAo+IEFueSBJZGVhPyAKClBsZWFzZSB0cnkgYWRkaW5nIHRvIHJl c3RvcmUgY29tbWFuZCAnLS1wcm92aWRpb24tZHdoLWRiJy4gVGhhbmtzLiAKLS0gCkRpZGkgCgot LS0tLS09X1BhcnRfMjAzMzc2NzNfMTYwMzAwOTY3MC4xNTE5ODIxOTA0MTcwCkNvbnRlbnQtVHlw ZTogdGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1 b3RlZC1wcmludGFibGUKCjxodG1sPjxib2R5PjxkaXYgc3R5bGU9M0QiZm9udC1mYW1pbHk6IHRy ZWJ1Y2hldCBtcyxzYW5zLXNlcmlmOyBmb250LXNpemU6ID0KMTJwdDsgY29sb3I6ICMwMDAwMDAi PjxkaXY+U3RpbGwgbm8gbHVjazo8YnI+PC9kaXY+PGRpdj48YnIgZGF0YS1tY2UtYm9ndXM9Cj0z RCIxIj48L2Rpdj48ZGl2PiMgZW5naW5lLWJhY2t1cCAtLW1vZGU9M0RyZXN0b3JlIC0tZmlsZT0z RGJhY2tfZnV0dXIgLS1sbz0KZz0zRGxvZ19mdXR1ciAtLXByb3Zpc2lvbi1kYiAtLXJlc3RvcmUt cGVybWlzc2lvbnMgLS1wcm92aXNpb24tZHdoLWRiPGJyPlByPQplcGFyaW5nIHRvIHJlc3RvcmU6 PGJyPi0gVW5wYWNraW5nIGZpbGUgJ2JhY2tfZnV0dXInPGJyPlJlc3RvcmluZzo8YnI+LSBGaWw9 CmVzPGJyPlByb3Zpc2lvbmluZyBQb3N0Z3JlU1FMIHVzZXJzL2RhdGFiYXNlczo8YnI+LSB1c2Vy ICdlbmdpbmUnLCBkYXRhYmFzZT0KICdlbmdpbmUnPGJyPi0gdXNlciAnb3ZpcnRfZW5naW5lX2hp c3RvcnknLCBkYXRhYmFzZSAnb3ZpcnRfZW5naW5lX2hpc3RvcnknPQo8YnI+UmVzdG9yaW5nOjxi cj4tIEVuZ2luZSBkYXRhYmFzZSAnZW5naW5lJzxicj5GQVRBTDogRXJyb3JzIHdoaWxlIHJlc3Rv cmk9Cm5nIGRhdGFiYXNlIGVuZ2luZTxicj48L2Rpdj48ZGl2PjxiciBkYXRhLW1jZS1ib2d1cz0z RCIxIj48L2Rpdj48ZGl2PkkgZGlkID0KYSBlbmdpbmUtY2xlYW51cCwgdHJ5IGl0IGFnYWluIGJ1 dCBzdGlsbCB0aGUgc2FtZSBlcnJvci48YnIgZGF0YS1tY2UtYm9ndXM9Cj0zRCIxIj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48aHIgaWQ9M0QiendjaHIiIGRhdGEtbWFya2VyPTNEIl9fRElWSURFUl9f Ij48ZD0KaXYgZGF0YS1tYXJrZXI9M0QiX19IRUFERVJTX18iPjxiPkRlOiA8L2I+IlllZGlkeWFo IEJhciBEYXZpZCIgJmx0O2RpZGlAcmVkPQpoYXQuY29tJmd0Ozxicj48Yj5QYXJhOiA8L2I+c3Vw b3J0ZUBsb2dpY3dvcmtzLnB0PGJyPjxiPkNjOiA8L2I+Im92aXJ0IHVzZXI9CnMiICZsdDt1c2Vy c0BvdmlydC5vcmcmZ3Q7PGJyPjxiPkVudmlhZGFzOiA8L2I+UXVhcnRhLWZlaXJhLCAyOCBEZSBG ZXZlcmVpcj0KbyBkZSAyMDE4IDEyOjI0OjUwPGJyPjxiPkFzc3VudG86IDwvYj5SZTogW292aXJ0 LXVzZXJzXSBCYWNrdXAgJmFtcDsgUmVzdG9yPQplPGJyPjwvZGl2Pjxicj48ZGl2IGRhdGEtbWFy a2VyPTNEIl9fUVVPVEVEX1RFWFRfXyI+T24gV2VkLCBGZWIgMjgsIDIwMTggYXQ9CiAyOjEwIFBN LCAmbmJzcDsmbHQ7c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0Jmd0OyB3cm90ZTo8YnI+Jmd0OyBIaSw8 YnI+Jmd0Ozxicj0KPiZndDsgSSdtIHRlc3RpbmcgYmFja3VwICZhbXA7IHJlc3RvcmUgb24gT3Zp cnQgNC4yLjxicj4mZ3Q7IEkgZm9sbG93IHRoaXMgPQpkb2M8YnI+Jmd0OyBodHRwczovL3d3dy5v dmlydC5vcmcvZG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9jaGFwLUJhY2t1cHNfYW49CmRfTWln cmF0aW9uLzxicj4mZ3Q7IFRyeSB0byByZXN0b3JlIHRvIGEgZnJlc2ggaW5zdGFsbGF0aW9uIGJ1 dCBhbHdheXMgZ2V0ID0KdGhpcyBlcnJvciBtZXNzYWdlOjxicj4mZ3Q7PGJyPiZndDsgcmVzdG9y ZS1wZXJtaXNzaW9uczxicj4mZ3Q7IFByZXBhcmluZyB0PQpvIHJlc3RvcmU6PGJyPiZndDsgLSBV bnBhY2tpbmcgZmlsZSAnYmFja19maWxlJzxicj4mZ3Q7IFJlc3RvcmluZzo8YnI+Jmd0OyA9Ci0g RmlsZXM8YnI+Jmd0OyBQcm92aXNpb25pbmcgUG9zdGdyZVNRTCB1c2Vycy9kYXRhYmFzZXM6PGJy PiZndDsgLSB1c2VyICdlbj0KZ2luZScsIGRhdGFiYXNlICdlbmdpbmUnPGJyPiZndDsgUmVzdG9y aW5nOjxicj4mZ3Q7IEZBVEFMOiBDYW4ndCBjb25uZWN0IHRvPQogZGF0YWJhc2UgJ292aXJ0X2Vu Z2luZV9oaXN0b3J5Jy4gUGxlYXNlIHNlZTxicj4mZ3Q7ICcvdXNyL2Jpbi9lbmdpbmUtYmFja3U9 CnAgLS1oZWxwJy48YnI+Jmd0Ozxicj4mZ3Q7IE9uIHRoZSBsaXZlIGVuZ2luZSBJIHJ1biAjIGVu Z2luZS1iYWNrdXAgLS1zY29wZT0KPTNEYWxsIC0tbW9kZT0zRGJhY2t1cDxicj4mZ3Q7IC0tZmls ZT0zRGZpbGVfbmFtZSAtLWxvZz0zRGxvZ19maWxlX25hbWU8YnI+PQomZ3Q7PGJyPiZndDsgQW5k IHRyeSB0byByZXN0b3JlIG9uIGEgZnJlc2ggaW5zdGFsbGF0aW9uOjxicj4mZ3Q7ICMgZW5naW5l LWI9CmFja3VwIC0tbW9kZT0zRHJlc3RvcmUgLS1maWxlPTNEZmlsZV9uYW1lIC0tbG9nPTNEbG9n X2ZpbGVfbmFtZTxicj4mZ3Q7IC0tcD0Kcm92aXNpb24tZGIgLS1yZXN0b3JlLXBlcm1pc3Npb25z PGJyPiZndDs8YnI+Jmd0OyBBbnkgSWRlYT88YnI+PGJyPlBsZWFzZSB0PQpyeSBhZGRpbmcgdG8g cmVzdG9yZSBjb21tYW5kICctLXByb3ZpZGlvbi1kd2gtZGInLiBUaGFua3MuPGJyPi0tIDxicj5E aWRpPGI9CnI+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4KLS0tLS0tPV9QYXJ0XzIwMzM3Njcz XzE2MDMwMDk2NzAuMTUxOTgyMTkwNDE3MC0tCg== --===============5854441623495726282==-- From suporte at logicworks.pt Wed Feb 28 14:44:47 2018 Content-Type: multipart/mixed; boundary="===============6883151370600243154==" MIME-Version: 1.0 From: suporte at logicworks.pt To: users at ovirt.org Subject: Re: [ovirt-users] Backup & Restore Date: Wed, 28 Feb 2018 14:44:39 +0000 Message-ID: <1229669542.20349654.1519829079176.JavaMail.zimbra@logicworks.pt> In-Reply-To: 1513265050.20337674.1519821904171.JavaMail.zimbra@logicworks.pt --===============6883151370600243154== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_20349653_1465707940.1519829079176 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit If I run = # engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur --pr= ovision-db --restore-permissions --provision-dwh-db --log=3D/root/rest-log = to create a log, I found these errors: = 2018-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovirt_engine_history -= h localhost -p 5432 ovirt_engine_history -t -c show lc_messages = 2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_engine_histor= y -h localhost -p 5432 ovirt_engine_history -s = 2018-02-28 14:36:31 6339: OUTPUT: - Engine database 'engine' = 2018-02-28 14:36:31 6339: Restoring engine database backup at /tmp/engine-b= ackup.VVkcNuYAkV/db/engine_backup.db = 2018-02-28 14:36:31 6339: restoreDB: backupfile /tmp/engine-backup.VVkcNuYA= kV/db/engine_backup.db user engine host localhost port 5432 database engine= orig_user compressor format custom jobsnum 2 = 2018-02-28 14:36:31 6339: pg_cmd running: pg_restore -w -U engine -h localh= ost -p 5432 -d engine -j 2 /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.d= b = pg_restore: [archiver (db)] Error while PROCESSING TOC: = pg_restore: [archiver (db)] Error from TOC entry 7314; 0 0 COMMENT EXTENSIO= N plpgsql = pg_restore: [archiver (db)] could not execute query: ERROR: must be owner o= f extension plpgsql = Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'= ; = pg_restore: [archiver (db)] Error from TOC entry 693; 1255 211334 FUNCTION = uuid_generate_v1() engine = pg_restore: [archiver (db)] could not execute query: ERROR: function "uuid_= generate_v1" already exists with same argument types = Command was: CREATE FUNCTION uuid_generate_v1() RETURNS uuid = LANGUAGE plpgsql STABLE = AS ' = DECLARE = v_val BIGINT; = v_4_1_par... = pg_restore: [archiver (db)] could not execute query: ERROR: must be owner o= f function uuid_generate_v1 = Command was: ALTER FUNCTION public.uuid_generate_v1() OWNER TO engine; = pg_restore: WARNING: column "user_role_title" has type "unknown" = DETAIL: Proceeding with relation creation anyway. = pg_restore: WARNING: no privileges could be revoked for "public" = pg_restore: WARNING: no privileges could be revoked for "public" = pg_restore: WARNING: no privileges were granted for "public" = pg_restore: WARNING: no privileges were granted for "public" = WARNING: errors ignored on restore: 3 = 2018-02-28 14:37:23 6339: FATAL: Errors while restoring database engine = De: suporte(a)logicworks.pt = Para: "Yedidyah Bar David" = Cc: "ovirt users" = Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:45:04 = Assunto: Re: [ovirt-users] Backup & Restore = Still no luck: = # engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur --pr= ovision-db --restore-permissions --provision-dwh-db = Preparing to restore: = - Unpacking file 'back_futur' = Restoring: = - Files = Provisioning PostgreSQL users/databases: = - user 'engine', database 'engine' = - user 'ovirt_engine_history', database 'ovirt_engine_history' = Restoring: = - Engine database 'engine' = FATAL: Errors while restoring database engine = I did a engine-cleanup, try it again but still the same error. = De: "Yedidyah Bar David" = Para: suporte(a)logicworks.pt = Cc: "ovirt users" = Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50 = Assunto: Re: [ovirt-users] Backup & Restore = On Wed, Feb 28, 2018 at 2:10 PM, wrote: = > Hi, = > = > I'm testing backup & restore on Ovirt 4.2. = > I follow this doc = > https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migratio= n/ = > Try to restore to a fresh installation but always get this error message: = > = > restore-permissions = > Preparing to restore: = > - Unpacking file 'back_file' = > Restoring: = > - Files = > Provisioning PostgreSQL users/databases: = > - user 'engine', database 'engine' = > Restoring: = > FATAL: Can't connect to database 'ovirt_engine_history'. Please see = > '/usr/bin/engine-backup --help'. = > = > On the live engine I run # engine-backup --scope=3Dall --mode=3Dbackup = > --file=3Dfile_name --log=3Dlog_file_name = > = > And try to restore on a fresh installation: = > # engine-backup --mode=3Drestore --file=3Dfile_name --log=3Dlog_file_name = > --provision-db --restore-permissions = > = > Any Idea? = Please try adding to restore command '--providion-dwh-db'. Thanks. = -- = Didi = _______________________________________________ = Users mailing list = Users(a)ovirt.org = http://lists.ovirt.org/mailman/listinfo/users = ------=3D_Part_20349653_1465707940.1519829079176 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable
If I run

# engine-backup --mode=3D3Drestore --file=3D3Dback_futur --log= =3D3Dlo=3D g_futur --provision-db --restore-permissions --provision-dwh-db --log=3D3D/= ro=3D ot/rest-log

to create a log= , =3D I found these errors:

2018-02-28 14:36:31 6339: pg_cmd running: psql -w -U ov= ir=3D t_engine_history -h localhost -p 5432 ovirt_engine_history -t -c show lc_me= =3D ssages
2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_eng= =3D ine_history -h localhost -p 5432 ovirt_engine_history -s
2018-02-28 14:3= =3D 6:31 6339: OUTPUT: - Engine database 'engine'
2018-02-28 14:36:31 6339: = =3D Restoring engine database backup at /tmp/engine-backup.VVkcNuYAkV/db/engine= =3D _backup.db
2018-02-28 14:36:31 6339: restoreDB: backupfile /tmp/engine-b= =3D ackup.VVkcNuYAkV/db/engine_backup.db user engine host localhost port 5432 d= =3D atabase engine orig_user compressor format custom jobsnum 2
2018-02-28 1= =3D 4:36:31 6339: pg_cmd running: pg_restore -w -U engine -h localhost -p 5432 = =3D -d engine -j 2 /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db
pg_rest= =3D ore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (= =3D db)] Error from TOC entry 7314; 0 0 COMMENT EXTENSION plpgsql
pg_restor= =3D e: [archiver (db)] could not execute query: ERROR: must be owner of extensi= =3D on plpgsql
Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL proce= =3D dural language';



pg_restore: [archiver (db)] Error from TOC = =3D entry 693; 1255 211334 FUNCTION uuid_generate_v1() engine
pg_restore: [a= =3D rchiver (db)] could not execute query: ERROR: function "uuid_generate_v1" a= =3D lready exists with same argument types
Command was: CREATE FUNCTION uui= =3D d_generate_v1() RETURNS uuid
LANGUAGE plpgsql STABLE
AS '
DECLAR= =3D E
v_val BIGINT;
v_4_1_par...
pg_restore: [archiver (db)] could n= =3D ot execute query: ERROR: must be owner of function uuid_generate_v1
Com= =3D mand was: ALTER FUNCTION public.uuid_generate_v1() OWNER TO engine;

= =3D
pg_restore: WARNING: column "user_role_title" has type "unknown"
DET= =3D AIL: Proceeding with relation creation anyway.
pg_restore: WARNING: no p= =3D rivileges could be revoked for "public"
pg_restore: WARNING: no privileg= =3D es could be revoked for "public"
pg_restore: WARNING: no privileges were= =3D granted for "public"
pg_restore: WARNING: no privileges were granted fo= =3D r "public"
WARNING: errors ignored on restore: 3
2018-02-28 14:37:23 = =3D 6339: FATAL: Errors while restoring database engine

De: suporte(a)logicworks.pt
Para: "Yedidyah Bar David"= &=3D lt;didi(a)redhat.com>
Cc: "ovirt users" <users(a)ovirt.org&= gt;<=3D br>Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:45:04
As= =3D sunto: Re: [ovirt-users] Backup & Restore

Still no luck:

# = =3D engine-backup --mode=3D3Drestore --file=3D3Dback_futur --log=3D3Dlog_futur = --prov=3D ision-db --restore-permissions --provision-dwh-db
Preparing to restore:<= =3D br>- Unpacking file 'back_futur'
Restoring:
- Files
Provisioning P= =3D ostgreSQL users/databases:
- user 'engine', database 'engine'
- user = =3D 'ovirt_engine_history', database 'ovirt_engine_history'
Restoring:
- = =3D Engine database 'engine'
FATAL: Errors while restoring database engine

I did a engine-cleanup, try it again but still the same er= =3D ror.

De: "Yedidyah Bar David" &= lt=3D ;didi(a)redhat.com>
Para: suporte(a)logicworks.pt
Cc: "o=3D virt users" <users(a)ovirt.org>
Enviadas: Quarta-feira, 28 = De=3D Fevereiro de 2018 12:24:50
Assunto: Re: [ovirt-users] Backup &am= =3D p; Restore

On Wed, Feb 28, 2018 at 2:10 PM,  <sup= =3D orte(a)logicworks.pt> wrote:
> Hi,
>
> I'm testing bac= ku=3D p & restore on Ovirt 4.2.
> I follow this doc
> https://www= =3D .ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/
> Tr= =3D y to restore to a fresh installation but always get this error message:
= =3D >
> restore-permissions
> Preparing to restore:
> - Un= =3D packing file 'back_file'
> Restoring:
> - Files
> Provisi= =3D oning PostgreSQL users/databases:
> - user 'engine', database 'engine= =3D '
> Restoring:
> FATAL: Can't connect to database 'ovirt_engine= =3D _history'. Please see
> '/usr/bin/engine-backup --help'.
>
&= =3D gt; On the live engine I run # engine-backup --scope=3D3Dall --mode=3D3Dbac= kup<=3D br>> --file=3D3Dfile_name --log=3D3Dlog_file_name
>
> And tr= y to=3D restore on a fresh installation:
> # engine-backup --mode=3D3Drestor= e =3D --file=3D3Dfile_name --log=3D3Dlog_file_name
> --provision-db --resto= re-p=3D ermissions
>
> Any Idea?

Please try adding to restore co= =3D mmand '--providion-dwh-db'. Thanks.
--
Didi

_____= =3D __________________________________________
Users mailing list
Users(a= )o=3D virt.org
http://lists.ovirt.org/mailman/listinfo/users
------=3D_Part_20349653_1465707940.1519829079176-- --===============6883151370600243154== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzIwMzQ5NjUzXzE0NjU3MDc5NDAuMTUxOTgyOTA3OTE3NgpDb250ZW50LVR5 cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSWYgSSBydW4gCgojIGVuZ2luZS1iYWNrdXAgLS1tb2RlPXJlc3RvcmUgLS1maWxlPWJh Y2tfZnV0dXIgLS1sb2c9bG9nX2Z1dHVyIC0tcHJvdmlzaW9uLWRiIC0tcmVzdG9yZS1wZXJtaXNz aW9ucyAtLXByb3Zpc2lvbi1kd2gtZGIgLS1sb2c9L3Jvb3QvcmVzdC1sb2cgCgp0byBjcmVhdGUg YSBsb2csIEkgZm91bmQgdGhlc2UgZXJyb3JzOiAKCjIwMTgtMDItMjggMTQ6MzY6MzEgNjMzOTog cGdfY21kIHJ1bm5pbmc6IHBzcWwgLXcgLVUgb3ZpcnRfZW5naW5lX2hpc3RvcnkgLWggbG9jYWxo b3N0IC1wIDU0MzIgb3ZpcnRfZW5naW5lX2hpc3RvcnkgLXQgLWMgc2hvdyBsY19tZXNzYWdlcyAK MjAxOC0wMi0yOCAxNDozNjozMSA2MzM5OiBwZ19jbWQgcnVubmluZzogcGdfZHVtcCAtdyAtVSBv dmlydF9lbmdpbmVfaGlzdG9yeSAtaCBsb2NhbGhvc3QgLXAgNTQzMiBvdmlydF9lbmdpbmVfaGlz dG9yeSAtcyAKMjAxOC0wMi0yOCAxNDozNjozMSA2MzM5OiBPVVRQVVQ6IC0gRW5naW5lIGRhdGFi YXNlICdlbmdpbmUnIAoyMDE4LTAyLTI4IDE0OjM2OjMxIDYzMzk6IFJlc3RvcmluZyBlbmdpbmUg ZGF0YWJhc2UgYmFja3VwIGF0IC90bXAvZW5naW5lLWJhY2t1cC5WVmtjTnVZQWtWL2RiL2VuZ2lu ZV9iYWNrdXAuZGIgCjIwMTgtMDItMjggMTQ6MzY6MzEgNjMzOTogcmVzdG9yZURCOiBiYWNrdXBm aWxlIC90bXAvZW5naW5lLWJhY2t1cC5WVmtjTnVZQWtWL2RiL2VuZ2luZV9iYWNrdXAuZGIgdXNl ciBlbmdpbmUgaG9zdCBsb2NhbGhvc3QgcG9ydCA1NDMyIGRhdGFiYXNlIGVuZ2luZSBvcmlnX3Vz ZXIgY29tcHJlc3NvciBmb3JtYXQgY3VzdG9tIGpvYnNudW0gMiAKMjAxOC0wMi0yOCAxNDozNjoz MSA2MzM5OiBwZ19jbWQgcnVubmluZzogcGdfcmVzdG9yZSAtdyAtVSBlbmdpbmUgLWggbG9jYWxo b3N0IC1wIDU0MzIgLWQgZW5naW5lIC1qIDIgL3RtcC9lbmdpbmUtYmFja3VwLlZWa2NOdVlBa1Yv ZGIvZW5naW5lX2JhY2t1cC5kYiAKcGdfcmVzdG9yZTogW2FyY2hpdmVyIChkYildIEVycm9yIHdo aWxlIFBST0NFU1NJTkcgVE9DOiAKcGdfcmVzdG9yZTogW2FyY2hpdmVyIChkYildIEVycm9yIGZy b20gVE9DIGVudHJ5IDczMTQ7IDAgMCBDT01NRU5UIEVYVEVOU0lPTiBwbHBnc3FsIApwZ19yZXN0 b3JlOiBbYXJjaGl2ZXIgKGRiKV0gY291bGQgbm90IGV4ZWN1dGUgcXVlcnk6IEVSUk9SOiBtdXN0 IGJlIG93bmVyIG9mIGV4dGVuc2lvbiBwbHBnc3FsIApDb21tYW5kIHdhczogQ09NTUVOVCBPTiBF WFRFTlNJT04gcGxwZ3NxbCBJUyAnUEwvcGdTUUwgcHJvY2VkdXJhbCBsYW5ndWFnZSc7IAoKCgpw Z19yZXN0b3JlOiBbYXJjaGl2ZXIgKGRiKV0gRXJyb3IgZnJvbSBUT0MgZW50cnkgNjkzOyAxMjU1 IDIxMTMzNCBGVU5DVElPTiB1dWlkX2dlbmVyYXRlX3YxKCkgZW5naW5lIApwZ19yZXN0b3JlOiBb YXJjaGl2ZXIgKGRiKV0gY291bGQgbm90IGV4ZWN1dGUgcXVlcnk6IEVSUk9SOiBmdW5jdGlvbiAi dXVpZF9nZW5lcmF0ZV92MSIgYWxyZWFkeSBleGlzdHMgd2l0aCBzYW1lIGFyZ3VtZW50IHR5cGVz IApDb21tYW5kIHdhczogQ1JFQVRFIEZVTkNUSU9OIHV1aWRfZ2VuZXJhdGVfdjEoKSBSRVRVUk5T IHV1aWQgCkxBTkdVQUdFIHBscGdzcWwgU1RBQkxFIApBUyAnIApERUNMQVJFIAp2X3ZhbCBCSUdJ TlQ7IAp2XzRfMV9wYXIuLi4gCnBnX3Jlc3RvcmU6IFthcmNoaXZlciAoZGIpXSBjb3VsZCBub3Qg ZXhlY3V0ZSBxdWVyeTogRVJST1I6IG11c3QgYmUgb3duZXIgb2YgZnVuY3Rpb24gdXVpZF9nZW5l cmF0ZV92MSAKQ29tbWFuZCB3YXM6IEFMVEVSIEZVTkNUSU9OIHB1YmxpYy51dWlkX2dlbmVyYXRl X3YxKCkgT1dORVIgVE8gZW5naW5lOyAKCgpwZ19yZXN0b3JlOiBXQVJOSU5HOiBjb2x1bW4gInVz ZXJfcm9sZV90aXRsZSIgaGFzIHR5cGUgInVua25vd24iIApERVRBSUw6IFByb2NlZWRpbmcgd2l0 aCByZWxhdGlvbiBjcmVhdGlvbiBhbnl3YXkuIApwZ19yZXN0b3JlOiBXQVJOSU5HOiBubyBwcml2 aWxlZ2VzIGNvdWxkIGJlIHJldm9rZWQgZm9yICJwdWJsaWMiIApwZ19yZXN0b3JlOiBXQVJOSU5H OiBubyBwcml2aWxlZ2VzIGNvdWxkIGJlIHJldm9rZWQgZm9yICJwdWJsaWMiIApwZ19yZXN0b3Jl OiBXQVJOSU5HOiBubyBwcml2aWxlZ2VzIHdlcmUgZ3JhbnRlZCBmb3IgInB1YmxpYyIgCnBnX3Jl c3RvcmU6IFdBUk5JTkc6IG5vIHByaXZpbGVnZXMgd2VyZSBncmFudGVkIGZvciAicHVibGljIiAK V0FSTklORzogZXJyb3JzIGlnbm9yZWQgb24gcmVzdG9yZTogMyAKMjAxOC0wMi0yOCAxNDozNzoy MyA2MzM5OiBGQVRBTDogRXJyb3JzIHdoaWxlIHJlc3RvcmluZyBkYXRhYmFzZSBlbmdpbmUgCgoK RGU6IHN1cG9ydGVAbG9naWN3b3Jrcy5wdCAKUGFyYTogIlllZGlkeWFoIEJhciBEYXZpZCIgPGRp ZGlAcmVkaGF0LmNvbT4gCkNjOiAib3ZpcnQgdXNlcnMiIDx1c2Vyc0BvdmlydC5vcmc+IApFbnZp YWRhczogUXVhcnRhLWZlaXJhLCAyOCBEZSBGZXZlcmVpcm8gZGUgMjAxOCAxMjo0NTowNCAKQXNz dW50bzogUmU6IFtvdmlydC11c2Vyc10gQmFja3VwICYgUmVzdG9yZSAKClN0aWxsIG5vIGx1Y2s6 IAoKIyBlbmdpbmUtYmFja3VwIC0tbW9kZT1yZXN0b3JlIC0tZmlsZT1iYWNrX2Z1dHVyIC0tbG9n PWxvZ19mdXR1ciAtLXByb3Zpc2lvbi1kYiAtLXJlc3RvcmUtcGVybWlzc2lvbnMgLS1wcm92aXNp b24tZHdoLWRiIApQcmVwYXJpbmcgdG8gcmVzdG9yZTogCi0gVW5wYWNraW5nIGZpbGUgJ2JhY2tf ZnV0dXInIApSZXN0b3Jpbmc6IAotIEZpbGVzIApQcm92aXNpb25pbmcgUG9zdGdyZVNRTCB1c2Vy cy9kYXRhYmFzZXM6IAotIHVzZXIgJ2VuZ2luZScsIGRhdGFiYXNlICdlbmdpbmUnIAotIHVzZXIg J292aXJ0X2VuZ2luZV9oaXN0b3J5JywgZGF0YWJhc2UgJ292aXJ0X2VuZ2luZV9oaXN0b3J5JyAK UmVzdG9yaW5nOiAKLSBFbmdpbmUgZGF0YWJhc2UgJ2VuZ2luZScgCkZBVEFMOiBFcnJvcnMgd2hp bGUgcmVzdG9yaW5nIGRhdGFiYXNlIGVuZ2luZSAKCkkgZGlkIGEgZW5naW5lLWNsZWFudXAsIHRy eSBpdCBhZ2FpbiBidXQgc3RpbGwgdGhlIHNhbWUgZXJyb3IuIAoKCkRlOiAiWWVkaWR5YWggQmFy IERhdmlkIiA8ZGlkaUByZWRoYXQuY29tPiAKUGFyYTogc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0IApD YzogIm92aXJ0IHVzZXJzIiA8dXNlcnNAb3ZpcnQub3JnPiAKRW52aWFkYXM6IFF1YXJ0YS1mZWly YSwgMjggRGUgRmV2ZXJlaXJvIGRlIDIwMTggMTI6MjQ6NTAgCkFzc3VudG86IFJlOiBbb3ZpcnQt dXNlcnNdIEJhY2t1cCAmIFJlc3RvcmUgCgpPbiBXZWQsIEZlYiAyOCwgMjAxOCBhdCAyOjEwIFBN LCA8c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PiB3cm90ZTogCj4gSGksIAo+IAo+IEknbSB0ZXN0aW5n IGJhY2t1cCAmIHJlc3RvcmUgb24gT3ZpcnQgNC4yLiAKPiBJIGZvbGxvdyB0aGlzIGRvYyAKPiBo dHRwczovL3d3dy5vdmlydC5vcmcvZG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9jaGFwLUJhY2t1 cHNfYW5kX01pZ3JhdGlvbi8gCj4gVHJ5IHRvIHJlc3RvcmUgdG8gYSBmcmVzaCBpbnN0YWxsYXRp b24gYnV0IGFsd2F5cyBnZXQgdGhpcyBlcnJvciBtZXNzYWdlOiAKPiAKPiByZXN0b3JlLXBlcm1p c3Npb25zIAo+IFByZXBhcmluZyB0byByZXN0b3JlOiAKPiAtIFVucGFja2luZyBmaWxlICdiYWNr X2ZpbGUnIAo+IFJlc3RvcmluZzogCj4gLSBGaWxlcyAKPiBQcm92aXNpb25pbmcgUG9zdGdyZVNR TCB1c2Vycy9kYXRhYmFzZXM6IAo+IC0gdXNlciAnZW5naW5lJywgZGF0YWJhc2UgJ2VuZ2luZScg Cj4gUmVzdG9yaW5nOiAKPiBGQVRBTDogQ2FuJ3QgY29ubmVjdCB0byBkYXRhYmFzZSAnb3ZpcnRf ZW5naW5lX2hpc3RvcnknLiBQbGVhc2Ugc2VlIAo+ICcvdXNyL2Jpbi9lbmdpbmUtYmFja3VwIC0t aGVscCcuIAo+IAo+IE9uIHRoZSBsaXZlIGVuZ2luZSBJIHJ1biAjIGVuZ2luZS1iYWNrdXAgLS1z Y29wZT1hbGwgLS1tb2RlPWJhY2t1cCAKPiAtLWZpbGU9ZmlsZV9uYW1lIC0tbG9nPWxvZ19maWxl X25hbWUgCj4gCj4gQW5kIHRyeSB0byByZXN0b3JlIG9uIGEgZnJlc2ggaW5zdGFsbGF0aW9uOiAK PiAjIGVuZ2luZS1iYWNrdXAgLS1tb2RlPXJlc3RvcmUgLS1maWxlPWZpbGVfbmFtZSAtLWxvZz1s b2dfZmlsZV9uYW1lIAo+IC0tcHJvdmlzaW9uLWRiIC0tcmVzdG9yZS1wZXJtaXNzaW9ucyAKPiAK PiBBbnkgSWRlYT8gCgpQbGVhc2UgdHJ5IGFkZGluZyB0byByZXN0b3JlIGNvbW1hbmQgJy0tcHJv dmlkaW9uLWR3aC1kYicuIFRoYW5rcy4gCi0tIApEaWRpIAoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gClVzZXJzIG1haWxpbmcgbGlzdCAKVXNlcnNAb3Zp cnQub3JnIApodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnMgCgot LS0tLS09X1BhcnRfMjAzNDk2NTNfMTQ2NTcwNzk0MC4xNTE5ODI5MDc5MTc2CkNvbnRlbnQtVHlw ZTogdGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1 b3RlZC1wcmludGFibGUKCjxodG1sPjxib2R5PjxkaXYgc3R5bGU9M0QiZm9udC1mYW1pbHk6IHRy ZWJ1Y2hldCBtcyxzYW5zLXNlcmlmOyBmb250LXNpemU6ID0KMTJwdDsgY29sb3I6ICMwMDAwMDAi PjxkaXY+SWYgSSBydW4gPGJyPjwvZGl2PjxkaXY+PGJyIGRhdGEtbWNlLWJvZ3VzPTNEIjEiPQo+ PC9kaXY+PGRpdj4jIGVuZ2luZS1iYWNrdXAgLS1tb2RlPTNEcmVzdG9yZSAtLWZpbGU9M0RiYWNr X2Z1dHVyIC0tbG9nPTNEbG89CmdfZnV0dXIgLS1wcm92aXNpb24tZGIgLS1yZXN0b3JlLXBlcm1p c3Npb25zIC0tcHJvdmlzaW9uLWR3aC1kYiAtLWxvZz0zRC9ybz0Kb3QvcmVzdC1sb2c8L2Rpdj48 ZGl2PjxiciBkYXRhLW1jZS1ib2d1cz0zRCIxIj48L2Rpdj48ZGl2PnRvIGNyZWF0ZSBhIGxvZywg PQpJIGZvdW5kIHRoZXNlIGVycm9yczo8YnIgZGF0YS1tY2UtYm9ndXM9M0QiMSI+PC9kaXY+PGRp dj48YnIgZGF0YS1tY2UtYm9ndXM9Cj0zRCIxIj48L2Rpdj48ZGl2PjIwMTgtMDItMjggMTQ6MzY6 MzEgNjMzOTogcGdfY21kIHJ1bm5pbmc6IHBzcWwgLXcgLVUgb3Zpcj0KdF9lbmdpbmVfaGlzdG9y eSAtaCBsb2NhbGhvc3QgLXAgNTQzMiBvdmlydF9lbmdpbmVfaGlzdG9yeSAtdCAtYyBzaG93IGxj X21lPQpzc2FnZXM8YnI+MjAxOC0wMi0yOCAxNDozNjozMSA2MzM5OiBwZ19jbWQgcnVubmluZzog cGdfZHVtcCAtdyAtVSBvdmlydF9lbmc9CmluZV9oaXN0b3J5IC1oIGxvY2FsaG9zdCAtcCA1NDMy IG92aXJ0X2VuZ2luZV9oaXN0b3J5IC1zPGJyPjIwMTgtMDItMjggMTQ6Mz0KNjozMSA2MzM5OiBP VVRQVVQ6IC0gRW5naW5lIGRhdGFiYXNlICdlbmdpbmUnPGJyPjIwMTgtMDItMjggMTQ6MzY6MzEg NjMzOTogPQpSZXN0b3JpbmcgZW5naW5lIGRhdGFiYXNlIGJhY2t1cCBhdCAvdG1wL2VuZ2luZS1i YWNrdXAuVlZrY051WUFrVi9kYi9lbmdpbmU9Cl9iYWNrdXAuZGI8YnI+MjAxOC0wMi0yOCAxNDoz NjozMSA2MzM5OiByZXN0b3JlREI6IGJhY2t1cGZpbGUgL3RtcC9lbmdpbmUtYj0KYWNrdXAuVlZr Y051WUFrVi9kYi9lbmdpbmVfYmFja3VwLmRiIHVzZXIgZW5naW5lIGhvc3QgbG9jYWxob3N0IHBv cnQgNTQzMiBkPQphdGFiYXNlIGVuZ2luZSBvcmlnX3VzZXIgY29tcHJlc3NvciBmb3JtYXQgY3Vz dG9tIGpvYnNudW0gMjxicj4yMDE4LTAyLTI4IDE9CjQ6MzY6MzEgNjMzOTogcGdfY21kIHJ1bm5p bmc6IHBnX3Jlc3RvcmUgLXcgLVUgZW5naW5lIC1oIGxvY2FsaG9zdCAtcCA1NDMyID0KLWQgZW5n aW5lIC1qIDIgL3RtcC9lbmdpbmUtYmFja3VwLlZWa2NOdVlBa1YvZGIvZW5naW5lX2JhY2t1cC5k Yjxicj5wZ19yZXN0PQpvcmU6IFthcmNoaXZlciAoZGIpXSBFcnJvciB3aGlsZSBQUk9DRVNTSU5H IFRPQzo8YnI+cGdfcmVzdG9yZTogW2FyY2hpdmVyICg9CmRiKV0gRXJyb3IgZnJvbSBUT0MgZW50 cnkgNzMxNDsgMCAwIENPTU1FTlQgRVhURU5TSU9OIHBscGdzcWwgPGJyPnBnX3Jlc3Rvcj0KZTog W2FyY2hpdmVyIChkYildIGNvdWxkIG5vdCBleGVjdXRlIHF1ZXJ5OiBFUlJPUjogbXVzdCBiZSBv d25lciBvZiBleHRlbnNpPQpvbiBwbHBnc3FsPGJyPiBDb21tYW5kIHdhczogQ09NTUVOVCBPTiBF WFRFTlNJT04gcGxwZ3NxbCBJUyAnUEwvcGdTUUwgcHJvY2U9CmR1cmFsIGxhbmd1YWdlJzs8YnI+ PGJyPjxicj48YnI+cGdfcmVzdG9yZTogW2FyY2hpdmVyIChkYildIEVycm9yIGZyb20gVE9DID0K ZW50cnkgNjkzOyAxMjU1IDIxMTMzNCBGVU5DVElPTiB1dWlkX2dlbmVyYXRlX3YxKCkgZW5naW5l PGJyPnBnX3Jlc3RvcmU6IFthPQpyY2hpdmVyIChkYildIGNvdWxkIG5vdCBleGVjdXRlIHF1ZXJ5 OiBFUlJPUjogZnVuY3Rpb24gInV1aWRfZ2VuZXJhdGVfdjEiIGE9CmxyZWFkeSBleGlzdHMgd2l0 aCBzYW1lIGFyZ3VtZW50IHR5cGVzPGJyPiBDb21tYW5kIHdhczogQ1JFQVRFIEZVTkNUSU9OIHV1 aT0KZF9nZW5lcmF0ZV92MSgpIFJFVFVSTlMgdXVpZDxicj4gTEFOR1VBR0UgcGxwZ3NxbCBTVEFC TEU8YnI+IEFTICc8YnI+REVDTEFSPQpFPGJyPiB2X3ZhbCBCSUdJTlQ7PGJyPiB2XzRfMV9wYXIu Li48YnI+cGdfcmVzdG9yZTogW2FyY2hpdmVyIChkYildIGNvdWxkIG49Cm90IGV4ZWN1dGUgcXVl cnk6IEVSUk9SOiBtdXN0IGJlIG93bmVyIG9mIGZ1bmN0aW9uIHV1aWRfZ2VuZXJhdGVfdjE8YnI+ IENvbT0KbWFuZCB3YXM6IEFMVEVSIEZVTkNUSU9OIHB1YmxpYy51dWlkX2dlbmVyYXRlX3YxKCkg T1dORVIgVE8gZW5naW5lOzxicj48YnI+PQo8YnI+cGdfcmVzdG9yZTogV0FSTklORzogY29sdW1u ICJ1c2VyX3JvbGVfdGl0bGUiIGhhcyB0eXBlICJ1bmtub3duIjxicj5ERVQ9CkFJTDogUHJvY2Vl ZGluZyB3aXRoIHJlbGF0aW9uIGNyZWF0aW9uIGFueXdheS48YnI+cGdfcmVzdG9yZTogV0FSTklO Rzogbm8gcD0Kcml2aWxlZ2VzIGNvdWxkIGJlIHJldm9rZWQgZm9yICJwdWJsaWMiPGJyPnBnX3Jl c3RvcmU6IFdBUk5JTkc6IG5vIHByaXZpbGVnPQplcyBjb3VsZCBiZSByZXZva2VkIGZvciAicHVi bGljIjxicj5wZ19yZXN0b3JlOiBXQVJOSU5HOiBubyBwcml2aWxlZ2VzIHdlcmU9CiBncmFudGVk IGZvciAicHVibGljIjxicj5wZ19yZXN0b3JlOiBXQVJOSU5HOiBubyBwcml2aWxlZ2VzIHdlcmUg Z3JhbnRlZCBmbz0KciAicHVibGljIjxicj5XQVJOSU5HOiBlcnJvcnMgaWdub3JlZCBvbiByZXN0 b3JlOiAzPGJyPjIwMTgtMDItMjggMTQ6Mzc6MjMgPQo2MzM5OiBGQVRBTDogRXJyb3JzIHdoaWxl IHJlc3RvcmluZyBkYXRhYmFzZSBlbmdpbmU8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY9Cj48aHIg aWQ9M0QiendjaHIiIGRhdGEtbWFya2VyPTNEIl9fRElWSURFUl9fIj48ZGl2IGRhdGEtbWFya2Vy PTNEIl9fSEVBREVSUz0KX18iPjxiPkRlOiA8L2I+c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PGJyPjxi PlBhcmE6IDwvYj4iWWVkaWR5YWggQmFyIERhdmlkIiAmPQpsdDtkaWRpQHJlZGhhdC5jb20mZ3Q7 PGJyPjxiPkNjOiA8L2I+Im92aXJ0IHVzZXJzIiAmbHQ7dXNlcnNAb3ZpcnQub3JnJmd0Ozw9CmJy PjxiPkVudmlhZGFzOiA8L2I+UXVhcnRhLWZlaXJhLCAyOCBEZSBGZXZlcmVpcm8gZGUgMjAxOCAx Mjo0NTowNDxicj48Yj5Bcz0Kc3VudG86IDwvYj5SZTogW292aXJ0LXVzZXJzXSBCYWNrdXAgJmFt cDsgUmVzdG9yZTxicj48L2Rpdj48YnI+PGRpdiBkYXRhLW1hPQpya2VyPTNEIl9fUVVPVEVEX1RF WFRfXyI+PGRpdiBzdHlsZT0zRCJmb250LWZhbWlseTogdHJlYnVjaGV0IG1zLHNhbnMtc2VyaWY9 CjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMCI+PGRpdj5TdGlsbCBubyBsdWNrOjxi cj48L2Rpdj48YnI+PGRpdj4jID0KZW5naW5lLWJhY2t1cCAtLW1vZGU9M0RyZXN0b3JlIC0tZmls ZT0zRGJhY2tfZnV0dXIgLS1sb2c9M0Rsb2dfZnV0dXIgLS1wcm92PQppc2lvbi1kYiAtLXJlc3Rv cmUtcGVybWlzc2lvbnMgLS1wcm92aXNpb24tZHdoLWRiPGJyPlByZXBhcmluZyB0byByZXN0b3Jl Ojw9CmJyPi0gVW5wYWNraW5nIGZpbGUgJ2JhY2tfZnV0dXInPGJyPlJlc3RvcmluZzo8YnI+LSBG aWxlczxicj5Qcm92aXNpb25pbmcgUD0Kb3N0Z3JlU1FMIHVzZXJzL2RhdGFiYXNlczo8YnI+LSB1 c2VyICdlbmdpbmUnLCBkYXRhYmFzZSAnZW5naW5lJzxicj4tIHVzZXIgPQonb3ZpcnRfZW5naW5l X2hpc3RvcnknLCBkYXRhYmFzZSAnb3ZpcnRfZW5naW5lX2hpc3RvcnknPGJyPlJlc3RvcmluZzo8 YnI+LSA9CkVuZ2luZSBkYXRhYmFzZSAnZW5naW5lJzxicj5GQVRBTDogRXJyb3JzIHdoaWxlIHJl c3RvcmluZyBkYXRhYmFzZSBlbmdpbmU8Yj0Kcj48L2Rpdj48YnI+PGRpdj5JIGRpZCBhIGVuZ2lu ZS1jbGVhbnVwLCB0cnkgaXQgYWdhaW4gYnV0IHN0aWxsIHRoZSBzYW1lIGVyPQpyb3IuPGJyPjwv ZGl2Pjxicj48aHIgaWQ9M0QiendjaHIiPjxkaXY+PGI+RGU6IDwvYj4iWWVkaWR5YWggQmFyIERh dmlkIiAmbHQ9CjtkaWRpQHJlZGhhdC5jb20mZ3Q7PGJyPjxiPlBhcmE6IDwvYj5zdXBvcnRlQGxv Z2ljd29ya3MucHQ8YnI+PGI+Q2M6IDwvYj4ibz0KdmlydCB1c2VycyIgJmx0O3VzZXJzQG92aXJ0 Lm9yZyZndDs8YnI+PGI+RW52aWFkYXM6IDwvYj5RdWFydGEtZmVpcmEsIDI4IERlPQogRmV2ZXJl aXJvIGRlIDIwMTggMTI6MjQ6NTA8YnI+PGI+QXNzdW50bzogPC9iPlJlOiBbb3ZpcnQtdXNlcnNd IEJhY2t1cCAmYW09CnA7IFJlc3RvcmU8YnI+PC9kaXY+PGJyPjxkaXY+T24gV2VkLCBGZWIgMjgs IDIwMTggYXQgMjoxMCBQTSwgJm5ic3A7Jmx0O3N1cD0Kb3J0ZUBsb2dpY3dvcmtzLnB0Jmd0OyB3 cm90ZTo8YnI+Jmd0OyBIaSw8YnI+Jmd0Ozxicj4mZ3Q7IEknbSB0ZXN0aW5nIGJhY2t1PQpwICZh bXA7IHJlc3RvcmUgb24gT3ZpcnQgNC4yLjxicj4mZ3Q7IEkgZm9sbG93IHRoaXMgZG9jPGJyPiZn dDsgaHR0cHM6Ly93d3c9Ci5vdmlydC5vcmcvZG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9jaGFw LUJhY2t1cHNfYW5kX01pZ3JhdGlvbi88YnI+Jmd0OyBUcj0KeSB0byByZXN0b3JlIHRvIGEgZnJl c2ggaW5zdGFsbGF0aW9uIGJ1dCBhbHdheXMgZ2V0IHRoaXMgZXJyb3IgbWVzc2FnZTo8YnI+PQom Z3Q7PGJyPiZndDsgcmVzdG9yZS1wZXJtaXNzaW9uczxicj4mZ3Q7IFByZXBhcmluZyB0byByZXN0 b3JlOjxicj4mZ3Q7IC0gVW49CnBhY2tpbmcgZmlsZSAnYmFja19maWxlJzxicj4mZ3Q7IFJlc3Rv cmluZzo8YnI+Jmd0OyAtIEZpbGVzPGJyPiZndDsgUHJvdmlzaT0Kb25pbmcgUG9zdGdyZVNRTCB1 c2Vycy9kYXRhYmFzZXM6PGJyPiZndDsgLSB1c2VyICdlbmdpbmUnLCBkYXRhYmFzZSAnZW5naW5l PQonPGJyPiZndDsgUmVzdG9yaW5nOjxicj4mZ3Q7IEZBVEFMOiBDYW4ndCBjb25uZWN0IHRvIGRh dGFiYXNlICdvdmlydF9lbmdpbmU9Cl9oaXN0b3J5Jy4gUGxlYXNlIHNlZTxicj4mZ3Q7ICcvdXNy L2Jpbi9lbmdpbmUtYmFja3VwIC0taGVscCcuPGJyPiZndDs8YnI+Jj0KZ3Q7IE9uIHRoZSBsaXZl IGVuZ2luZSBJIHJ1biAjIGVuZ2luZS1iYWNrdXAgLS1zY29wZT0zRGFsbCAtLW1vZGU9M0RiYWNr dXA8PQpicj4mZ3Q7IC0tZmlsZT0zRGZpbGVfbmFtZSAtLWxvZz0zRGxvZ19maWxlX25hbWU8YnI+ Jmd0Ozxicj4mZ3Q7IEFuZCB0cnkgdG89CiByZXN0b3JlIG9uIGEgZnJlc2ggaW5zdGFsbGF0aW9u Ojxicj4mZ3Q7ICMgZW5naW5lLWJhY2t1cCAtLW1vZGU9M0RyZXN0b3JlID0KLS1maWxlPTNEZmls ZV9uYW1lIC0tbG9nPTNEbG9nX2ZpbGVfbmFtZTxicj4mZ3Q7IC0tcHJvdmlzaW9uLWRiIC0tcmVz dG9yZS1wPQplcm1pc3Npb25zPGJyPiZndDs8YnI+Jmd0OyBBbnkgSWRlYT88YnI+PGJyPlBsZWFz ZSB0cnkgYWRkaW5nIHRvIHJlc3RvcmUgY289Cm1tYW5kICctLXByb3ZpZGlvbi1kd2gtZGInLiBU aGFua3MuPGJyPi0tIDxicj5EaWRpPGJyPjwvZGl2PjwvZGl2Pjxicj5fX19fXz0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPlVzZXJzIG1haWxpbmcgbGlzdDxi cj5Vc2Vyc0BvPQp2aXJ0Lm9yZzxicj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlz dGluZm8vdXNlcnM8YnI+PC9kaXY+PC9kaXY+PC89CmJvZHk+PC9odG1sPgotLS0tLS09X1BhcnRf MjAzNDk2NTNfMTQ2NTcwNzk0MC4xNTE5ODI5MDc5MTc2LS0K --===============6883151370600243154==-- From didi at redhat.com Thu Mar 1 07:28:16 2018 Content-Type: multipart/mixed; boundary="===============5666731851949014369==" MIME-Version: 1.0 From: Yedidyah Bar David To: users at ovirt.org Subject: Re: [ovirt-users] Backup & Restore Date: Thu, 01 Mar 2018 09:28:13 +0200 Message-ID: In-Reply-To: 1229669542.20349654.1519829079176.JavaMail.zimbra@logicworks.pt --===============5666731851949014369== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2018 at 4:44 PM, wrote: > If I run > > # engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur > --provision-db --restore-permissions --provision-dwh-db --log=3D/root/res= t-log > > to create a log, I found these errors: > > 2018-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovirt_engine_history= -h > localhost -p 5432 ovirt_engine_history -t -c show lc_messages > 2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_engine_hist= ory > -h localhost -p 5432 ovirt_engine_history -s > 2018-02-28 14:36:31 6339: OUTPUT: - Engine database 'engine' > 2018-02-28 14:36:31 6339: Restoring engine database backup at > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db > 2018-02-28 14:36:31 6339: restoreDB: backupfile > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db user engine host localh= ost > port 5432 database engine orig_user compressor format custom jobsnum 2 > 2018-02-28 14:36:31 6339: pg_cmd running: pg_restore -w -U engine -h > localhost -p 5432 -d engine -j 2 > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 7314; 0 0 COMMENT EXTENS= ION > plpgsql > pg_restore: [archiver (db)] could not execute query: ERROR: must be owner= of > extension plpgsql > Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural languag= e'; > > > > pg_restore: [archiver (db)] Error from TOC entry 693; 1255 211334 FUNCTION > uuid_generate_v1() engine > pg_restore: [archiver (db)] could not execute query: ERROR: function > "uuid_generate_v1" already exists with same argument types This is the error that fails you. I have a pending patch to make this more visible in the log [1], need to find time to verify it... Does this happen on a clean machine? Perhaps 'engine-cleanup' after such a failed restore is not enough. Please try reinstalling the OS and trying again. If it's not an important machine (test/dev/etc), this will probably be enough, as a faster replacement for a full OS reinstall: engine-cleanup systemctl stop postgresql systemctl stop rh-postgresql95-postgresql rm -rf /var/lib/pgsql/data /var/opt/rh/rh-postgresql95/lib/pgsql/data Then try restore again. [1] https://gerrit.ovirt.org/86395 > Command was: CREATE FUNCTION uuid_generate_v1() RETURNS uuid > LANGUAGE plpgsql STABLE > AS ' > DECLARE > v_val BIGINT; > v_4_1_par... > pg_restore: [archiver (db)] could not execute query: ERROR: must be owner= of > function uuid_generate_v1 > Command was: ALTER FUNCTION public.uuid_generate_v1() OWNER TO engine; Adding also Eli. Eli - perhaps we need to patch engine-backup to ignore also this error? I think the minimal flow to reproduce is: engine-setup engine-backup --mode=3Dbackup --file=3Df1 --log=3Dl1 engine-cleanup engine-backup --mode=3Drestore --file=3Df1 --provision-db --provision-dwh-db --log=3Dl2 Didn't try this myself. > > > pg_restore: WARNING: column "user_role_title" has type "unknown" > DETAIL: Proceeding with relation creation anyway. > pg_restore: WARNING: no privileges could be revoked for "public" > pg_restore: WARNING: no privileges could be revoked for "public" > pg_restore: WARNING: no privileges were granted for "public" > pg_restore: WARNING: no privileges were granted for "public" > WARNING: errors ignored on restore: 3 > 2018-02-28 14:37:23 6339: FATAL: Errors while restoring database engine > > ________________________________ > De: suporte(a)logicworks.pt > Para: "Yedidyah Bar David" > Cc: "ovirt users" > Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:45:04 > > Assunto: Re: [ovirt-users] Backup & Restore > > Still no luck: > > # engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur > --provision-db --restore-permissions --provision-dwh-db > Preparing to restore: > - Unpacking file 'back_futur' > Restoring: > - Files > Provisioning PostgreSQL users/databases: > - user 'engine', database 'engine' > - user 'ovirt_engine_history', database 'ovirt_engine_history' > Restoring: > - Engine database 'engine' > FATAL: Errors while restoring database engine > > I did a engine-cleanup, try it again but still the same error. > > ________________________________ > De: "Yedidyah Bar David" > Para: suporte(a)logicworks.pt > Cc: "ovirt users" > Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50 > Assunto: Re: [ovirt-users] Backup & Restore > > On Wed, Feb 28, 2018 at 2:10 PM, wrote: >> Hi, >> >> I'm testing backup & restore on Ovirt 4.2. >> I follow this doc >> >> https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migrati= on/ >> Try to restore to a fresh installation but always get this error message: >> >> restore-permissions >> Preparing to restore: >> - Unpacking file 'back_file' >> Restoring: >> - Files >> Provisioning PostgreSQL users/databases: >> - user 'engine', database 'engine' >> Restoring: >> FATAL: Can't connect to database 'ovirt_engine_history'. Please see >> '/usr/bin/engine-backup --help'. >> >> On the live engine I run # engine-backup --scope=3Dall --mode=3Dbackup >> --file=3Dfile_name --log=3Dlog_file_name >> >> And try to restore on a fresh installation: >> # engine-backup --mode=3Drestore --file=3Dfile_name --log=3Dlog_file_name >> --provision-db --restore-permissions >> >> Any Idea? > > Please try adding to restore command '--providion-dwh-db'. Thanks. > -- > Didi > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -- = Didi --===============5666731851949014369==-- From suporte at logicworks.pt Thu Mar 1 12:08:07 2018 Content-Type: multipart/mixed; boundary="===============2183825340960443521==" MIME-Version: 1.0 From: suporte at logicworks.pt To: users at ovirt.org Subject: Re: [ovirt-users] Backup & Restore Date: Thu, 01 Mar 2018 12:07:58 +0000 Message-ID: <1803853344.20566967.1519906078677.JavaMail.zimbra@logicworks.pt> In-Reply-To: CAHRwYXvAjWicB17=GCJgWMQBFLvued8Ayh9G1U2NKeKY9YFaNQ@mail.gmail.com --===============2183825340960443521== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_20566966_39555052.1519906078677 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit Yes, it happens in a clean machine. I try it twice and restore always fails= . = From: "Yedidyah Bar David" = To: suporte(a)logicworks.pt, "Eli Mesika" = Cc: "ovirt users" = Sent: Thursday, March 1, 2018 7:28:13 AM = Subject: Re: [ovirt-users] Backup & Restore = On Wed, Feb 28, 2018 at 4:44 PM, wrote: = > If I run = > = > # engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur = > --provision-db --restore-permissions --provision-dwh-db --log=3D/root/res= t-log = > = > to create a log, I found these errors: = > = > 2018-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovirt_engine_history= -h = > localhost -p 5432 ovirt_engine_history -t -c show lc_messages = > 2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_engine_hist= ory = > -h localhost -p 5432 ovirt_engine_history -s = > 2018-02-28 14:36:31 6339: OUTPUT: - Engine database 'engine' = > 2018-02-28 14:36:31 6339: Restoring engine database backup at = > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db = > 2018-02-28 14:36:31 6339: restoreDB: backupfile = > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db user engine host localh= ost = > port 5432 database engine orig_user compressor format custom jobsnum 2 = > 2018-02-28 14:36:31 6339: pg_cmd running: pg_restore -w -U engine -h = > localhost -p 5432 -d engine -j 2 = > /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db = > pg_restore: [archiver (db)] Error while PROCESSING TOC: = > pg_restore: [archiver (db)] Error from TOC entry 7314; 0 0 COMMENT EXTENS= ION = > plpgsql = > pg_restore: [archiver (db)] could not execute query: ERROR: must be owner= of = > extension plpgsql = > Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural languag= e'; = > = > = > = > pg_restore: [archiver (db)] Error from TOC entry 693; 1255 211334 FUNCTIO= N = > uuid_generate_v1() engine = > pg_restore: [archiver (db)] could not execute query: ERROR: function = > "uuid_generate_v1" already exists with same argument types = This is the error that fails you. I have a pending patch to make this more = visible in the log [1], need to find time to verify it... = Does this happen on a clean machine? Perhaps 'engine-cleanup' after such = a failed restore is not enough. Please try reinstalling the OS and trying = again. = If it's not an important machine (test/dev/etc), this will probably be = enough, as a faster replacement for a full OS reinstall: = engine-cleanup = systemctl stop postgresql = systemctl stop rh-postgresql95-postgresql = rm -rf /var/lib/pgsql/data /var/opt/rh/rh-postgresql95/lib/pgsql/data = Then try restore again. = [1] https://gerrit.ovirt.org/86395 = > Command was: CREATE FUNCTION uuid_generate_v1() RETURNS uuid = > LANGUAGE plpgsql STABLE = > AS ' = > DECLARE = > v_val BIGINT; = > v_4_1_par... = > pg_restore: [archiver (db)] could not execute query: ERROR: must be owner= of = > function uuid_generate_v1 = > Command was: ALTER FUNCTION public.uuid_generate_v1() OWNER TO engine; = Adding also Eli. Eli - perhaps we need to patch engine-backup to ignore = also this error? I think the minimal flow to reproduce is: = engine-setup = engine-backup --mode=3Dbackup --file=3Df1 --log=3Dl1 = engine-cleanup = engine-backup --mode=3Drestore --file=3Df1 --provision-db = --provision-dwh-db --log=3Dl2 = Didn't try this myself. = > = > = > pg_restore: WARNING: column "user_role_title" has type "unknown" = > DETAIL: Proceeding with relation creation anyway. = > pg_restore: WARNING: no privileges could be revoked for "public" = > pg_restore: WARNING: no privileges could be revoked for "public" = > pg_restore: WARNING: no privileges were granted for "public" = > pg_restore: WARNING: no privileges were granted for "public" = > WARNING: errors ignored on restore: 3 = > 2018-02-28 14:37:23 6339: FATAL: Errors while restoring database engine = > = > ________________________________ = > De: suporte(a)logicworks.pt = > Para: "Yedidyah Bar David" = > Cc: "ovirt users" = > Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:45:04 = > = > Assunto: Re: [ovirt-users] Backup & Restore = > = > Still no luck: = > = > # engine-backup --mode=3Drestore --file=3Dback_futur --log=3Dlog_futur = > --provision-db --restore-permissions --provision-dwh-db = > Preparing to restore: = > - Unpacking file 'back_futur' = > Restoring: = > - Files = > Provisioning PostgreSQL users/databases: = > - user 'engine', database 'engine' = > - user 'ovirt_engine_history', database 'ovirt_engine_history' = > Restoring: = > - Engine database 'engine' = > FATAL: Errors while restoring database engine = > = > I did a engine-cleanup, try it again but still the same error. = > = > ________________________________ = > De: "Yedidyah Bar David" = > Para: suporte(a)logicworks.pt = > Cc: "ovirt users" = > Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50 = > Assunto: Re: [ovirt-users] Backup & Restore = > = > On Wed, Feb 28, 2018 at 2:10 PM, wrote: = >> Hi, = >> = >> I'm testing backup & restore on Ovirt 4.2. = >> I follow this doc = >> = >> https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migrati= on/ = >> Try to restore to a fresh installation but always get this error message= : = >> = >> restore-permissions = >> Preparing to restore: = >> - Unpacking file 'back_file' = >> Restoring: = >> - Files = >> Provisioning PostgreSQL users/databases: = >> - user 'engine', database 'engine' = >> Restoring: = >> FATAL: Can't connect to database 'ovirt_engine_history'. Please see = >> '/usr/bin/engine-backup --help'. = >> = >> On the live engine I run # engine-backup --scope=3Dall --mode=3Dbackup = >> --file=3Dfile_name --log=3Dlog_file_name = >> = >> And try to restore on a fresh installation: = >> # engine-backup --mode=3Drestore --file=3Dfile_name --log=3Dlog_file_nam= e = >> --provision-db --restore-permissions = >> = >> Any Idea? = > = > Please try adding to restore command '--providion-dwh-db'. Thanks. = > -- = > Didi = > = > _______________________________________________ = > Users mailing list = > Users(a)ovirt.org = > http://lists.ovirt.org/mailman/listinfo/users = -- = Didi = ------=3D_Part_20566966_39555052.1519906078677 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable
Yes, it happens in a clean machine. I try it twi= =3D ce and restore always fails.

From: "Yedid= yah =3D Bar David" <didi(a)redhat.com>
To: suporte(a)logicworks.pt,= "El=3D i Mesika" <emesika(a)redhat.com>
Cc: "ovirt users" <user= s@=3D ovirt.org>
Sent: Thursday, March 1, 2018 7:28:13 AM
Subj= =3D ect: Re: [ovirt-users] Backup & Restore

On Wed, Feb 28, 2018 at 4:44 PM,  = &l=3D t;suporte(a)logicworks.pt> wrote:
> If I run
>
> # eng= in=3D e-backup --mode=3D3Drestore --file=3D3Dback_futur --log=3D3Dlog_futur
&g= t; --p=3D rovision-db --restore-permissions --provision-dwh-db --log=3D3D/root/rest-l= og=3D
>
> to create a log, I found these errors:
>
> 201= =3D 8-02-28 14:36:31 6339: pg_cmd running: psql -w -U ovirt_engine_history -h> localhost -p 5432 ovirt_engine_history -t -c show lc_messages
>= =3D ; 2018-02-28 14:36:31 6339: pg_cmd running: pg_dump -w -U ovirt_engine_hist= =3D ory
> -h localhost -p 5432 ovirt_engine_history -s
> 2018-02-28= =3D 14:36:31 6339: OUTPUT: - Engine database 'engine'
> 2018-02-28 14:36= =3D :31 6339: Restoring engine database backup at
> /tmp/engine-backup.VV= =3D kcNuYAkV/db/engine_backup.db
> 2018-02-28 14:36:31 6339: restoreDB: b= =3D ackupfile
> /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db user en= =3D gine host localhost
> port 5432 database engine orig_user compressor = =3D format custom jobsnum 2
> 2018-02-28 14:36:31 6339: pg_cmd running: p= =3D g_restore -w -U engine -h
> localhost -p 5432 -d engine -j 2
> = =3D /tmp/engine-backup.VVkcNuYAkV/db/engine_backup.db
> pg_restore: [arch= =3D iver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] = =3D Error from TOC entry 7314; 0 0 COMMENT EXTENSION
> plpgsql
> pg= =3D _restore: [archiver (db)] could not execute query: ERROR: must be owner of<= =3D br>> extension plpgsql
> Command was: COMMENT ON EXTENSION plpgsql= =3D IS 'PL/pgSQL procedural language';
>
>
>
> pg_rest= =3D ore: [archiver (db)] Error from TOC entry 693; 1255 211334 FUNCTION
>= =3D uuid_generate_v1() engine
> pg_restore: [archiver (db)] could not ex= =3D ecute query: ERROR: function
> "uuid_generate_v1" already exists with= =3D same argument types

This is the error that fails you. I have a pend= =3D ing patch to make this more
visible in the log [1], need to find time to= =3D verify it...

Does this happen on a clean machine? Perhaps 'engine-c= =3D leanup' after such
a failed restore is not enough. Please try reinstalli= =3D ng the OS and trying
again.

If it's not an important machine (tes= =3D t/dev/etc), this will probably be
enough, as a faster replacement for a = =3D full OS reinstall:

engine-cleanup
systemctl stop postgresql
sy= =3D stemctl stop rh-postgresql95-postgresql
rm -rf /var/lib/pgsql/data /var/= =3D opt/rh/rh-postgresql95/lib/pgsql/data

Then try restore again.
[1] https://gerrit.ovirt.org/86395

> Command was: CREATE FUNCTIO= =3D N uuid_generate_v1() RETURNS uuid
> LANGUAGE plpgsql STABLE
> A= =3D S '
> DECLARE
> v_val BIGINT;
> v_4_1_par...
> pg_r= =3D estore: [archiver (db)] could not execute query: ERROR: must be owner of> function uuid_generate_v1
> Command was: ALTER FUNCTION public.= =3D uuid_generate_v1() OWNER TO engine;

Adding also Eli. Eli - perhaps w= =3D e need to patch engine-backup to ignore
also this error? I think the min= =3D imal flow to reproduce is:

engine-setup
engine-backup --mode=3D3D= ba=3D ckup --file=3D3Df1 --log=3D3Dl1
engine-cleanup
engine-backup --mode= =3D3Dres=3D tore --file=3D3Df1 --provision-db
--provision-dwh-db --log=3D3Dl2
Did=3D n't try this myself.

>
>
> pg_restore: WARNING: colum= =3D n "user_role_title" has type "unknown"
> DETAIL: Proceeding with rela= =3D tion creation anyway.
> pg_restore: WARNING: no privileges could be r= =3D evoked for "public"
> pg_restore: WARNING: no privileges could be rev= =3D oked for "public"
> pg_restore: WARNING: no privileges were granted f= =3D or "public"
> pg_restore: WARNING: no privileges were granted for "pu= =3D blic"
> WARNING: errors ignored on restore: 3
> 2018-02-28 14:3= =3D 7:23 6339: FATAL: Errors while restoring database engine
>
> __= =3D ______________________________
> De: suporte(a)logicworks.pt
> = Pa=3D ra: "Yedidyah Bar David" <didi(a)redhat.com>
> Cc: "ovirt users= " =3D <users(a)ovirt.org>
> Enviadas: Quarta-feira, 28 De Fevereiro d= e =3D 2018 12:45:04
>
> Assunto: Re: [ovirt-users] Backup & Resto= =3D re
>
> Still no luck:
>
> # engine-backup --mode=3D= 3D=3D restore --file=3D3Dback_futur --log=3D3Dlog_futur
> --provision-db --= rest=3D ore-permissions --provision-dwh-db
> Preparing to restore:
> - = =3D Unpacking file 'back_futur'
> Restoring:
> - Files
> Prov= =3D isioning PostgreSQL users/databases:
> - user 'engine', database 'eng= =3D ine'
> - user 'ovirt_engine_history', database 'ovirt_engine_history'= =3D
> Restoring:
> - Engine database 'engine'
> FATAL: Error= =3D s while restoring database engine
>
> I did a engine-cleanup, t= =3D ry it again but still the same error.
>
> _____________________= =3D ___________
> De: "Yedidyah Bar David" <didi(a)redhat.com>
&= gt=3D ; Para: suporte(a)logicworks.pt
> Cc: "ovirt users" <users(a)ovirt= .org=3D >
> Enviadas: Quarta-feira, 28 De Fevereiro de 2018 12:24:50
&g= =3D t; Assunto: Re: [ovirt-users] Backup & Restore
>
> On Wed, = =3D Feb 28, 2018 at 2:10 PM,  <suporte(a)logicworks.pt> wrote:
&g= t;=3D > Hi,
>>
>> I'm testing backup & restore on Ovirt = =3D 4.2.
>> I follow this doc
>>
>> https://www.ovir= =3D t.org/documentation/admin-guide/chap-Backups_and_Migration/
>> Try= =3D to restore to a fresh installation but always get this error message:
&= =3D gt;>
>> restore-permissions
>> Preparing to restore:>> - Unpacking file 'back_file'
>> Restoring:
>> = =3D - Files
>> Provisioning PostgreSQL users/databases:
>> - = =3D user 'engine', database 'engine'
>> Restoring:
>> FATAL: = =3D Can't connect to database 'ovirt_engine_history'. Please see
>> '/= =3D usr/bin/engine-backup --help'.
>>
>> On the live engine I= =3D run # engine-backup --scope=3D3Dall --mode=3D3Dbackup
>> --file= =3D3Dfil=3D e_name --log=3D3Dlog_file_name
>>
>> And try to restore o= n =3D a fresh installation:
>> # engine-backup --mode=3D3Drestore --file= =3D =3D3Dfile_name --log=3D3Dlog_file_name
>> --provision-db --restore= -per=3D missions
>>
>> Any Idea?
>
> Please try addin= =3D g to restore command '--providion-dwh-db'. Thanks.
> --
> Didi<= =3D br>>
> _______________________________________________
> Use= =3D rs mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/ma= il=3D man/listinfo/users



--
Didi
------=3D_Part_20566966_39555052.1519906078677-- --===============2183825340960443521== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzIwNTY2OTY2XzM5NTU1MDUyLjE1MTk5MDYwNzg2NzcKQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdi aXQKClllcywgaXQgaGFwcGVucyBpbiBhIGNsZWFuIG1hY2hpbmUuIEkgdHJ5IGl0IHR3aWNlIGFu ZCByZXN0b3JlIGFsd2F5cyBmYWlscy4gCgoKRnJvbTogIlllZGlkeWFoIEJhciBEYXZpZCIgPGRp ZGlAcmVkaGF0LmNvbT4gClRvOiBzdXBvcnRlQGxvZ2ljd29ya3MucHQsICJFbGkgTWVzaWthIiA8 ZW1lc2lrYUByZWRoYXQuY29tPiAKQ2M6ICJvdmlydCB1c2VycyIgPHVzZXJzQG92aXJ0Lm9yZz4g ClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxLCAyMDE4IDc6Mjg6MTMgQU0gClN1YmplY3Q6IFJlOiBb b3ZpcnQtdXNlcnNdIEJhY2t1cCAmIFJlc3RvcmUgCgpPbiBXZWQsIEZlYiAyOCwgMjAxOCBhdCA0 OjQ0IFBNLCA8c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0PiB3cm90ZTogCj4gSWYgSSBydW4gCj4gCj4g IyBlbmdpbmUtYmFja3VwIC0tbW9kZT1yZXN0b3JlIC0tZmlsZT1iYWNrX2Z1dHVyIC0tbG9nPWxv Z19mdXR1ciAKPiAtLXByb3Zpc2lvbi1kYiAtLXJlc3RvcmUtcGVybWlzc2lvbnMgLS1wcm92aXNp b24tZHdoLWRiIC0tbG9nPS9yb290L3Jlc3QtbG9nIAo+IAo+IHRvIGNyZWF0ZSBhIGxvZywgSSBm b3VuZCB0aGVzZSBlcnJvcnM6IAo+IAo+IDIwMTgtMDItMjggMTQ6MzY6MzEgNjMzOTogcGdfY21k IHJ1bm5pbmc6IHBzcWwgLXcgLVUgb3ZpcnRfZW5naW5lX2hpc3RvcnkgLWggCj4gbG9jYWxob3N0 IC1wIDU0MzIgb3ZpcnRfZW5naW5lX2hpc3RvcnkgLXQgLWMgc2hvdyBsY19tZXNzYWdlcyAKPiAy MDE4LTAyLTI4IDE0OjM2OjMxIDYzMzk6IHBnX2NtZCBydW5uaW5nOiBwZ19kdW1wIC13IC1VIG92 aXJ0X2VuZ2luZV9oaXN0b3J5IAo+IC1oIGxvY2FsaG9zdCAtcCA1NDMyIG92aXJ0X2VuZ2luZV9o aXN0b3J5IC1zIAo+IDIwMTgtMDItMjggMTQ6MzY6MzEgNjMzOTogT1VUUFVUOiAtIEVuZ2luZSBk YXRhYmFzZSAnZW5naW5lJyAKPiAyMDE4LTAyLTI4IDE0OjM2OjMxIDYzMzk6IFJlc3RvcmluZyBl bmdpbmUgZGF0YWJhc2UgYmFja3VwIGF0IAo+IC90bXAvZW5naW5lLWJhY2t1cC5WVmtjTnVZQWtW L2RiL2VuZ2luZV9iYWNrdXAuZGIgCj4gMjAxOC0wMi0yOCAxNDozNjozMSA2MzM5OiByZXN0b3Jl REI6IGJhY2t1cGZpbGUgCj4gL3RtcC9lbmdpbmUtYmFja3VwLlZWa2NOdVlBa1YvZGIvZW5naW5l X2JhY2t1cC5kYiB1c2VyIGVuZ2luZSBob3N0IGxvY2FsaG9zdCAKPiBwb3J0IDU0MzIgZGF0YWJh c2UgZW5naW5lIG9yaWdfdXNlciBjb21wcmVzc29yIGZvcm1hdCBjdXN0b20gam9ic251bSAyIAo+ IDIwMTgtMDItMjggMTQ6MzY6MzEgNjMzOTogcGdfY21kIHJ1bm5pbmc6IHBnX3Jlc3RvcmUgLXcg LVUgZW5naW5lIC1oIAo+IGxvY2FsaG9zdCAtcCA1NDMyIC1kIGVuZ2luZSAtaiAyIAo+IC90bXAv ZW5naW5lLWJhY2t1cC5WVmtjTnVZQWtWL2RiL2VuZ2luZV9iYWNrdXAuZGIgCj4gcGdfcmVzdG9y ZTogW2FyY2hpdmVyIChkYildIEVycm9yIHdoaWxlIFBST0NFU1NJTkcgVE9DOiAKPiBwZ19yZXN0 b3JlOiBbYXJjaGl2ZXIgKGRiKV0gRXJyb3IgZnJvbSBUT0MgZW50cnkgNzMxNDsgMCAwIENPTU1F TlQgRVhURU5TSU9OIAo+IHBscGdzcWwgCj4gcGdfcmVzdG9yZTogW2FyY2hpdmVyIChkYildIGNv dWxkIG5vdCBleGVjdXRlIHF1ZXJ5OiBFUlJPUjogbXVzdCBiZSBvd25lciBvZiAKPiBleHRlbnNp b24gcGxwZ3NxbCAKPiBDb21tYW5kIHdhczogQ09NTUVOVCBPTiBFWFRFTlNJT04gcGxwZ3NxbCBJ UyAnUEwvcGdTUUwgcHJvY2VkdXJhbCBsYW5ndWFnZSc7IAo+IAo+IAo+IAo+IHBnX3Jlc3RvcmU6 IFthcmNoaXZlciAoZGIpXSBFcnJvciBmcm9tIFRPQyBlbnRyeSA2OTM7IDEyNTUgMjExMzM0IEZV TkNUSU9OIAo+IHV1aWRfZ2VuZXJhdGVfdjEoKSBlbmdpbmUgCj4gcGdfcmVzdG9yZTogW2FyY2hp dmVyIChkYildIGNvdWxkIG5vdCBleGVjdXRlIHF1ZXJ5OiBFUlJPUjogZnVuY3Rpb24gCj4gInV1 aWRfZ2VuZXJhdGVfdjEiIGFscmVhZHkgZXhpc3RzIHdpdGggc2FtZSBhcmd1bWVudCB0eXBlcyAK ClRoaXMgaXMgdGhlIGVycm9yIHRoYXQgZmFpbHMgeW91LiBJIGhhdmUgYSBwZW5kaW5nIHBhdGNo IHRvIG1ha2UgdGhpcyBtb3JlIAp2aXNpYmxlIGluIHRoZSBsb2cgWzFdLCBuZWVkIHRvIGZpbmQg dGltZSB0byB2ZXJpZnkgaXQuLi4gCgpEb2VzIHRoaXMgaGFwcGVuIG9uIGEgY2xlYW4gbWFjaGlu ZT8gUGVyaGFwcyAnZW5naW5lLWNsZWFudXAnIGFmdGVyIHN1Y2ggCmEgZmFpbGVkIHJlc3RvcmUg aXMgbm90IGVub3VnaC4gUGxlYXNlIHRyeSByZWluc3RhbGxpbmcgdGhlIE9TIGFuZCB0cnlpbmcg CmFnYWluLiAKCklmIGl0J3Mgbm90IGFuIGltcG9ydGFudCBtYWNoaW5lICh0ZXN0L2Rldi9ldGMp LCB0aGlzIHdpbGwgcHJvYmFibHkgYmUgCmVub3VnaCwgYXMgYSBmYXN0ZXIgcmVwbGFjZW1lbnQg Zm9yIGEgZnVsbCBPUyByZWluc3RhbGw6IAoKZW5naW5lLWNsZWFudXAgCnN5c3RlbWN0bCBzdG9w IHBvc3RncmVzcWwgCnN5c3RlbWN0bCBzdG9wIHJoLXBvc3RncmVzcWw5NS1wb3N0Z3Jlc3FsIApy bSAtcmYgL3Zhci9saWIvcGdzcWwvZGF0YSAvdmFyL29wdC9yaC9yaC1wb3N0Z3Jlc3FsOTUvbGli L3Bnc3FsL2RhdGEgCgpUaGVuIHRyeSByZXN0b3JlIGFnYWluLiAKClsxXSBodHRwczovL2dlcnJp dC5vdmlydC5vcmcvODYzOTUgCgo+IENvbW1hbmQgd2FzOiBDUkVBVEUgRlVOQ1RJT04gdXVpZF9n ZW5lcmF0ZV92MSgpIFJFVFVSTlMgdXVpZCAKPiBMQU5HVUFHRSBwbHBnc3FsIFNUQUJMRSAKPiBB UyAnIAo+IERFQ0xBUkUgCj4gdl92YWwgQklHSU5UOyAKPiB2XzRfMV9wYXIuLi4gCj4gcGdfcmVz dG9yZTogW2FyY2hpdmVyIChkYildIGNvdWxkIG5vdCBleGVjdXRlIHF1ZXJ5OiBFUlJPUjogbXVz dCBiZSBvd25lciBvZiAKPiBmdW5jdGlvbiB1dWlkX2dlbmVyYXRlX3YxIAo+IENvbW1hbmQgd2Fz OiBBTFRFUiBGVU5DVElPTiBwdWJsaWMudXVpZF9nZW5lcmF0ZV92MSgpIE9XTkVSIFRPIGVuZ2lu ZTsgCgpBZGRpbmcgYWxzbyBFbGkuIEVsaSAtIHBlcmhhcHMgd2UgbmVlZCB0byBwYXRjaCBlbmdp bmUtYmFja3VwIHRvIGlnbm9yZSAKYWxzbyB0aGlzIGVycm9yPyBJIHRoaW5rIHRoZSBtaW5pbWFs IGZsb3cgdG8gcmVwcm9kdWNlIGlzOiAKCmVuZ2luZS1zZXR1cCAKZW5naW5lLWJhY2t1cCAtLW1v ZGU9YmFja3VwIC0tZmlsZT1mMSAtLWxvZz1sMSAKZW5naW5lLWNsZWFudXAgCmVuZ2luZS1iYWNr dXAgLS1tb2RlPXJlc3RvcmUgLS1maWxlPWYxIC0tcHJvdmlzaW9uLWRiIAotLXByb3Zpc2lvbi1k d2gtZGIgLS1sb2c9bDIgCgpEaWRuJ3QgdHJ5IHRoaXMgbXlzZWxmLiAKCj4gCj4gCj4gcGdfcmVz dG9yZTogV0FSTklORzogY29sdW1uICJ1c2VyX3JvbGVfdGl0bGUiIGhhcyB0eXBlICJ1bmtub3du IiAKPiBERVRBSUw6IFByb2NlZWRpbmcgd2l0aCByZWxhdGlvbiBjcmVhdGlvbiBhbnl3YXkuIAo+ IHBnX3Jlc3RvcmU6IFdBUk5JTkc6IG5vIHByaXZpbGVnZXMgY291bGQgYmUgcmV2b2tlZCBmb3Ig InB1YmxpYyIgCj4gcGdfcmVzdG9yZTogV0FSTklORzogbm8gcHJpdmlsZWdlcyBjb3VsZCBiZSBy ZXZva2VkIGZvciAicHVibGljIiAKPiBwZ19yZXN0b3JlOiBXQVJOSU5HOiBubyBwcml2aWxlZ2Vz IHdlcmUgZ3JhbnRlZCBmb3IgInB1YmxpYyIgCj4gcGdfcmVzdG9yZTogV0FSTklORzogbm8gcHJp dmlsZWdlcyB3ZXJlIGdyYW50ZWQgZm9yICJwdWJsaWMiIAo+IFdBUk5JTkc6IGVycm9ycyBpZ25v cmVkIG9uIHJlc3RvcmU6IDMgCj4gMjAxOC0wMi0yOCAxNDozNzoyMyA2MzM5OiBGQVRBTDogRXJy b3JzIHdoaWxlIHJlc3RvcmluZyBkYXRhYmFzZSBlbmdpbmUgCj4gCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gCj4gRGU6IHN1cG9ydGVAbG9naWN3b3Jrcy5wdCAKPiBQYXJhOiAi WWVkaWR5YWggQmFyIERhdmlkIiA8ZGlkaUByZWRoYXQuY29tPiAKPiBDYzogIm92aXJ0IHVzZXJz IiA8dXNlcnNAb3ZpcnQub3JnPiAKPiBFbnZpYWRhczogUXVhcnRhLWZlaXJhLCAyOCBEZSBGZXZl cmVpcm8gZGUgMjAxOCAxMjo0NTowNCAKPiAKPiBBc3N1bnRvOiBSZTogW292aXJ0LXVzZXJzXSBC YWNrdXAgJiBSZXN0b3JlIAo+IAo+IFN0aWxsIG5vIGx1Y2s6IAo+IAo+ICMgZW5naW5lLWJhY2t1 cCAtLW1vZGU9cmVzdG9yZSAtLWZpbGU9YmFja19mdXR1ciAtLWxvZz1sb2dfZnV0dXIgCj4gLS1w cm92aXNpb24tZGIgLS1yZXN0b3JlLXBlcm1pc3Npb25zIC0tcHJvdmlzaW9uLWR3aC1kYiAKPiBQ cmVwYXJpbmcgdG8gcmVzdG9yZTogCj4gLSBVbnBhY2tpbmcgZmlsZSAnYmFja19mdXR1cicgCj4g UmVzdG9yaW5nOiAKPiAtIEZpbGVzIAo+IFByb3Zpc2lvbmluZyBQb3N0Z3JlU1FMIHVzZXJzL2Rh dGFiYXNlczogCj4gLSB1c2VyICdlbmdpbmUnLCBkYXRhYmFzZSAnZW5naW5lJyAKPiAtIHVzZXIg J292aXJ0X2VuZ2luZV9oaXN0b3J5JywgZGF0YWJhc2UgJ292aXJ0X2VuZ2luZV9oaXN0b3J5JyAK PiBSZXN0b3Jpbmc6IAo+IC0gRW5naW5lIGRhdGFiYXNlICdlbmdpbmUnIAo+IEZBVEFMOiBFcnJv cnMgd2hpbGUgcmVzdG9yaW5nIGRhdGFiYXNlIGVuZ2luZSAKPiAKPiBJIGRpZCBhIGVuZ2luZS1j bGVhbnVwLCB0cnkgaXQgYWdhaW4gYnV0IHN0aWxsIHRoZSBzYW1lIGVycm9yLiAKPiAKPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyAKPiBEZTogIlllZGlkeWFoIEJhciBEYXZpZCIg PGRpZGlAcmVkaGF0LmNvbT4gCj4gUGFyYTogc3Vwb3J0ZUBsb2dpY3dvcmtzLnB0IAo+IENjOiAi b3ZpcnQgdXNlcnMiIDx1c2Vyc0BvdmlydC5vcmc+IAo+IEVudmlhZGFzOiBRdWFydGEtZmVpcmEs IDI4IERlIEZldmVyZWlybyBkZSAyMDE4IDEyOjI0OjUwIAo+IEFzc3VudG86IFJlOiBbb3ZpcnQt dXNlcnNdIEJhY2t1cCAmIFJlc3RvcmUgCj4gCj4gT24gV2VkLCBGZWIgMjgsIDIwMTggYXQgMjox MCBQTSwgPHN1cG9ydGVAbG9naWN3b3Jrcy5wdD4gd3JvdGU6IAo+PiBIaSwgCj4+IAo+PiBJJ20g dGVzdGluZyBiYWNrdXAgJiByZXN0b3JlIG9uIE92aXJ0IDQuMi4gCj4+IEkgZm9sbG93IHRoaXMg ZG9jIAo+PiAKPj4gaHR0cHM6Ly93d3cub3ZpcnQub3JnL2RvY3VtZW50YXRpb24vYWRtaW4tZ3Vp ZGUvY2hhcC1CYWNrdXBzX2FuZF9NaWdyYXRpb24vIAo+PiBUcnkgdG8gcmVzdG9yZSB0byBhIGZy ZXNoIGluc3RhbGxhdGlvbiBidXQgYWx3YXlzIGdldCB0aGlzIGVycm9yIG1lc3NhZ2U6IAo+PiAK Pj4gcmVzdG9yZS1wZXJtaXNzaW9ucyAKPj4gUHJlcGFyaW5nIHRvIHJlc3RvcmU6IAo+PiAtIFVu cGFja2luZyBmaWxlICdiYWNrX2ZpbGUnIAo+PiBSZXN0b3Jpbmc6IAo+PiAtIEZpbGVzIAo+PiBQ cm92aXNpb25pbmcgUG9zdGdyZVNRTCB1c2Vycy9kYXRhYmFzZXM6IAo+PiAtIHVzZXIgJ2VuZ2lu ZScsIGRhdGFiYXNlICdlbmdpbmUnIAo+PiBSZXN0b3Jpbmc6IAo+PiBGQVRBTDogQ2FuJ3QgY29u bmVjdCB0byBkYXRhYmFzZSAnb3ZpcnRfZW5naW5lX2hpc3RvcnknLiBQbGVhc2Ugc2VlIAo+PiAn L3Vzci9iaW4vZW5naW5lLWJhY2t1cCAtLWhlbHAnLiAKPj4gCj4+IE9uIHRoZSBsaXZlIGVuZ2lu ZSBJIHJ1biAjIGVuZ2luZS1iYWNrdXAgLS1zY29wZT1hbGwgLS1tb2RlPWJhY2t1cCAKPj4gLS1m aWxlPWZpbGVfbmFtZSAtLWxvZz1sb2dfZmlsZV9uYW1lIAo+PiAKPj4gQW5kIHRyeSB0byByZXN0 b3JlIG9uIGEgZnJlc2ggaW5zdGFsbGF0aW9uOiAKPj4gIyBlbmdpbmUtYmFja3VwIC0tbW9kZT1y ZXN0b3JlIC0tZmlsZT1maWxlX25hbWUgLS1sb2c9bG9nX2ZpbGVfbmFtZSAKPj4gLS1wcm92aXNp b24tZGIgLS1yZXN0b3JlLXBlcm1pc3Npb25zIAo+PiAKPj4gQW55IElkZWE/IAo+IAo+IFBsZWFz ZSB0cnkgYWRkaW5nIHRvIHJlc3RvcmUgY29tbWFuZCAnLS1wcm92aWRpb24tZHdoLWRiJy4gVGhh bmtzLiAKPiAtLSAKPiBEaWRpIAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIAo+IFVzZXJzIG1haWxpbmcgbGlzdCAKPiBVc2Vyc0BvdmlydC5vcmcg Cj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzIAoKCgotLSAK RGlkaSAKCi0tLS0tLT1fUGFydF8yMDU2Njk2Nl8zOTU1NTA1Mi4xNTE5OTA2MDc4Njc3CkNvbnRl bnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rp bmc6IHF1b3RlZC1wcmludGFibGUKCjxodG1sPjxib2R5PjxkaXYgc3R5bGU9M0QiZm9udC1mYW1p bHk6IHRyZWJ1Y2hldCBtcyxzYW5zLXNlcmlmOyBmb250LXNpemU6ID0KMTJwdDsgY29sb3I6ICMw MDAwMDAiPjxkaXY+WWVzLCBpdCBoYXBwZW5zIGluIGEgY2xlYW4gbWFjaGluZS4gSSB0cnkgaXQg dHdpPQpjZSBhbmQgcmVzdG9yZSBhbHdheXMgZmFpbHMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGhy IGlkPTNEInp3Y2hyIiBkYXRhLW1hcms9CmVyPTNEIl9fRElWSURFUl9fIj48ZGl2IGRhdGEtbWFy a2VyPTNEIl9fSEVBREVSU19fIj48Yj5Gcm9tOiA8L2I+IlllZGlkeWFoID0KQmFyIERhdmlkIiAm bHQ7ZGlkaUByZWRoYXQuY29tJmd0Ozxicj48Yj5UbzogPC9iPnN1cG9ydGVAbG9naWN3b3Jrcy5w dCwgIkVsPQppIE1lc2lrYSIgJmx0O2VtZXNpa2FAcmVkaGF0LmNvbSZndDs8YnI+PGI+Q2M6IDwv Yj4ib3ZpcnQgdXNlcnMiICZsdDt1c2Vyc0A9Cm92aXJ0Lm9yZyZndDs8YnI+PGI+U2VudDogPC9i PlRodXJzZGF5LCBNYXJjaCAxLCAyMDE4IDc6Mjg6MTMgQU08YnI+PGI+U3Viaj0KZWN0OiA8L2I+ UmU6IFtvdmlydC11c2Vyc10gQmFja3VwICZhbXA7IFJlc3RvcmU8YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpPQp2IGRhdGEtbWFya2VyPTNEIl9fUVVPVEVEX1RFWFRfXyI+T24gV2VkLCBGZWIg MjgsIDIwMTggYXQgNDo0NCBQTSwgJm5ic3A7Jmw9CnQ7c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0Jmd0 OyB3cm90ZTo8YnI+Jmd0OyBJZiBJIHJ1bjxicj4mZ3Q7PGJyPiZndDsgIyBlbmdpbj0KZS1iYWNr dXAgLS1tb2RlPTNEcmVzdG9yZSAtLWZpbGU9M0RiYWNrX2Z1dHVyIC0tbG9nPTNEbG9nX2Z1dHVy PGJyPiZndDsgLS1wPQpyb3Zpc2lvbi1kYiAtLXJlc3RvcmUtcGVybWlzc2lvbnMgLS1wcm92aXNp b24tZHdoLWRiIC0tbG9nPTNEL3Jvb3QvcmVzdC1sb2c9Cjxicj4mZ3Q7PGJyPiZndDsgdG8gY3Jl YXRlIGEgbG9nLCBJIGZvdW5kIHRoZXNlIGVycm9yczo8YnI+Jmd0Ozxicj4mZ3Q7IDIwMT0KOC0w Mi0yOCAxNDozNjozMSA2MzM5OiBwZ19jbWQgcnVubmluZzogcHNxbCAtdyAtVSBvdmlydF9lbmdp bmVfaGlzdG9yeSAtaDxiPQpyPiZndDsgbG9jYWxob3N0IC1wIDU0MzIgb3ZpcnRfZW5naW5lX2hp c3RvcnkgLXQgLWMgc2hvdyBsY19tZXNzYWdlczxicj4mZ3Q9CjsgMjAxOC0wMi0yOCAxNDozNjoz MSA2MzM5OiBwZ19jbWQgcnVubmluZzogcGdfZHVtcCAtdyAtVSBvdmlydF9lbmdpbmVfaGlzdD0K b3J5PGJyPiZndDsgLWggbG9jYWxob3N0IC1wIDU0MzIgb3ZpcnRfZW5naW5lX2hpc3RvcnkgLXM8 YnI+Jmd0OyAyMDE4LTAyLTI4PQogMTQ6MzY6MzEgNjMzOTogT1VUUFVUOiAtIEVuZ2luZSBkYXRh YmFzZSAnZW5naW5lJzxicj4mZ3Q7IDIwMTgtMDItMjggMTQ6MzY9CjozMSA2MzM5OiBSZXN0b3Jp bmcgZW5naW5lIGRhdGFiYXNlIGJhY2t1cCBhdDxicj4mZ3Q7IC90bXAvZW5naW5lLWJhY2t1cC5W Vj0Ka2NOdVlBa1YvZGIvZW5naW5lX2JhY2t1cC5kYjxicj4mZ3Q7IDIwMTgtMDItMjggMTQ6MzY6 MzEgNjMzOTogcmVzdG9yZURCOiBiPQphY2t1cGZpbGU8YnI+Jmd0OyAvdG1wL2VuZ2luZS1iYWNr dXAuVlZrY051WUFrVi9kYi9lbmdpbmVfYmFja3VwLmRiIHVzZXIgZW49CmdpbmUgaG9zdCBsb2Nh bGhvc3Q8YnI+Jmd0OyBwb3J0IDU0MzIgZGF0YWJhc2UgZW5naW5lIG9yaWdfdXNlciBjb21wcmVz c29yID0KZm9ybWF0IGN1c3RvbSBqb2JzbnVtIDI8YnI+Jmd0OyAyMDE4LTAyLTI4IDE0OjM2OjMx IDYzMzk6IHBnX2NtZCBydW5uaW5nOiBwPQpnX3Jlc3RvcmUgLXcgLVUgZW5naW5lIC1oPGJyPiZn dDsgbG9jYWxob3N0IC1wIDU0MzIgLWQgZW5naW5lIC1qIDI8YnI+Jmd0OyA9Ci90bXAvZW5naW5l LWJhY2t1cC5WVmtjTnVZQWtWL2RiL2VuZ2luZV9iYWNrdXAuZGI8YnI+Jmd0OyBwZ19yZXN0b3Jl OiBbYXJjaD0KaXZlciAoZGIpXSBFcnJvciB3aGlsZSBQUk9DRVNTSU5HIFRPQzo8YnI+Jmd0OyBw Z19yZXN0b3JlOiBbYXJjaGl2ZXIgKGRiKV0gPQpFcnJvciBmcm9tIFRPQyBlbnRyeSA3MzE0OyAw IDAgQ09NTUVOVCBFWFRFTlNJT048YnI+Jmd0OyBwbHBnc3FsPGJyPiZndDsgcGc9Cl9yZXN0b3Jl OiBbYXJjaGl2ZXIgKGRiKV0gY291bGQgbm90IGV4ZWN1dGUgcXVlcnk6IEVSUk9SOiBtdXN0IGJl IG93bmVyIG9mPD0KYnI+Jmd0OyBleHRlbnNpb24gcGxwZ3NxbDxicj4mZ3Q7IENvbW1hbmQgd2Fz OiBDT01NRU5UIE9OIEVYVEVOU0lPTiBwbHBnc3FsPQogSVMgJ1BML3BnU1FMIHByb2NlZHVyYWwg bGFuZ3VhZ2UnOzxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IHBnX3Jlc3Q9Cm9yZTog W2FyY2hpdmVyIChkYildIEVycm9yIGZyb20gVE9DIGVudHJ5IDY5MzsgMTI1NSAyMTEzMzQgRlVO Q1RJT048YnI+Jmd0Oz0KIHV1aWRfZ2VuZXJhdGVfdjEoKSBlbmdpbmU8YnI+Jmd0OyBwZ19yZXN0 b3JlOiBbYXJjaGl2ZXIgKGRiKV0gY291bGQgbm90IGV4PQplY3V0ZSBxdWVyeTogRVJST1I6IGZ1 bmN0aW9uPGJyPiZndDsgInV1aWRfZ2VuZXJhdGVfdjEiIGFscmVhZHkgZXhpc3RzIHdpdGg9CiBz YW1lIGFyZ3VtZW50IHR5cGVzPGJyPjxicj5UaGlzIGlzIHRoZSBlcnJvciB0aGF0IGZhaWxzIHlv dS4gSSBoYXZlIGEgcGVuZD0KaW5nIHBhdGNoIHRvIG1ha2UgdGhpcyBtb3JlPGJyPnZpc2libGUg aW4gdGhlIGxvZyBbMV0sIG5lZWQgdG8gZmluZCB0aW1lIHRvPQogdmVyaWZ5IGl0Li4uPGJyPjxi cj5Eb2VzIHRoaXMgaGFwcGVuIG9uIGEgY2xlYW4gbWFjaGluZT8gUGVyaGFwcyAnZW5naW5lLWM9 CmxlYW51cCcgYWZ0ZXIgc3VjaDxicj5hIGZhaWxlZCByZXN0b3JlIGlzIG5vdCBlbm91Z2guIFBs ZWFzZSB0cnkgcmVpbnN0YWxsaT0KbmcgdGhlIE9TIGFuZCB0cnlpbmc8YnI+YWdhaW4uPGJyPjxi cj5JZiBpdCdzIG5vdCBhbiBpbXBvcnRhbnQgbWFjaGluZSAodGVzPQp0L2Rldi9ldGMpLCB0aGlz IHdpbGwgcHJvYmFibHkgYmU8YnI+ZW5vdWdoLCBhcyBhIGZhc3RlciByZXBsYWNlbWVudCBmb3Ig YSA9CmZ1bGwgT1MgcmVpbnN0YWxsOjxicj48YnI+ZW5naW5lLWNsZWFudXA8YnI+c3lzdGVtY3Rs IHN0b3AgcG9zdGdyZXNxbDxicj5zeT0Kc3RlbWN0bCBzdG9wIHJoLXBvc3RncmVzcWw5NS1wb3N0 Z3Jlc3FsPGJyPnJtIC1yZiAvdmFyL2xpYi9wZ3NxbC9kYXRhIC92YXIvPQpvcHQvcmgvcmgtcG9z dGdyZXNxbDk1L2xpYi9wZ3NxbC9kYXRhPGJyPjxicj5UaGVuIHRyeSByZXN0b3JlIGFnYWluLjxi cj48YnI9Cj5bMV0gaHR0cHM6Ly9nZXJyaXQub3ZpcnQub3JnLzg2Mzk1PGJyPjxicj4mZ3Q7IENv bW1hbmQgd2FzOiBDUkVBVEUgRlVOQ1RJTz0KTiB1dWlkX2dlbmVyYXRlX3YxKCkgUkVUVVJOUyB1 dWlkPGJyPiZndDsgTEFOR1VBR0UgcGxwZ3NxbCBTVEFCTEU8YnI+Jmd0OyBBPQpTICc8YnI+Jmd0 OyBERUNMQVJFPGJyPiZndDsgdl92YWwgQklHSU5UOzxicj4mZ3Q7IHZfNF8xX3Bhci4uLjxicj4m Z3Q7IHBnX3I9CmVzdG9yZTogW2FyY2hpdmVyIChkYildIGNvdWxkIG5vdCBleGVjdXRlIHF1ZXJ5 OiBFUlJPUjogbXVzdCBiZSBvd25lciBvZjxicj0KPiZndDsgZnVuY3Rpb24gdXVpZF9nZW5lcmF0 ZV92MTxicj4mZ3Q7IENvbW1hbmQgd2FzOiBBTFRFUiBGVU5DVElPTiBwdWJsaWMuPQp1dWlkX2dl bmVyYXRlX3YxKCkgT1dORVIgVE8gZW5naW5lOzxicj48YnI+QWRkaW5nIGFsc28gRWxpLiBFbGkg LSBwZXJoYXBzIHc9CmUgbmVlZCB0byBwYXRjaCBlbmdpbmUtYmFja3VwIHRvIGlnbm9yZTxicj5h bHNvIHRoaXMgZXJyb3I/IEkgdGhpbmsgdGhlIG1pbj0KaW1hbCBmbG93IHRvIHJlcHJvZHVjZSBp czo8YnI+PGJyPmVuZ2luZS1zZXR1cDxicj5lbmdpbmUtYmFja3VwIC0tbW9kZT0zRGJhPQpja3Vw IC0tZmlsZT0zRGYxIC0tbG9nPTNEbDE8YnI+ZW5naW5lLWNsZWFudXA8YnI+ZW5naW5lLWJhY2t1 cCAtLW1vZGU9M0RyZXM9CnRvcmUgLS1maWxlPTNEZjEgLS1wcm92aXNpb24tZGI8YnI+LS1wcm92 aXNpb24tZHdoLWRiIC0tbG9nPTNEbDI8YnI+PGJyPkRpZD0Kbid0IHRyeSB0aGlzIG15c2VsZi48 YnI+PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IHBnX3Jlc3RvcmU6IFdBUk5JTkc6IGNvbHVtPQpu ICJ1c2VyX3JvbGVfdGl0bGUiIGhhcyB0eXBlICJ1bmtub3duIjxicj4mZ3Q7IERFVEFJTDogUHJv Y2VlZGluZyB3aXRoIHJlbGE9CnRpb24gY3JlYXRpb24gYW55d2F5Ljxicj4mZ3Q7IHBnX3Jlc3Rv cmU6IFdBUk5JTkc6IG5vIHByaXZpbGVnZXMgY291bGQgYmUgcj0KZXZva2VkIGZvciAicHVibGlj Ijxicj4mZ3Q7IHBnX3Jlc3RvcmU6IFdBUk5JTkc6IG5vIHByaXZpbGVnZXMgY291bGQgYmUgcmV2 PQpva2VkIGZvciAicHVibGljIjxicj4mZ3Q7IHBnX3Jlc3RvcmU6IFdBUk5JTkc6IG5vIHByaXZp bGVnZXMgd2VyZSBncmFudGVkIGY9Cm9yICJwdWJsaWMiPGJyPiZndDsgcGdfcmVzdG9yZTogV0FS TklORzogbm8gcHJpdmlsZWdlcyB3ZXJlIGdyYW50ZWQgZm9yICJwdT0KYmxpYyI8YnI+Jmd0OyBX QVJOSU5HOiBlcnJvcnMgaWdub3JlZCBvbiByZXN0b3JlOiAzPGJyPiZndDsgMjAxOC0wMi0yOCAx NDozPQo3OjIzIDYzMzk6IEZBVEFMOiBFcnJvcnMgd2hpbGUgcmVzdG9yaW5nIGRhdGFiYXNlIGVu Z2luZTxicj4mZ3Q7PGJyPiZndDsgX189Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4mZ3Q7IERlOiBzdXBvcnRlQGxvZ2ljd29ya3MucHQ8YnI+Jmd0OyBQYT0KcmE6ICJZZWRpZHlh aCBCYXIgRGF2aWQiICZsdDtkaWRpQHJlZGhhdC5jb20mZ3Q7PGJyPiZndDsgQ2M6ICJvdmlydCB1 c2VycyIgPQombHQ7dXNlcnNAb3ZpcnQub3JnJmd0Ozxicj4mZ3Q7IEVudmlhZGFzOiBRdWFydGEt ZmVpcmEsIDI4IERlIEZldmVyZWlybyBkZSA9CjIwMTggMTI6NDU6MDQ8YnI+Jmd0Ozxicj4mZ3Q7 IEFzc3VudG86IFJlOiBbb3ZpcnQtdXNlcnNdIEJhY2t1cCAmYW1wOyBSZXN0bz0KcmU8YnI+Jmd0 Ozxicj4mZ3Q7IFN0aWxsIG5vIGx1Y2s6PGJyPiZndDs8YnI+Jmd0OyAjIGVuZ2luZS1iYWNrdXAg LS1tb2RlPTNEPQpyZXN0b3JlIC0tZmlsZT0zRGJhY2tfZnV0dXIgLS1sb2c9M0Rsb2dfZnV0dXI8 YnI+Jmd0OyAtLXByb3Zpc2lvbi1kYiAtLXJlc3Q9Cm9yZS1wZXJtaXNzaW9ucyAtLXByb3Zpc2lv bi1kd2gtZGI8YnI+Jmd0OyBQcmVwYXJpbmcgdG8gcmVzdG9yZTo8YnI+Jmd0OyAtID0KVW5wYWNr aW5nIGZpbGUgJ2JhY2tfZnV0dXInPGJyPiZndDsgUmVzdG9yaW5nOjxicj4mZ3Q7IC0gRmlsZXM8 YnI+Jmd0OyBQcm92PQppc2lvbmluZyBQb3N0Z3JlU1FMIHVzZXJzL2RhdGFiYXNlczo8YnI+Jmd0 OyAtIHVzZXIgJ2VuZ2luZScsIGRhdGFiYXNlICdlbmc9CmluZSc8YnI+Jmd0OyAtIHVzZXIgJ292 aXJ0X2VuZ2luZV9oaXN0b3J5JywgZGF0YWJhc2UgJ292aXJ0X2VuZ2luZV9oaXN0b3J5Jz0KPGJy PiZndDsgUmVzdG9yaW5nOjxicj4mZ3Q7IC0gRW5naW5lIGRhdGFiYXNlICdlbmdpbmUnPGJyPiZn dDsgRkFUQUw6IEVycm9yPQpzIHdoaWxlIHJlc3RvcmluZyBkYXRhYmFzZSBlbmdpbmU8YnI+Jmd0 Ozxicj4mZ3Q7IEkgZGlkIGEgZW5naW5lLWNsZWFudXAsIHQ9CnJ5IGl0IGFnYWluIGJ1dCBzdGls bCB0aGUgc2FtZSBlcnJvci48YnI+Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fXz0K X19fX19fX19fX188YnI+Jmd0OyBEZTogIlllZGlkeWFoIEJhciBEYXZpZCIgJmx0O2RpZGlAcmVk aGF0LmNvbSZndDs8YnI+Jmd0PQo7IFBhcmE6IHN1cG9ydGVAbG9naWN3b3Jrcy5wdDxicj4mZ3Q7 IENjOiAib3ZpcnQgdXNlcnMiICZsdDt1c2Vyc0BvdmlydC5vcmc9CiZndDs8YnI+Jmd0OyBFbnZp YWRhczogUXVhcnRhLWZlaXJhLCAyOCBEZSBGZXZlcmVpcm8gZGUgMjAxOCAxMjoyNDo1MDxicj4m Zz0KdDsgQXNzdW50bzogUmU6IFtvdmlydC11c2Vyc10gQmFja3VwICZhbXA7IFJlc3RvcmU8YnI+ Jmd0Ozxicj4mZ3Q7IE9uIFdlZCwgPQpGZWIgMjgsIDIwMTggYXQgMjoxMCBQTSwgJm5ic3A7Jmx0 O3N1cG9ydGVAbG9naWN3b3Jrcy5wdCZndDsgd3JvdGU6PGJyPiZndDs9CiZndDsgSGksPGJyPiZn dDsmZ3Q7PGJyPiZndDsmZ3Q7IEknbSB0ZXN0aW5nIGJhY2t1cCAmYW1wOyByZXN0b3JlIG9uIE92 aXJ0ID0KNC4yLjxicj4mZ3Q7Jmd0OyBJIGZvbGxvdyB0aGlzIGRvYzxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyBodHRwczovL3d3dy5vdmlyPQp0Lm9yZy9kb2N1bWVudGF0aW9uL2FkbWluLWd1aWRl L2NoYXAtQmFja3Vwc19hbmRfTWlncmF0aW9uLzxicj4mZ3Q7Jmd0OyBUcnk9CiB0byByZXN0b3Jl IHRvIGEgZnJlc2ggaW5zdGFsbGF0aW9uIGJ1dCBhbHdheXMgZ2V0IHRoaXMgZXJyb3IgbWVzc2Fn ZTo8YnI+Jj0KZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyByZXN0b3JlLXBlcm1pc3Npb25zPGJyPiZndDsm Z3Q7IFByZXBhcmluZyB0byByZXN0b3JlOjxiPQpyPiZndDsmZ3Q7IC0gVW5wYWNraW5nIGZpbGUg J2JhY2tfZmlsZSc8YnI+Jmd0OyZndDsgUmVzdG9yaW5nOjxicj4mZ3Q7Jmd0OyA9Ci0gRmlsZXM8 YnI+Jmd0OyZndDsgUHJvdmlzaW9uaW5nIFBvc3RncmVTUUwgdXNlcnMvZGF0YWJhc2VzOjxicj4m Z3Q7Jmd0OyAtID0KdXNlciAnZW5naW5lJywgZGF0YWJhc2UgJ2VuZ2luZSc8YnI+Jmd0OyZndDsg UmVzdG9yaW5nOjxicj4mZ3Q7Jmd0OyBGQVRBTDogPQpDYW4ndCBjb25uZWN0IHRvIGRhdGFiYXNl ICdvdmlydF9lbmdpbmVfaGlzdG9yeScuIFBsZWFzZSBzZWU8YnI+Jmd0OyZndDsgJy89CnVzci9i aW4vZW5naW5lLWJhY2t1cCAtLWhlbHAnLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBPbiB0aGUg bGl2ZSBlbmdpbmUgST0KIHJ1biAjIGVuZ2luZS1iYWNrdXAgLS1zY29wZT0zRGFsbCAtLW1vZGU9 M0RiYWNrdXA8YnI+Jmd0OyZndDsgLS1maWxlPTNEZmlsPQplX25hbWUgLS1sb2c9M0Rsb2dfZmls ZV9uYW1lPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEFuZCB0cnkgdG8gcmVzdG9yZSBvbiA9CmEg ZnJlc2ggaW5zdGFsbGF0aW9uOjxicj4mZ3Q7Jmd0OyAjIGVuZ2luZS1iYWNrdXAgLS1tb2RlPTNE cmVzdG9yZSAtLWZpbGU9Cj0zRGZpbGVfbmFtZSAtLWxvZz0zRGxvZ19maWxlX25hbWU8YnI+Jmd0 OyZndDsgLS1wcm92aXNpb24tZGIgLS1yZXN0b3JlLXBlcj0KbWlzc2lvbnM8YnI+Jmd0OyZndDs8 YnI+Jmd0OyZndDsgQW55IElkZWE/PGJyPiZndDs8YnI+Jmd0OyBQbGVhc2UgdHJ5IGFkZGluPQpn IHRvIHJlc3RvcmUgY29tbWFuZCAnLS1wcm92aWRpb24tZHdoLWRiJy4gVGhhbmtzLjxicj4mZ3Q7 IC0tPGJyPiZndDsgRGlkaTw9CmJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IFVzZT0KcnMgbWFpbGluZyBsaXN0PGJy PiZndDsgVXNlcnNAb3ZpcnQub3JnPGJyPiZndDsgaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWls PQptYW4vbGlzdGluZm8vdXNlcnM8YnI+PGJyPjxicj48YnI+LS0gPGJyPkRpZGk8YnI+PC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4KLS0tLS0tPV9QYXJ0XzIwNTY2OTY2XzM5NTU1MDUyLjE1MTk5 MDYwNzg2NzctLQo= --===============2183825340960443521==-- From emmanuel.thetas at obs-nancay.fr Thu May 24 09:32:41 2018 Content-Type: multipart/mixed; boundary="===============7475917538793603669==" MIME-Version: 1.0 From: emmanuel.thetas at obs-nancay.fr To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Thu, 24 May 2018 09:32:33 +0000 Message-ID: <20180524093233.23217.93425@mail.ovirt.org> In-Reply-To: 1803853344.20566967.1519906078677.JavaMail.zimbra@logicworks.pt --===============7475917538793603669== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable hi, I have the same error when I try to restore on a new hosted VM (ovirt 4.2.3) Have you a solution ? Emmanuel --===============7475917538793603669==-- From torsten.stolpmann at verit.de Mon Dec 17 12:25:22 2018 Content-Type: multipart/mixed; boundary="===============8573867522399118449==" MIME-Version: 1.0 From: Torsten Stolpmann To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Mon, 17 Dec 2018 13:16:15 +0100 Message-ID: In-Reply-To: 20180524093233.23217.93425@mail.ovirt.org --===============8573867522399118449== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I experienced the same issue while restoring a full backup (engine & = dwh) on a clean machine. Both machines are running CentOS 7.6 and oVirt 4.2.7. The issue went away when adding the following line to the IGNORED_ERRORS = list starting at 1944 in engine-backup: must be owner of function uuid_generate_v1 Hope this helps, Torsten On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: > hi, > = > I have the same error when I try to restore on a new hosted VM (ovirt 4.2= .3) > Have you a solution ? > = > Emmanuel > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org >=20 --===============8573867522399118449==-- From didi at redhat.com Tue Dec 18 06:55:05 2018 Content-Type: multipart/mixed; boundary="===============7731187314176235713==" MIME-Version: 1.0 From: Yedidyah Bar David To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Tue, 18 Dec 2018 08:54:30 +0200 Message-ID: In-Reply-To: cd57a7b6-638e-6eb7-84c4-a324f57b7c79@verit.de --===============7731187314176235713== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann wrote: > > I experienced the same issue while restoring a full backup (engine & > dwh) on a clean machine. Both machines are running CentOS 7.6 and > oVirt 4.2.7. > > The issue went away when adding the following line to the IGNORED_ERRORS > list starting at 1944 in engine-backup: > > must be owner of function uuid_generate_v1 > > Hope this helps, It does, and thanks for the report! Can you please share all of your setup logs (/var/log/ovirt-engine/setup/*)? Thanks! More details: This function should not normally be included in a 4.2 backup, and I do not yet understand why you get this error. If it's a clean 4.2 setup, it should never have been defined. Earlier versions did create it, and the upgrade process should have dropped it, if it's an upgraded setup. See also: https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 Best regards, > > Torsten > > On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: > > hi, > > > > I have the same error when I try to restore on a new hosted VM (ovirt 4= .2.3) > > Have you a solution ? > > > > Emmanuel > > _______________________________________________ > > Users mailing list -- users(a)ovirt.org > > To unsubscribe send an email to users-leave(a)ovirt.org > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-gu= idelines/ > List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.org/me= ssage/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ -- = Didi --===============7731187314176235713==-- From torsten.stolpmann at verit.de Tue Dec 18 15:18:17 2018 Content-Type: multipart/mixed; boundary="===============9112225799284878926==" MIME-Version: 1.0 From: Torsten Stolpmann To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Tue, 18 Dec 2018 16:17:50 +0100 Message-ID: <26f03b4e-45c0-f554-09c6-572ef7c4abe6@verit.de> In-Reply-To: CAHRwYXsOcNscgn-Upde6JJDiGvL85vmOhG_CUKhY42acSn_x8A@mail.gmail.com --===============9112225799284878926== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Yedidyah, please find the logs at the following URL: = http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz Let me know once you received them safely so I can remove them again. I also added the restore.log containing the actual error which occured = during the restore. Since this was a clean system I restored on, the setup has been executed = after the database restore, so the setup logs probably contain nothing = of interest. I added them anyway. Please let me know if there is anything I can add to this. Cheers, Torsten On 18.12.2018 07:54, Yedidyah Bar David wrote: > On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann > wrote: >> >> I experienced the same issue while restoring a full backup (engine & >> dwh) on a clean machine. Both machines are running CentOS 7.6 and >> oVirt 4.2.7. >> >> The issue went away when adding the following line to the IGNORED_ERRORS >> list starting at 1944 in engine-backup: >> >> must be owner of function uuid_generate_v1 >> >> Hope this helps, > = > It does, and thanks for the report! > = > Can you please share all of your setup logs (/var/log/ovirt-engine/setup/= *)? > = > Thanks! > = > More details: > = > This function should not normally be included in a 4.2 backup, and I do > not yet understand why you get this error. > = > If it's a clean 4.2 setup, it should never have been defined. > Earlier versions did create it, and the upgrade process should have > dropped it, if it's an upgraded setup. See also: > = > https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 > = > Best regards, > = >> >> Torsten >> >> On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: >>> hi, >>> >>> I have the same error when I try to restore on a new hosted VM (ovirt 4= .2.3) >>> Have you a solution ? >>> >>> Emmanuel >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-leave(a)ovirt.org >>> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-g= uidelines/ >> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.org/m= essage/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ > = > = >=20 --===============9112225799284878926==-- From didi at redhat.com Wed Dec 19 07:02:23 2018 Content-Type: multipart/mixed; boundary="===============8268972851227782019==" MIME-Version: 1.0 From: Yedidyah Bar David To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Wed, 19 Dec 2018 09:01:12 +0200 Message-ID: In-Reply-To: 26f03b4e-45c0-f554-09c6-572ef7c4abe6@verit.de --===============8268972851227782019== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann wrote: > > Hi Yedidyah, > > please find the logs at the following URL: > http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.gz > > Let me know once you received them safely so I can remove them again. Done. > > I also added the restore.log containing the actual error which occured > during the restore. > > Since this was a clean system I restored on, the setup has been executed > after the database restore, so the setup logs probably contain nothing > of interest. I added them anyway. Sorry I wasn't clear enough. I meant the setup logs on the machine used to create the backup. So that I can try to see why your backup contained this function. Do you still have these by any chance? Indeed, I can't see anything wrong in the logs above. > > Please let me know if there is anything I can add to this. If you do not have setup logs from the original machine, at least try to think about its history and tell us notable points - including entire version history, setup/upgrade (or similar) problems you had there (and perhaps worked around), etc. If you, or anyone, manages to come up with a flow resulting in a 4.2 engine database that contains a function uuid_generate_v1 in the engine database schema, I'd definitely want to know about it. Re-adding others posting in this thread, in case someone has a clue. Perhaps one of you has setup logs of the machine on which the backup was generated? If so, please share. Thanks. That said, on a second thought, the implications of this are not that significant - mainly somewhat lower performance - so perhaps it's more important to fix your bug (by adding a line to IGNORED_ERRORS, as you suggested)... but it's still weird. Thanks and best regards, > > Cheers, > > Torsten > > > On 18.12.2018 07:54, Yedidyah Bar David wrote: > > On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann > > wrote: > >> > >> I experienced the same issue while restoring a full backup (engine & > >> dwh) on a clean machine. Both machines are running CentOS 7.6 and > >> oVirt 4.2.7. > >> > >> The issue went away when adding the following line to the IGNORED_ERRO= RS > >> list starting at 1944 in engine-backup: > >> > >> must be owner of function uuid_generate_v1 > >> > >> Hope this helps, > > > > It does, and thanks for the report! > > > > Can you please share all of your setup logs (/var/log/ovirt-engine/setu= p/*)? > > > > Thanks! > > > > More details: > > > > This function should not normally be included in a 4.2 backup, and I do > > not yet understand why you get this error. > > > > If it's a clean 4.2 setup, it should never have been defined. > > Earlier versions did create it, and the upgrade process should have > > dropped it, if it's an upgraded setup. See also: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 > > > > Best regards, > > > >> > >> Torsten > >> > >> On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: > >>> hi, > >>> > >>> I have the same error when I try to restore on a new hosted VM (ovirt= 4.2.3) > >>> Have you a solution ? > >>> > >>> Emmanuel > >>> _______________________________________________ > >>> Users mailing list -- users(a)ovirt.org > >>> To unsubscribe send an email to users-leave(a)ovirt.org > >>> > >> _______________________________________________ > >> Users mailing list -- users(a)ovirt.org > >> To unsubscribe send an email to users-leave(a)ovirt.org > >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community= -guidelines/ > >> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.org= /message/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ > > > > > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-gu= idelines/ > List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.org/me= ssage/FCN5WVAJOGFBUTFV276O2RMCTMACAGTS/ -- = Didi --===============8268972851227782019==-- From torsten.stolpmann at verit.de Wed Dec 19 10:35:22 2018 Content-Type: multipart/mixed; boundary="===============6077690238902431679==" MIME-Version: 1.0 From: Torsten Stolpmann To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Wed, 19 Dec 2018 11:34:19 +0100 Message-ID: In-Reply-To: CAHRwYXvfpV5B6Shfw5rUVF13nTtZG-HaB2EtqXsdt8FcTL2JgA@mail.gmail.com --===============6077690238902431679== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 19.12.2018 08:01, Yedidyah Bar David wrote: > On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann > wrote: >> >> Hi Yedidyah, >> >> please find the logs at the following URL: >> http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.tar.= gz >> >> Let me know once you received them safely so I can remove them again. > = > Done. > = Thanks, removed. >> >> I also added the restore.log containing the actual error which occured >> during the restore. >> >> Since this was a clean system I restored on, the setup has been executed >> after the database restore, so the setup logs probably contain nothing >> of interest. I added them anyway. > = > Sorry I wasn't clear enough. I meant the setup logs on the machine used > to create the backup. So that I can try to see why your backup contained > this function. Do you still have these by any chance? > = > Indeed, I can't see anything wrong in the logs above. > = Sorry for misunderstanding, this totally makes sense. I added the setup logs i found at: = http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz Again, please let me know once I can remove them. >> >> Please let me know if there is anything I can add to this. > = > If you do not have setup logs from the original machine, at least try > to think about its history and tell us notable points - including entire > version history, setup/upgrade (or similar) problems you had there (and > perhaps worked around), etc. > = We started with one of the first 4.0 releases and updated the system on = a regular basis since then. We almost never skipped a release. There was indeed one glitch during updates which was connected to the = Postgres version in use: The initial install was (accidentally) done under Postgres 9.4 which = happened to be present on the machine at that point of time. oVirt 4.0 = was allowing this way back then. I think in 4.1 Postgres 9.2 has been = enforced, so there had been workarounds to allow updates under 9.4. This = got resolved with the migration to 4.2 which brought the Postgres 9.5 = installation (if I recall that correctly). Other than that I have no idea which might have introduced this. If you find something in the logs you need more information on, please = let me know. Best regards Torsten > If you, or anyone, manages to come up with a flow resulting in a 4.2 > engine database that contains a function uuid_generate_v1 in the engine > database schema, I'd definitely want to know about it. > = > Re-adding others posting in this thread, in case someone has a clue. > Perhaps one of you has setup logs of the machine on which the backup > was generated? If so, please share. Thanks. > = > That said, on a second thought, the implications of this are not that > significant - mainly somewhat lower performance - so perhaps it's more > important to fix your bug (by adding a line to IGNORED_ERRORS, as you > suggested)... but it's still weird. > = > Thanks and best regards, > = >> >> Cheers, >> >> Torsten >> >> >> On 18.12.2018 07:54, Yedidyah Bar David wrote: >>> On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann >>> wrote: >>>> >>>> I experienced the same issue while restoring a full backup (engine & >>>> dwh) on a clean machine. Both machines are running CentOS 7.6 and >>>> oVirt 4.2.7. >>>> >>>> The issue went away when adding the following line to the IGNORED_ERRO= RS >>>> list starting at 1944 in engine-backup: >>>> >>>> must be owner of function uuid_generate_v1 >>>> >>>> Hope this helps, >>> >>> It does, and thanks for the report! >>> >>> Can you please share all of your setup logs (/var/log/ovirt-engine/setu= p/*)? >>> >>> Thanks! >>> >>> More details: >>> >>> This function should not normally be included in a 4.2 backup, and I do >>> not yet understand why you get this error. >>> >>> If it's a clean 4.2 setup, it should never have been defined. >>> Earlier versions did create it, and the upgrade process should have >>> dropped it, if it's an upgraded setup. See also: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 >>> >>> Best regards, >>> >>>> >>>> Torsten >>>> >>>> On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: >>>>> hi, >>>>> >>>>> I have the same error when I try to restore on a new hosted VM (ovirt= 4.2.3) >>>>> Have you a solution ? >>>>> >>>>> Emmanuel >>>>> _______________________________________________ >>>>> Users mailing list -- users(a)ovirt.org >>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>> >>>> _______________________________________________ >>>> Users mailing list -- users(a)ovirt.org >>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community= -guidelines/ >>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.org= /message/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ >>> >>> >>> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-g= uidelines/ >> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.org/m= essage/FCN5WVAJOGFBUTFV276O2RMCTMACAGTS/ > = > = >=20 --===============6077690238902431679==-- From didi at redhat.com Wed Dec 19 10:55:27 2018 Content-Type: multipart/mixed; boundary="===============3714717035290331165==" MIME-Version: 1.0 From: Yedidyah Bar David To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Wed, 19 Dec 2018 12:54:56 +0200 Message-ID: In-Reply-To: bebbaf6f-2d88-7ec1-17a0-b5958a18b4c0@verit.de --===============3714717035290331165== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann wrote: > > On 19.12.2018 08:01, Yedidyah Bar David wrote: > > On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann > > wrote: > >> > >> Hi Yedidyah, > >> > >> please find the logs at the following URL: > >> http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.ta= r.gz > >> > >> Let me know once you received them safely so I can remove them again. > > > > Done. > > > > Thanks, removed. > > >> > >> I also added the restore.log containing the actual error which occured > >> during the restore. > >> > >> Since this was a clean system I restored on, the setup has been execut= ed > >> after the database restore, so the setup logs probably contain nothing > >> of interest. I added them anyway. > > > > Sorry I wasn't clear enough. I meant the setup logs on the machine used > > to create the backup. So that I can try to see why your backup contained > > this function. Do you still have these by any chance? > > > > Indeed, I can't see anything wrong in the logs above. > > > Sorry for misunderstanding, this totally makes sense. > > I added the setup logs i found at: > http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz > > Again, please let me know once I can remove them. Done. > > >> > >> Please let me know if there is anything I can add to this. > > > > If you do not have setup logs from the original machine, at least try > > to think about its history and tell us notable points - including entire > > version history, setup/upgrade (or similar) problems you had there (and > > perhaps worked around), etc. > > > > We started with one of the first 4.0 releases and updated the system on > a regular basis since then. We almost never skipped a release. The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , meaning it was last upgraded almost a year ago. Were there indeed no more upgrades since? The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , which didn't remove the uuid functions. The bug I linked at before, 1515635, was fixed in 4.2.1. Based on this, I think the best solution for now would be the patch you suggested. Would you like to open a bug for this and push a patch to gerrit? I can do this as well if you prefer. Bug summary line should probably be something like: engine-setup fails after restoring a backup taken with 4.2.0 Another solution would be to try using the same engine version during restore (4.2.0.2), and only upgrade later. This is a bit hard, because we do not have separate repos for each version, although they do include all released versions - so you can try e.g.: yum install ovirt-engine-4.2.0.2-1.el7 (meaning, after you remove existing 4.2.7, or you can try yum downgrade). I didn't try this myself, not sure how well it would work. There might be older dependencies to handle, and/or it might break due to too-new stuff. Obviously, the best solution is to upgrade more often and backup more often, and have a smaller difference between backup version and restore version, ideally no difference. But I realize this does not always work out for everyone... > > There was indeed one glitch during updates which was connected to the > Postgres version in use: > > The initial install was (accidentally) done under Postgres 9.4 which > happened to be present on the machine at that point of time. oVirt 4.0 > was allowing this way back then. I think in 4.1 Postgres 9.2 has been > enforced, so there had been workarounds to allow updates under 9.4. This > got resolved with the migration to 4.2 which brought the Postgres 9.5 > installation (if I recall that correctly). > > Other than that I have no idea which might have introduced this. All of this sounds irrelevant to current problem. Thanks for recalling :-) Best regards, > > If you find something in the logs you need more information on, please > let me know. > > Best regards > > Torsten > > > > If you, or anyone, manages to come up with a flow resulting in a 4.2 > > engine database that contains a function uuid_generate_v1 in the engine > > database schema, I'd definitely want to know about it. > > > > Re-adding others posting in this thread, in case someone has a clue. > > Perhaps one of you has setup logs of the machine on which the backup > > was generated? If so, please share. Thanks. > > > > That said, on a second thought, the implications of this are not that > > significant - mainly somewhat lower performance - so perhaps it's more > > important to fix your bug (by adding a line to IGNORED_ERRORS, as you > > suggested)... but it's still weird. > > > > Thanks and best regards, > > > >> > >> Cheers, > >> > >> Torsten > >> > >> > >> On 18.12.2018 07:54, Yedidyah Bar David wrote: > >>> On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann > >>> wrote: > >>>> > >>>> I experienced the same issue while restoring a full backup (engine & > >>>> dwh) on a clean machine. Both machines are running CentOS 7.6 and > >>>> oVirt 4.2.7. > >>>> > >>>> The issue went away when adding the following line to the IGNORED_ER= RORS > >>>> list starting at 1944 in engine-backup: > >>>> > >>>> must be owner of function uuid_generate_v1 > >>>> > >>>> Hope this helps, > >>> > >>> It does, and thanks for the report! > >>> > >>> Can you please share all of your setup logs (/var/log/ovirt-engine/se= tup/*)? > >>> > >>> Thanks! > >>> > >>> More details: > >>> > >>> This function should not normally be included in a 4.2 backup, and I = do > >>> not yet understand why you get this error. > >>> > >>> If it's a clean 4.2 setup, it should never have been defined. > >>> Earlier versions did create it, and the upgrade process should have > >>> dropped it, if it's an upgraded setup. See also: > >>> > >>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 > >>> > >>> Best regards, > >>> > >>>> > >>>> Torsten > >>>> > >>>> On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: > >>>>> hi, > >>>>> > >>>>> I have the same error when I try to restore on a new hosted VM (ovi= rt 4.2.3) > >>>>> Have you a solution ? > >>>>> > >>>>> Emmanuel > >>>>> _______________________________________________ > >>>>> Users mailing list -- users(a)ovirt.org > >>>>> To unsubscribe send an email to users-leave(a)ovirt.org > >>>>> > >>>> _______________________________________________ > >>>> Users mailing list -- users(a)ovirt.org > >>>> To unsubscribe send an email to users-leave(a)ovirt.org > >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/communi= ty-guidelines/ > >>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.o= rg/message/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ > >>> > >>> > >>> > >> _______________________________________________ > >> Users mailing list -- users(a)ovirt.org > >> To unsubscribe send an email to users-leave(a)ovirt.org > >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community= -guidelines/ > >> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.org= /message/FCN5WVAJOGFBUTFV276O2RMCTMACAGTS/ > > > > > > -- = Didi --===============3714717035290331165==-- From torsten.stolpmann at verit.de Wed Dec 19 11:35:43 2018 Content-Type: multipart/mixed; boundary="===============7148971807397845571==" MIME-Version: 1.0 From: Torsten Stolpmann To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Wed, 19 Dec 2018 12:35:16 +0100 Message-ID: <65fa68fb-ed39-6ed8-debd-41af8ca76f3b@verit.de> In-Reply-To: CAHRwYXtV89SQrDGdeqXTJ2j6zpXOKmesA6SdnPKL6BCmwuORqg@mail.gmail.com --===============7148971807397845571== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 19.12.2018 11:54, Yedidyah Bar David wrote: > On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann > wrote: >> >> On 19.12.2018 08:01, Yedidyah Bar David wrote: >>> On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann >>> wrote: >>>> >>>> Hi Yedidyah, >>>> >>>> please find the logs at the following URL: >>>> http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.ta= r.gz >>>> >>>> Let me know once you received them safely so I can remove them again. >>> >>> Done. >>> >> >> Thanks, removed. >> >>>> >>>> I also added the restore.log containing the actual error which occured >>>> during the restore. >>>> >>>> Since this was a clean system I restored on, the setup has been execut= ed >>>> after the database restore, so the setup logs probably contain nothing >>>> of interest. I added them anyway. >>> >>> Sorry I wasn't clear enough. I meant the setup logs on the machine used >>> to create the backup. So that I can try to see why your backup contained >>> this function. Do you still have these by any chance? >>> >>> Indeed, I can't see anything wrong in the logs above. >>> >> Sorry for misunderstanding, this totally makes sense. >> >> I added the setup logs i found at: >> http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.gz >> >> Again, please let me know once I can remove them. > = > Done. > Thanks, removed. >> >>>> >>>> Please let me know if there is anything I can add to this. >>> >>> If you do not have setup logs from the original machine, at least try >>> to think about its history and tell us notable points - including entire >>> version history, setup/upgrade (or similar) problems you had there (and >>> perhaps worked around), etc. >>> >> >> We started with one of the first 4.0 releases and updated the system on >> a regular basis since then. We almost never skipped a release. > = > The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , > meaning it was last upgraded almost a year ago. Were there indeed no > more upgrades since? > = 20171231170651 is most probably the date when we installed the last = major release (4.2.0). We did a lot more updates since and I now have a = suspicion what went wrong here. We naively assumed that a yum update is sufficient for a minor upgrade = of the engine installation. Rereading the documentation I think we were = missing explicit engine-setup calls after each minor upgrade. It may be the case, that the extra call to engine-setup is required to = not be part of the yum update. I think in this case it would be a good = idea to warn users that this step has not yet been taken and the update = is not completed yet. Could this be the cause for the missing logs and behavior discrepancies? If yes, would another call to engine-setup in the current state fix this = and allow us to produce correct backups in the future? > The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , > which didn't remove the uuid functions. The bug I linked at before, > 1515635, was fixed in 4.2.1. > = > Based on this, I think the best solution for now would be the patch > you suggested. Would you like to open a bug for this and push a patch > to gerrit? I can do this as well if you prefer. Bug summary line > should probably be something like: > = > engine-setup fails after restoring a backup taken with 4.2.0 > = I currently fear that would only cure the symptom. > Another solution would be to try using the same engine version during > restore (4.2.0.2), and only upgrade later. This is a bit hard, because > we do not have separate repos for each version, although they do > include all released versions - so you can try e.g.: > = > yum install ovirt-engine-4.2.0.2-1.el7 > = > (meaning, after you remove existing 4.2.7, or you can try yum downgrade). > = > I didn't try this myself, not sure how well it would work. There might > be older dependencies to handle, and/or it might break due to too-new > stuff. > = I don't think this is necessary. > Obviously, the best solution is to upgrade more often and backup more > often, and have a smaller difference between backup version and restore > version, ideally no difference. But I realize this does not always > work out for everyone... > = You are right, we did this. Best regards Torsten >> >> There was indeed one glitch during updates which was connected to the >> Postgres version in use: >> >> The initial install was (accidentally) done under Postgres 9.4 which >> happened to be present on the machine at that point of time. oVirt 4.0 >> was allowing this way back then. I think in 4.1 Postgres 9.2 has been >> enforced, so there had been workarounds to allow updates under 9.4. This >> got resolved with the migration to 4.2 which brought the Postgres 9.5 >> installation (if I recall that correctly). >> >> Other than that I have no idea which might have introduced this. > = > All of this sounds irrelevant to current problem. Thanks for recalling :-) > = > Best regards, > = >> >> If you find something in the logs you need more information on, please >> let me know. >> >> Best regards >> >> Torsten >> >> >>> If you, or anyone, manages to come up with a flow resulting in a 4.2 >>> engine database that contains a function uuid_generate_v1 in the engine >>> database schema, I'd definitely want to know about it. >>> >>> Re-adding others posting in this thread, in case someone has a clue. >>> Perhaps one of you has setup logs of the machine on which the backup >>> was generated? If so, please share. Thanks. >>> >>> That said, on a second thought, the implications of this are not that >>> significant - mainly somewhat lower performance - so perhaps it's more >>> important to fix your bug (by adding a line to IGNORED_ERRORS, as you >>> suggested)... but it's still weird. >>> >>> Thanks and best regards, >>> >>>> >>>> Cheers, >>>> >>>> Torsten >>>> >>>> >>>> On 18.12.2018 07:54, Yedidyah Bar David wrote: >>>>> On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann >>>>> wrote: >>>>>> >>>>>> I experienced the same issue while restoring a full backup (engine & >>>>>> dwh) on a clean machine. Both machines are running CentOS 7.6 and >>>>>> oVirt 4.2.7. >>>>>> >>>>>> The issue went away when adding the following line to the IGNORED_ER= RORS >>>>>> list starting at 1944 in engine-backup: >>>>>> >>>>>> must be owner of function uuid_generate_v1 >>>>>> >>>>>> Hope this helps, >>>>> >>>>> It does, and thanks for the report! >>>>> >>>>> Can you please share all of your setup logs (/var/log/ovirt-engine/se= tup/*)? >>>>> >>>>> Thanks! >>>>> >>>>> More details: >>>>> >>>>> This function should not normally be included in a 4.2 backup, and I = do >>>>> not yet understand why you get this error. >>>>> >>>>> If it's a clean 4.2 setup, it should never have been defined. >>>>> Earlier versions did create it, and the upgrade process should have >>>>> dropped it, if it's an upgraded setup. See also: >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 >>>>> >>>>> Best regards, >>>>> >>>>>> >>>>>> Torsten >>>>>> >>>>>> On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: >>>>>>> hi, >>>>>>> >>>>>>> I have the same error when I try to restore on a new hosted VM (ovi= rt 4.2.3) >>>>>>> Have you a solution ? >>>>>>> >>>>>>> Emmanuel >>>>>>> _______________________________________________ >>>>>>> Users mailing list -- users(a)ovirt.org >>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list -- users(a)ovirt.org >>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/communi= ty-guidelines/ >>>>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.o= rg/message/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Users mailing list -- users(a)ovirt.org >>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/community= -guidelines/ >>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.org= /message/FCN5WVAJOGFBUTFV276O2RMCTMACAGTS/ >>> >>> >>> > = > = >=20 --===============7148971807397845571==-- From didi at redhat.com Thu Dec 20 06:42:25 2018 Content-Type: multipart/mixed; boundary="===============2351612994097790819==" MIME-Version: 1.0 From: Yedidyah Bar David To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Thu, 20 Dec 2018 08:41:45 +0200 Message-ID: In-Reply-To: 65fa68fb-ed39-6ed8-debd-41af8ca76f3b@verit.de --===============2351612994097790819== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann wrote: > > On 19.12.2018 11:54, Yedidyah Bar David wrote: > > On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann > > wrote: > >> > >> On 19.12.2018 08:01, Yedidyah Bar David wrote: > >>> On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann > >>> wrote: > >>>> > >>>> Hi Yedidyah, > >>>> > >>>> please find the logs at the following URL: > >>>> http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.= tar.gz > >>>> > >>>> Let me know once you received them safely so I can remove them again. > >>> > >>> Done. > >>> > >> > >> Thanks, removed. > >> > >>>> > >>>> I also added the restore.log containing the actual error which occur= ed > >>>> during the restore. > >>>> > >>>> Since this was a clean system I restored on, the setup has been exec= uted > >>>> after the database restore, so the setup logs probably contain nothi= ng > >>>> of interest. I added them anyway. > >>> > >>> Sorry I wasn't clear enough. I meant the setup logs on the machine us= ed > >>> to create the backup. So that I can try to see why your backup contai= ned > >>> this function. Do you still have these by any chance? > >>> > >>> Indeed, I can't see anything wrong in the logs above. > >>> > >> Sorry for misunderstanding, this totally makes sense. > >> > >> I added the setup logs i found at: > >> http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.= gz > >> > >> Again, please let me know once I can remove them. > > > > Done. > > > Thanks, removed. > > >> > >>>> > >>>> Please let me know if there is anything I can add to this. > >>> > >>> If you do not have setup logs from the original machine, at least try > >>> to think about its history and tell us notable points - including ent= ire > >>> version history, setup/upgrade (or similar) problems you had there (a= nd > >>> perhaps worked around), etc. > >>> > >> > >> We started with one of the first 4.0 releases and updated the system on > >> a regular basis since then. We almost never skipped a release. > > > > The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , > > meaning it was last upgraded almost a year ago. Were there indeed no > > more upgrades since? > > > > 20171231170651 is most probably the date when we installed the last > major release (4.2.0). We did a lot more updates since and I now have a > suspicion what went wrong here. > > We naively assumed that a yum update is sufficient for a minor upgrade > of the engine installation. :-( > Rereading the documentation I think we were > missing explicit engine-setup calls after each minor upgrade. Indeed > > It may be the case, that the extra call to engine-setup is required to > not be part of the yum update. engine-setup might need to ask the user questions, so we do not run it inside yum update. > I think in this case it would be a good > idea to warn users that this step has not yet been taken and the update > is not completed yet. Do you think you would have noticed? It's not that hard to add such a message during yum update, but not sure it's that helpful. Perhaps we can also make the engine check e.g. if the setup package is newer than itself, and warn the user in the admin ui. > > Could this be the cause for the missing logs and behavior discrepancies? > > If yes, would another call to engine-setup in the current state fix this > and allow us to produce correct backups in the future? If you still have the source machine, then yes, it should be enough. Run engine-setup, then engine-backup again to backup, then restore on the new machine. > > > The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , > > which didn't remove the uuid functions. The bug I linked at before, > > 1515635, was fixed in 4.2.1. > > > > Based on this, I think the best solution for now would be the patch > > you suggested. Would you like to open a bug for this and push a patch > > to gerrit? I can do this as well if you prefer. Bug summary line > > should probably be something like: > > > > engine-setup fails after restoring a backup taken with 4.2.0 > > > I currently fear that would only cure the symptom. > > > Another solution would be to try using the same engine version during > > restore (4.2.0.2), and only upgrade later. This is a bit hard, because > > we do not have separate repos for each version, although they do > > include all released versions - so you can try e.g.: > > > > yum install ovirt-engine-4.2.0.2-1.el7 > > > > (meaning, after you remove existing 4.2.7, or you can try yum downgrade= ). > > > > I didn't try this myself, not sure how well it would work. There might > > be older dependencies to handle, and/or it might break due to too-new > > stuff. > > > I don't think this is necessary. > > > Obviously, the best solution is to upgrade more often and backup more > > often, and have a smaller difference between backup version and restore > > version, ideally no difference. But I realize this does not always > > work out for everyone... > > > You are right, we did this. > OK. I assume this discussion is theoretical, right? That you already patched engine-backup manually and restored. Best regards, > Best regards > > Torsten > >> > >> There was indeed one glitch during updates which was connected to the > >> Postgres version in use: > >> > >> The initial install was (accidentally) done under Postgres 9.4 which > >> happened to be present on the machine at that point of time. oVirt 4.0 > >> was allowing this way back then. I think in 4.1 Postgres 9.2 has been > >> enforced, so there had been workarounds to allow updates under 9.4. Th= is > >> got resolved with the migration to 4.2 which brought the Postgres 9.5 > >> installation (if I recall that correctly). > >> > >> Other than that I have no idea which might have introduced this. > > > > All of this sounds irrelevant to current problem. Thanks for recalling = :-) > > > > Best regards, > > > >> > >> If you find something in the logs you need more information on, please > >> let me know. > >> > >> Best regards > >> > >> Torsten > >> > >> > >>> If you, or anyone, manages to come up with a flow resulting in a 4.2 > >>> engine database that contains a function uuid_generate_v1 in the engi= ne > >>> database schema, I'd definitely want to know about it. > >>> > >>> Re-adding others posting in this thread, in case someone has a clue. > >>> Perhaps one of you has setup logs of the machine on which the backup > >>> was generated? If so, please share. Thanks. > >>> > >>> That said, on a second thought, the implications of this are not that > >>> significant - mainly somewhat lower performance - so perhaps it's more > >>> important to fix your bug (by adding a line to IGNORED_ERRORS, as you > >>> suggested)... but it's still weird. > >>> > >>> Thanks and best regards, > >>> > >>>> > >>>> Cheers, > >>>> > >>>> Torsten > >>>> > >>>> > >>>> On 18.12.2018 07:54, Yedidyah Bar David wrote: > >>>>> On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann > >>>>> wrote: > >>>>>> > >>>>>> I experienced the same issue while restoring a full backup (engine= & > >>>>>> dwh) on a clean machine. Both machines are running CentOS 7.6 and > >>>>>> oVirt 4.2.7. > >>>>>> > >>>>>> The issue went away when adding the following line to the IGNORED_= ERRORS > >>>>>> list starting at 1944 in engine-backup: > >>>>>> > >>>>>> must be owner of function uuid_generate_v1 > >>>>>> > >>>>>> Hope this helps, > >>>>> > >>>>> It does, and thanks for the report! > >>>>> > >>>>> Can you please share all of your setup logs (/var/log/ovirt-engine/= setup/*)? > >>>>> > >>>>> Thanks! > >>>>> > >>>>> More details: > >>>>> > >>>>> This function should not normally be included in a 4.2 backup, and = I do > >>>>> not yet understand why you get this error. > >>>>> > >>>>> If it's a clean 4.2 setup, it should never have been defined. > >>>>> Earlier versions did create it, and the upgrade process should have > >>>>> dropped it, if it's an upgraded setup. See also: > >>>>> > >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 > >>>>> > >>>>> Best regards, > >>>>> > >>>>>> > >>>>>> Torsten > >>>>>> > >>>>>> On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: > >>>>>>> hi, > >>>>>>> > >>>>>>> I have the same error when I try to restore on a new hosted VM (o= virt 4.2.3) > >>>>>>> Have you a solution ? > >>>>>>> > >>>>>>> Emmanuel > >>>>>>> _______________________________________________ > >>>>>>> Users mailing list -- users(a)ovirt.org > >>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Users mailing list -- users(a)ovirt.org > >>>>>> To unsubscribe send an email to users-leave(a)ovirt.org > >>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >>>>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/commu= nity-guidelines/ > >>>>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt= .org/message/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> Users mailing list -- users(a)ovirt.org > >>>> To unsubscribe send an email to users-leave(a)ovirt.org > >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/communi= ty-guidelines/ > >>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.o= rg/message/FCN5WVAJOGFBUTFV276O2RMCTMACAGTS/ > >>> > >>> > >>> > > > > > > -- = Didi --===============2351612994097790819==-- From torsten.stolpmann at verit.de Thu Dec 20 18:23:34 2018 Content-Type: multipart/mixed; boundary="===============5232317770719309289==" MIME-Version: 1.0 From: Torsten Stolpmann To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Thu, 20 Dec 2018 19:23:06 +0100 Message-ID: <88e1ae1f-8af1-8a78-83e8-3bb097b8115c@verit.de> In-Reply-To: CAHRwYXvW=RnRCAAyGp8rqbNcQZrtJsmuDaTOWyKVxo+yzOH9rQ@mail.gmail.com --===============5232317770719309289== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 20.12.2018 07:41, Yedidyah Bar David wrote: > On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann > wrote: >> >> On 19.12.2018 11:54, Yedidyah Bar David wrote: >>> On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann >>> wrote: >>>> >>>> On 19.12.2018 08:01, Yedidyah Bar David wrote: >>>>> On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann >>>>> wrote: >>>>>> >>>>>> Hi Yedidyah, >>>>>> >>>>>> please find the logs at the following URL: >>>>>> http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-logs.= tar.gz >>>>>> >>>>>> Let me know once you received them safely so I can remove them again. >>>>> >>>>> Done. >>>>> >>>> >>>> Thanks, removed. >>>> >>>>>> >>>>>> I also added the restore.log containing the actual error which occur= ed >>>>>> during the restore. >>>>>> >>>>>> Since this was a clean system I restored on, the setup has been exec= uted >>>>>> after the database restore, so the setup logs probably contain nothi= ng >>>>>> of interest. I added them anyway. >>>>> >>>>> Sorry I wasn't clear enough. I meant the setup logs on the machine us= ed >>>>> to create the backup. So that I can try to see why your backup contai= ned >>>>> this function. Do you still have these by any chance? >>>>> >>>>> Indeed, I can't see anything wrong in the logs above. >>>>> >>>> Sorry for misunderstanding, this totally makes sense. >>>> >>>> I added the setup logs i found at: >>>> http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.tar.= gz >>>> >>>> Again, please let me know once I can remove them. >>> >>> Done. >>> >> Thanks, removed. >> >>>> >>>>>> >>>>>> Please let me know if there is anything I can add to this. >>>>> >>>>> If you do not have setup logs from the original machine, at least try >>>>> to think about its history and tell us notable points - including ent= ire >>>>> version history, setup/upgrade (or similar) problems you had there (a= nd >>>>> perhaps worked around), etc. >>>>> >>>> >>>> We started with one of the first 4.0 releases and updated the system on >>>> a regular basis since then. We almost never skipped a release. >>> >>> The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , >>> meaning it was last upgraded almost a year ago. Were there indeed no >>> more upgrades since? >>> >> >> 20171231170651 is most probably the date when we installed the last >> major release (4.2.0). We did a lot more updates since and I now have a >> suspicion what went wrong here. >> >> We naively assumed that a yum update is sufficient for a minor upgrade >> of the engine installation. > = > :-( > = >> Rereading the documentation I think we were >> missing explicit engine-setup calls after each minor upgrade. > = > Indeed > = >> >> It may be the case, that the extra call to engine-setup is required to >> not be part of the yum update. > = > engine-setup might need to ask the user questions, so we do not run it > inside yum update. > As long as it clear to users that this is required this is totally ok = for me. >> I think in this case it would be a good >> idea to warn users that this step has not yet been taken and the update >> is not completed yet. > = > Do you think you would have noticed? It's not that hard to add such a > message during yum update, but not sure it's that helpful. > = Yes, I would probably have noticed that. Sooner or later ... :) > Perhaps we can also make the engine check e.g. if the setup package is > newer than itself, and warn the user in the admin ui. > = I think that both is a good idea. Some applications even go the way to = lock out users from the GUI until a necessary database migration has = been executed by an administrator. Your mileage may vary here but this = is the solution I would favor. >> >> Could this be the cause for the missing logs and behavior discrepancies? >> >> If yes, would another call to engine-setup in the current state fix this >> and allow us to produce correct backups in the future? > = > If you still have the source machine, then yes, it should be enough. > Run engine-setup, then engine-backup again to backup, then restore > on the new machine. > = Thanks, will do. >> >>> The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , >>> which didn't remove the uuid functions. The bug I linked at before, >>> 1515635, was fixed in 4.2.1. >>> >>> Based on this, I think the best solution for now would be the patch >>> you suggested. Would you like to open a bug for this and push a patch >>> to gerrit? I can do this as well if you prefer. Bug summary line >>> should probably be something like: >>> >>> engine-setup fails after restoring a backup taken with 4.2.0 >>> >> I currently fear that would only cure the symptom. >> >>> Another solution would be to try using the same engine version during >>> restore (4.2.0.2), and only upgrade later. This is a bit hard, because >>> we do not have separate repos for each version, although they do >>> include all released versions - so you can try e.g.: >>> >>> yum install ovirt-engine-4.2.0.2-1.el7 >>> >>> (meaning, after you remove existing 4.2.7, or you can try yum downgrade= ). >>> >>> I didn't try this myself, not sure how well it would work. There might >>> be older dependencies to handle, and/or it might break due to too-new >>> stuff. >>> >> I don't think this is necessary. >> >>> Obviously, the best solution is to upgrade more often and backup more >>> often, and have a smaller difference between backup version and restore >>> version, ideally no difference. But I realize this does not always >>> work out for everyone... >>> >> You are right, we did this. >> > = > OK. I assume this discussion is theoretical, right? > That you already patched engine-backup manually and restored. Yes it is. Thanks a lot for your patience and support. Torsten > = > Best regards, > = >> Best regards >> >> Torsten >>>> >>>> There was indeed one glitch during updates which was connected to the >>>> Postgres version in use: >>>> >>>> The initial install was (accidentally) done under Postgres 9.4 which >>>> happened to be present on the machine at that point of time. oVirt 4.0 >>>> was allowing this way back then. I think in 4.1 Postgres 9.2 has been >>>> enforced, so there had been workarounds to allow updates under 9.4. Th= is >>>> got resolved with the migration to 4.2 which brought the Postgres 9.5 >>>> installation (if I recall that correctly). >>>> >>>> Other than that I have no idea which might have introduced this. >>> >>> All of this sounds irrelevant to current problem. Thanks for recalling = :-) >>> >>> Best regards, >>> >>>> >>>> If you find something in the logs you need more information on, please >>>> let me know. >>>> >>>> Best regards >>>> >>>> Torsten >>>> >>>> >>>>> If you, or anyone, manages to come up with a flow resulting in a 4.2 >>>>> engine database that contains a function uuid_generate_v1 in the engi= ne >>>>> database schema, I'd definitely want to know about it. >>>>> >>>>> Re-adding others posting in this thread, in case someone has a clue. >>>>> Perhaps one of you has setup logs of the machine on which the backup >>>>> was generated? If so, please share. Thanks. >>>>> >>>>> That said, on a second thought, the implications of this are not that >>>>> significant - mainly somewhat lower performance - so perhaps it's more >>>>> important to fix your bug (by adding a line to IGNORED_ERRORS, as you >>>>> suggested)... but it's still weird. >>>>> >>>>> Thanks and best regards, >>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Torsten >>>>>> >>>>>> >>>>>> On 18.12.2018 07:54, Yedidyah Bar David wrote: >>>>>>> On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann >>>>>>> wrote: >>>>>>>> >>>>>>>> I experienced the same issue while restoring a full backup (engine= & >>>>>>>> dwh) on a clean machine. Both machines are running CentOS 7.6 and >>>>>>>> oVirt 4.2.7. >>>>>>>> >>>>>>>> The issue went away when adding the following line to the IGNORED_= ERRORS >>>>>>>> list starting at 1944 in engine-backup: >>>>>>>> >>>>>>>> must be owner of function uuid_generate_v1 >>>>>>>> >>>>>>>> Hope this helps, >>>>>>> >>>>>>> It does, and thanks for the report! >>>>>>> >>>>>>> Can you please share all of your setup logs (/var/log/ovirt-engine/= setup/*)? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> More details: >>>>>>> >>>>>>> This function should not normally be included in a 4.2 backup, and = I do >>>>>>> not yet understand why you get this error. >>>>>>> >>>>>>> If it's a clean 4.2 setup, it should never have been defined. >>>>>>> Earlier versions did create it, and the upgrade process should have >>>>>>> dropped it, if it's an upgraded setup. See also: >>>>>>> >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>>> >>>>>>>> Torsten >>>>>>>> >>>>>>>> On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: >>>>>>>>> hi, >>>>>>>>> >>>>>>>>> I have the same error when I try to restore on a new hosted VM (o= virt 4.2.3) >>>>>>>>> Have you a solution ? >>>>>>>>> >>>>>>>>> Emmanuel >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list -- users(a)ovirt.org >>>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list -- users(a)ovirt.org >>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>>>>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/commu= nity-guidelines/ >>>>>>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt= .org/message/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list -- users(a)ovirt.org >>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/communi= ty-guidelines/ >>>>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt.o= rg/message/FCN5WVAJOGFBUTFV276O2RMCTMACAGTS/ >>>>> >>>>> >>>>> >>> >>> >>> > = > = >=20 --===============5232317770719309289==-- From didi at redhat.com Thu Dec 27 08:08:34 2018 Content-Type: multipart/mixed; boundary="===============2466129337610573442==" MIME-Version: 1.0 From: Yedidyah Bar David To: users at ovirt.org Subject: [ovirt-users] Re: Backup & Restore Date: Thu, 27 Dec 2018 10:07:55 +0200 Message-ID: In-Reply-To: 88e1ae1f-8af1-8a78-83e8-3bb097b8115c@verit.de --===============2466129337610573442== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Dec 20, 2018 at 8:23 PM Torsten Stolpmann wrote: > > On 20.12.2018 07:41, Yedidyah Bar David wrote: > > On Wed, Dec 19, 2018 at 1:35 PM Torsten Stolpmann > > wrote: > >> > >> On 19.12.2018 11:54, Yedidyah Bar David wrote: > >>> On Wed, Dec 19, 2018 at 12:34 PM Torsten Stolpmann > >>> wrote: > >>>> > >>>> On 19.12.2018 08:01, Yedidyah Bar David wrote: > >>>>> On Tue, Dec 18, 2018 at 5:20 PM Torsten Stolpmann > >>>>> wrote: > >>>>>> > >>>>>> Hi Yedidyah, > >>>>>> > >>>>>> please find the logs at the following URL: > >>>>>> http://www.klaros-testmanagement.com/files/ovirt/ovirt-restore-log= s.tar.gz > >>>>>> > >>>>>> Let me know once you received them safely so I can remove them aga= in. > >>>>> > >>>>> Done. > >>>>> > >>>> > >>>> Thanks, removed. > >>>> > >>>>>> > >>>>>> I also added the restore.log containing the actual error which occ= ured > >>>>>> during the restore. > >>>>>> > >>>>>> Since this was a clean system I restored on, the setup has been ex= ecuted > >>>>>> after the database restore, so the setup logs probably contain not= hing > >>>>>> of interest. I added them anyway. > >>>>> > >>>>> Sorry I wasn't clear enough. I meant the setup logs on the machine = used > >>>>> to create the backup. So that I can try to see why your backup cont= ained > >>>>> this function. Do you still have these by any chance? > >>>>> > >>>>> Indeed, I can't see anything wrong in the logs above. > >>>>> > >>>> Sorry for misunderstanding, this totally makes sense. > >>>> > >>>> I added the setup logs i found at: > >>>> http://www.klaros-testmanagement.com/files/ovirt/ovirt-setup-logs.ta= r.gz > >>>> > >>>> Again, please let me know once I can remove them. > >>> > >>> Done. > >>> > >> Thanks, removed. > >> > >>>> > >>>>>> > >>>>>> Please let me know if there is anything I can add to this. > >>>>> > >>>>> If you do not have setup logs from the original machine, at least t= ry > >>>>> to think about its history and tell us notable points - including e= ntire > >>>>> version history, setup/upgrade (or similar) problems you had there = (and > >>>>> perhaps worked around), etc. > >>>>> > >>>> > >>>> We started with one of the first 4.0 releases and updated the system= on > >>>> a regular basis since then. We almost never skipped a release. > >>> > >>> The last log there is ovirt-engine-setup-20171231170651-lb3q89.log , > >>> meaning it was last upgraded almost a year ago. Were there indeed no > >>> more upgrades since? > >>> > >> > >> 20171231170651 is most probably the date when we installed the last > >> major release (4.2.0). We did a lot more updates since and I now have a > >> suspicion what went wrong here. > >> > >> We naively assumed that a yum update is sufficient for a minor upgrade > >> of the engine installation. > > > > :-( > > > >> Rereading the documentation I think we were > >> missing explicit engine-setup calls after each minor upgrade. > > > > Indeed > > > >> > >> It may be the case, that the extra call to engine-setup is required to > >> not be part of the yum update. > > > > engine-setup might need to ask the user questions, so we do not run it > > inside yum update. > > > As long as it clear to users that this is required this is totally ok > for me. > > >> I think in this case it would be a good > >> idea to warn users that this step has not yet been taken and the update > >> is not completed yet. > > > > Do you think you would have noticed? It's not that hard to add such a > > message during yum update, but not sure it's that helpful. > > > Yes, I would probably have noticed that. Sooner or later ... :) OK, now finished verifying this patch in CI: https://gerrit.ovirt.org/96446 https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test= s_manual/3834/ https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test= s_manual/3834/artifact/exported-artifacts/test_logs/upgrade-from-release-su= ite-master/post-001_upgrade_engine.py/lago_logs/lago.log Total output of: 2018-12-27 06:58:03,392::ssh.py::ssh::58::lago.ssh::DEBUG::Running c14e276c on lago-upgrade-from-release-suite-master-engine: yum -y update ovirt-*setup* Is 220 lines. Among these, line 134-136 are: Updating : ovirt-engine-setup-4.3.0-0.4.master.20181226121322.gitfe 1= 7/33 Updating ovirt-engine-setup. To update the engine, you need to run: engine-= setup Updating : ovirt-engine-setup-plugin-websocket-proxy-4.3.0-0.4.mast 1= 8/33 and lines 151-153 are: Erasing : ovirt-engine-lib-4.2.8.2-0.0.master.20181220151741.git31 3= 3/33 Updated ovirt-engine-setup. To update the engine, you need to run: engine-s= etup Verifying : ovirt-engine-dwh-setup-4.3.0-0.4.master.20181210085817.e = 1/33 I looked at yum's sources, and do not see a way to make it output something closer to the end. Comments are welcome (here or on gerrit). > > > Perhaps we can also make the engine check e.g. if the setup package is > > newer than itself, and warn the user in the admin ui. > > > I think that both is a good idea. Some applications even go the way to > lock out users from the GUI until a necessary database migration has > been executed by an administrator. Your mileage may vary here but this > is the solution I would favor. Also filed (but am not going to try working on, it's not my expertise): https://bugzilla.redhat.com/show_bug.cgi?id=3D1662109 Best regards, > > >> > >> Could this be the cause for the missing logs and behavior discrepancie= s? > >> > >> If yes, would another call to engine-setup in the current state fix th= is > >> and allow us to produce correct backups in the future? > > > > If you still have the source machine, then yes, it should be enough. > > Run engine-setup, then engine-backup again to backup, then restore > > on the new machine. > > > Thanks, will do. > > >> > >>> The log indicates the machine was upgraded to ovirt-engine-4.2.0.2 , > >>> which didn't remove the uuid functions. The bug I linked at before, > >>> 1515635, was fixed in 4.2.1. > >>> > >>> Based on this, I think the best solution for now would be the patch > >>> you suggested. Would you like to open a bug for this and push a patch > >>> to gerrit? I can do this as well if you prefer. Bug summary line > >>> should probably be something like: > >>> > >>> engine-setup fails after restoring a backup taken with 4.2.0 > >>> > >> I currently fear that would only cure the symptom. > >> > >>> Another solution would be to try using the same engine version during > >>> restore (4.2.0.2), and only upgrade later. This is a bit hard, because > >>> we do not have separate repos for each version, although they do > >>> include all released versions - so you can try e.g.: > >>> > >>> yum install ovirt-engine-4.2.0.2-1.el7 > >>> > >>> (meaning, after you remove existing 4.2.7, or you can try yum downgra= de). > >>> > >>> I didn't try this myself, not sure how well it would work. There might > >>> be older dependencies to handle, and/or it might break due to too-new > >>> stuff. > >>> > >> I don't think this is necessary. > >> > >>> Obviously, the best solution is to upgrade more often and backup more > >>> often, and have a smaller difference between backup version and resto= re > >>> version, ideally no difference. But I realize this does not always > >>> work out for everyone... > >>> > >> You are right, we did this. > >> > > > > OK. I assume this discussion is theoretical, right? > > That you already patched engine-backup manually and restored. > > Yes it is. > > Thanks a lot for your patience and support. > > Torsten > > > > > Best regards, > > > >> Best regards > >> > >> Torsten > >>>> > >>>> There was indeed one glitch during updates which was connected to the > >>>> Postgres version in use: > >>>> > >>>> The initial install was (accidentally) done under Postgres 9.4 which > >>>> happened to be present on the machine at that point of time. oVirt 4= .0 > >>>> was allowing this way back then. I think in 4.1 Postgres 9.2 has been > >>>> enforced, so there had been workarounds to allow updates under 9.4. = This > >>>> got resolved with the migration to 4.2 which brought the Postgres 9.5 > >>>> installation (if I recall that correctly). > >>>> > >>>> Other than that I have no idea which might have introduced this. > >>> > >>> All of this sounds irrelevant to current problem. Thanks for recallin= g :-) > >>> > >>> Best regards, > >>> > >>>> > >>>> If you find something in the logs you need more information on, plea= se > >>>> let me know. > >>>> > >>>> Best regards > >>>> > >>>> Torsten > >>>> > >>>> > >>>>> If you, or anyone, manages to come up with a flow resulting in a 4.2 > >>>>> engine database that contains a function uuid_generate_v1 in the en= gine > >>>>> database schema, I'd definitely want to know about it. > >>>>> > >>>>> Re-adding others posting in this thread, in case someone has a clue. > >>>>> Perhaps one of you has setup logs of the machine on which the backup > >>>>> was generated? If so, please share. Thanks. > >>>>> > >>>>> That said, on a second thought, the implications of this are not th= at > >>>>> significant - mainly somewhat lower performance - so perhaps it's m= ore > >>>>> important to fix your bug (by adding a line to IGNORED_ERRORS, as y= ou > >>>>> suggested)... but it's still weird. > >>>>> > >>>>> Thanks and best regards, > >>>>> > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Torsten > >>>>>> > >>>>>> > >>>>>> On 18.12.2018 07:54, Yedidyah Bar David wrote: > >>>>>>> On Mon, Dec 17, 2018 at 2:26 PM Torsten Stolpmann > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> I experienced the same issue while restoring a full backup (engi= ne & > >>>>>>>> dwh) on a clean machine. Both machines are running CentOS 7.6 and > >>>>>>>> oVirt 4.2.7. > >>>>>>>> > >>>>>>>> The issue went away when adding the following line to the IGNORE= D_ERRORS > >>>>>>>> list starting at 1944 in engine-backup: > >>>>>>>> > >>>>>>>> must be owner of function uuid_generate_v1 > >>>>>>>> > >>>>>>>> Hope this helps, > >>>>>>> > >>>>>>> It does, and thanks for the report! > >>>>>>> > >>>>>>> Can you please share all of your setup logs (/var/log/ovirt-engin= e/setup/*)? > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> More details: > >>>>>>> > >>>>>>> This function should not normally be included in a 4.2 backup, an= d I do > >>>>>>> not yet understand why you get this error. > >>>>>>> > >>>>>>> If it's a clean 4.2 setup, it should never have been defined. > >>>>>>> Earlier versions did create it, and the upgrade process should ha= ve > >>>>>>> dropped it, if it's an upgraded setup. See also: > >>>>>>> > >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1515635 > >>>>>>> > >>>>>>> Best regards, > >>>>>>> > >>>>>>>> > >>>>>>>> Torsten > >>>>>>>> > >>>>>>>> On 24.05.2018 11:32, emmanuel.thetas(a)obs-nancay.fr wrote: > >>>>>>>>> hi, > >>>>>>>>> > >>>>>>>>> I have the same error when I try to restore on a new hosted VM = (ovirt 4.2.3) > >>>>>>>>> Have you a solution ? > >>>>>>>>> > >>>>>>>>> Emmanuel > >>>>>>>>> _______________________________________________ > >>>>>>>>> Users mailing list -- users(a)ovirt.org > >>>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org > >>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Users mailing list -- users(a)ovirt.org > >>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org > >>>>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >>>>>>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/com= munity-guidelines/ > >>>>>>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovi= rt.org/message/YMMFCYUMLCM47OJSTHXS2IMOIKEEFU27/ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Users mailing list -- users(a)ovirt.org > >>>>>> To unsubscribe send an email to users-leave(a)ovirt.org > >>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > >>>>>> oVirt Code of Conduct: https://www.ovirt.org/community/about/commu= nity-guidelines/ > >>>>>> List Archives: https://lists.ovirt.org/archives/list/users(a)ovirt= .org/message/FCN5WVAJOGFBUTFV276O2RMCTMACAGTS/ > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > > > > > > -- = Didi --===============2466129337610573442==--