[ovirt-users] Re: how to remove a failed backup operation
On Thu, Sep 9, 2021 at 2:21 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
On Thu, Sep 9, 2021 at 12:53 PM Nir Soffer <nsoffer(a)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?us...
>
>
> 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
Attachments:
- attachment.html (text/html — 4.0 KB)