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=sharing
>
>
> 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