When testing a snapshot database restore by hand I've found that not all data will be restored and yet the psql command will exit with a status of 0, so a snapshot restore based on the data will appear to succeed.
psql:/tmp/tmpHFr8iO-snapshot-data/pg_data.new:80: ERROR: null value in column "_tenant_id" violates not-null constraint DETAIL: Failing row contains (2, 1c99dc6e-2b0f-424a-9c41-42c59774a26f, null, 2017-04-26 11:12:43.431, The blueprint describes an OpenStack vm created using Cloudify's..., \x80027d710128580a0000006167656e745f757365727102580600000063656e..., \x80027d71012e, null, \x80027d7101552b636c6f75646966792e706f6c69636965732e747269676765..., \x80027d7101285524636c6f75646966792e706f6c69636965732e7479706573..., \x80027d7101550d687474705f656e64706f696e7471027d710328550b646573..., \x80027d71012e, 2017-04-26 11:12:43.431, \x80027d71012855057363616c6571027d71032855096f7065726174696f6e71..., 2, null, 0). CONTEXT: COPY deployments, line 1: "2 1c99dc6e-2b0f-424a-9c41-42c59774a26f 2017-04-26 11:12:43.431 The blueprint describes an OpenStack ..." psql:/tmp/tmpHFr8iO-snapshot-data/pg_data.new:87: ERROR: current transaction is aborted, commands ignored until end of transaction block
Despite this error and the failure of everything after this point due to the failure in the transaction, the exit code of the psql will be 0, meaning that it'll be treated as a success.
It appears that adding '-v ON_ERROR_STOP=1' results in the correct behaviour on a failure but I've not yet confirmed that it also gives the correct behaviour on a success.
Probably affects 4.0.0 too, but not confirmed.
This was fixed recently.