On 22/04/2021 12:33, Dominic Jäger wrote:
On Wed, Apr 21, 2021 at 01:15:29PM +0200, Stefan Reiter wrote:
Implements the necessary API for allowing single file restore via the PVE web
GUI.
Restoring a couple of small text files and folders with textfiles from
containers worked really well for me. For VMs I could also restore some text
files & folders, but I didn't work as smooth.
I tried both with a single .fidx/root.pxar so far.
* This
proxmox-file-restore failed: Error: mounting 'drive-scsi0.img.fidx/part/1'
failed: all mounts failed or no supported file system (500)
is correct but it would be nice if we could try to say something like "We found
LVM stuff
which is currently unsupported". Currently it looks more like bug than
"expected error" to me.
I mean, the real fix here is to support those types of storage ;)
I think "no supported file system" explains the situation reasonably
well, but open to suggestions of course.
Maybe we could improve this (at some point in the future) so that the error
does not block the whole panel and we can continue to select another
part/number.
Because when two out of three parts block the whole thing, then remembering the
bad one(s), clicking X, clicking File restore->fidx->part->some number is not
ideal IMO.
argh, I already have a fix for that, but apparently I forgot to include
my widget-toolkit patches in the series - thanks for noticing!
* Sometimes the Download button remains enabled when errors (like the previous)
happen and then you get a couple of 0 byte files
yup, should probably disable that as well on error
* On the respective PBS sometimes this
2021-04-22T11:31:01+02:00: starting new backup reader datastore 'test': "/test"
2021-04-22T11:31:01+02:00: protocol upgrade done
2021-04-22T11:31:01+02:00: GET /download
2021-04-22T11:31:01+02:00: download
"/test/vm/100/2021-04-22T09:29:17Z/index.json.blob"
2021-04-22T11:31:01+02:00: GET /download
2021-04-22T11:31:01+02:00: download
"/test/vm/100/2021-04-22T09:29:17Z/drive-scsi0.img.fidx"
2021-04-22T11:31:01+02:00: register chunks in 'drive-scsi0.img.fidx' as
downloadable.
2021-04-22T11:31:01+02:00: GET /chunk
2021-04-22T11:31:01+02:00: download chunk
"/test/.chunks/394a/394a4b4c316868a466fbece11881752a10b31a782d2740ab414c3f48b5fb4e58"
2021-04-22T11:31:01+02:00: GET /chunk
2021-04-22T11:31:01+02:00: download chunk
"/test/.chunks/d628/d62885ad37c7a44a2fa9fdc558e85e89ecf4c9754617fab7e1f491fa3da65d38"
appears and stays there forever and when I clicked Stop
2021-04-22T11:47:00+02:00: TASK ERROR: task aborted
it seemed to accept but the circle remained spinning forever again (OK, I only
checked for a couple of minutes).
When you clicked "stop" where? On PBS side? That would be an error in
the server code somewhere then.
But yes, the task stays active - that is due to the nature of the beast,
the VM used to restore keeps the channel open for disk access as long as
it runs, once it times out the task should disappear too.
* Sometimes the PBS also logged
2021-04-22T11:42:40+02:00: starting new backup reader datastore 'test': "/test"
2021-04-22T11:42:40+02:00: protocol upgrade done
2021-04-22T11:42:40+02:00: GET /download
2021-04-22T11:42:40+02:00: download
"/test/ct/102/2021-04-22T09:39:23Z/index.json.blob"
2021-04-22T11:42:40+02:00: GET /download
2021-04-22T11:42:40+02:00: download
"/test/ct/102/2021-04-22T09:39:23Z/root.pxar.didx"
2021-04-22T11:42:40+02:00: register chunks in 'root.pxar.didx' as downloadable.
2021-04-22T11:42:40+02:00: GET /chunk
2021-04-22T11:42:40+02:00: download chunk
"/test/.chunks/ff63/ff63c49eae6b77e2933ea08af0dcf3786e74fc454ac2462ba780f0726c070023"
2021-04-22T11:42:40+02:00: GET /chunk
2021-04-22T11:42:40+02:00: download chunk
"/test/.chunks/261e/261ec247951ab57a51df87c593ae2aaf4f76c671bb94e13245f53ebdf25cfd45"
2021-04-22T11:42:40+02:00: GET /chunk
2021-04-22T11:42:40+02:00: download chunk
"/test/.chunks/3a60/3a60c4eb21123c01a63e981d8f550ba0f99b5e90b97340d384da9f079fa767ed"
2021-04-22T11:42:40+02:00: TASK ERROR: connection error: Transport endpoint is
not connected (os error 107)
but it looked to me like it didn't really matter? I could still download my
text files. Note that when it started to log such messages, there were
actually quite a lot of those entries.
That is an interesting one... does it happen in the middle of the task
log? It almost looks like the VM stopped and ended the connection. Maybe
some intermittant network stuff?
* A few times I got in the PVE GUI when I clicked on ...img.fidx
malformed JSON string, neither tag, array, object, number, string or atom, at character
offset 0 (before "VM 'qemu_root\\x40pa...") at
/usr/share/perl5/PVE/PBSClient.pm line 220. (500)
and I couldn't find out yet why and later it just didn't appear again.
Fixed with 6ea6324bd6cc in proxmox-backup.
* This is helpful
executable not found '/usr/bin/proxmox-file-restore'! Proxmox backup client or
file restore not installed? (500)
but the precise package name would make it even more helpful for me.
proxmox-backup-file-restore
True. Do we have that as a dependency actually, or is it like with
ifupdown2 where the user has to install it manually?
Today I also tried around with existing options of restoring data with the
backup client (CLI).
And even with the previous concerns, I think that in comparison to those CLI
possibilities this
new feature makes exploring & restoring really, really convenient.
Tested-by: Dominic Jäger <d.jae...@proxmox.com>
Thanks for testing and the feedback!
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
