From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <d.jaeger@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id BCF7175A2C
 for <pve-devel@lists.proxmox.com>; Thu, 22 Apr 2021 12:39:38 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id B274E1A982
 for <pve-devel@lists.proxmox.com>; Thu, 22 Apr 2021 12:39:08 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS id 0FE8A1A978
 for <pve-devel@lists.proxmox.com>; Thu, 22 Apr 2021 12:39:08 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 7CEF445BBF
 for <pve-devel@lists.proxmox.com>; Thu, 22 Apr 2021 12:33:47 +0200 (CEST)
Date: Thu, 22 Apr 2021 12:33:45 +0200
From: Dominic =?iso-8859-1?Q?J=E4ger?= <d.jaeger@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 Stefan Reiter <s.reiter@proxmox.com>
Message-ID: <20210422103345.GA63060@mala>
References: <20210421111539.29261-1-s.reiter@proxmox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210421111539.29261-1-s.reiter@proxmox.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-SPAM-LEVEL: Spam detection results:  1
 AWL 1.120 Adjusted score from AWL reputation of From: address
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 KAM_LOTSOFHASH           0.25 Emails with lots of hash-like gibberish
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [pbsclient.pm]
Subject: Re: [pve-devel] [PATCH 00/10] Single-file-restore GUI for PBS
 snapshots
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2021 10:39:38 -0000

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.

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.


* Sometimes the Download button remains enabled when errors (like the previous)
  happen and then you get a couple of 0 byte files


* 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).


* 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.


* 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.


* 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


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.jaeger@proxmox.com>