On Thu, Sep 9, 2021 at 2:21 PM Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Sep 9, 2021 at 12:53 PM Nir Soffer <nsoffer@redhat.com> wrote: ...
Any insight for finding the scratch disks ids in engine.log? See here my engine.log and timestamp of backup (as seen in database above) is 15:31 on 03 September:
https://drive.google.com/file/d/1Ao1CIA2wlFCqMMKeXbxKXrWZXUrnJN2h/view?usp=s...
To find the scratch disks the best way is to use the UI - open the storage > disks tab and change the content type to "Backup scratch disks" (see attached screenshot)
I confirm no scratch disks has been left in my case
Regardless, it is useful to understand engine log, here are the relevant events in your log:
[snip] 11. Error in the backup command - not sure why...
[snip]
12. Errors writing to database - no space left
[snip]
This seems to be the root cause for the engine failure - engine cannot write to the database, so it cannot complete handling of the backup command.
[snip]
So both scratch disks were removed as expected, and the only issue is the backup stuck in the finalizing state.
Because the root cause is no space on the database disk, caused by user error (filling up engine disk by mistake), I don't think we can do much about this.
Nir
Indeed I didn't recall my filesystem layout. The full was in my home dir but as I have no dedicated /home filesystem, it generated a / filesystem full and so impacting also with PostgreSQL database for the engine that uses /var/lib/pgsql/data/base. This goes and confirms your recommendation of not using the engine for running the backup. currently in fact the layout of filesystems of my external engine is : [g.cecchi@ovmgr1 ~]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.9G 0 4.9G 0% /dev tmpfs 4.9G 24K 4.9G 1% /dev/shm tmpfs 4.9G 25M 4.9G 1% /run tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup /dev/mapper/cl-root 43G 5.1G 36G 13% / /dev/sda2 976M 199M 710M 22% /boot /dev/sda1 599M 7.3M 592M 2% /boot/efi tmpfs 998M 0 998M 0% /run/user/1000 [g.cecchi@ovmgr1 ~]$ Thanks very much for the detailed analysis. Ok also for the closing of the bugzilla. Gianluca