Lukas Wagner [Thu, 19 Jan 2023 15:52:32 +0000 (16:52 +0100)]
api: serde-rename deleteable properties to kebab-case
In former commit, the enum members were renamed to be CamelCase, in
accordance with the usual Rust style guide. However, this broke the
GUI in some places due to failing JSON property deserialization.
To fix this, some serde(rename = "kebab-case") directives were added.
Some properties were also serde-renamed to snake_case, otherwise
it would have been necessary to also modify proxmox-widget-toolkit
as well as PVE source code. This can follow in a later commit if so
desired.
`proxmox-backup-client task log ..` and `proxmox-backup-manager task log ..`
are used to view the logs of tasks that have been started by another client, so
interrupting the task progress view should not forward the interrupt to the
running task. other call sites of the same helper(s) that spawn a task and then
print its progress should keep the old behaviour of interrupting the spawned
task on C^c.
Dominik Csapak [Mon, 16 Jan 2023 08:21:44 +0000 (09:21 +0100)]
fix #4466: show snapshots in media content again
while refactoring the the empty media set checks, we accidentally
reversed one check from !is_empty to unassigned, which now never
included the right media sets.
reversing the condition fixes that.
fixes 52517f7b: ("tape: hide internal use of all zero uuid for unassigned tapes")
Fiona Ebner [Thu, 5 Jan 2023 10:19:32 +0000 (11:19 +0100)]
http client: suppress "storing login ticket"-error when not using a TTY
as a stop-gap measure. Otherwise, task logs for PVE backups started
via non-CLI will have the message
> storing login ticket failed: $XDG_RUNTIME_DIR must be set
show up when running a proxmox-backup-client command (e.g. setting
notes and when uploading the log). This is confusing to users[0].
Dominik Csapak [Tue, 29 Nov 2022 08:16:11 +0000 (09:16 +0100)]
disk: zfs: improve error logging for zfs commands
zfs errors might include a newline in the output (e.g. when trying to
create a mirror on two differently sized disks), which trips up our
task log status parser since that expectes a 'TASK {status}' on the
beginning of the first line.
print the error from zfs into the log and bail out with a short notice
to check the task log
this fixes the 'unknown error' issue in the ui when an error happnes
during the zfs commands
Christoph Heiss [Mon, 12 Dec 2022 14:10:56 +0000 (15:10 +0100)]
fix #4346: pbs-client: don't fail silently when storing ticket
Instead, report an error if storing the ticket info failed, so that the
user is informed that something went wrong and follow-up commands might
require authentication again.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
similar to what's done in the proxmox repo/workspace, to avoid them getting out
of sync. before this change, the recently introduced pbs-key-config was
missing.
these are only used by a single member at the moment, but we can move them to
the workspace to have a single location for version + base feature set
specification.
besides harmonizing versions, the only global change is that the tokio-io
feature of pxar is now implied since its default anyway, instead of being
spelled out.
Lukas Wagner [Fri, 9 Dec 2022 11:14:25 +0000 (12:14 +0100)]
debug cli: add colored output for `diff archive`
This commit adds the `--color` flag to the `diff archive` tool.
Valid values are `always`, `auto` and `never`. `always` and
`never` should be self-explanatory, whereas `auto` will enable
colors unless one of the following is true:
- STDOUT is not a tty
- TERM=dumb is set
- NO_COLOR is set
The tool will highlight changed file attributes in yellow.
Furthermore, (A)dded files are highlighted in green,
(M)odified in yellow and (D)eleted in red.
Lukas Wagner [Fri, 9 Dec 2022 11:14:23 +0000 (12:14 +0100)]
debug cli: show more file attributes for `diff archive` command
This commit enriches the output of the `diff archive` command,
showing pxar entry type, mode, uid, gid, size, mtime and filename.
Attributes that changed between both snapshots are prefixed
with a "*".
For instance:
$ proxmox-backup-debug diff archive ...
A f 644 10045 10000 0 B 2022-11-28 13:44:51 add.txt
M f 644 10045 10000 6 B *2022-11-28 13:45:05 content.txt
D f 644 10045 10000 0 B 2022-11-28 13:17:09 deleted.txt
M f 644 10045 *29 0 B 2022-11-28 13:16:20 gid.txt
M f *777 10045 10000 0 B 2022-11-28 13:42:47 mode.txt
M f 644 10045 10000 0 B *2022-11-28 13:44:33 mtime.txt
M f 644 10045 10000 *7 B *2022-11-28 13:44:59 *size.txt
M f 644 *64045 10000 0 B 2022-11-28 13:16:18 uid.txt
M *f 644 10045 10000 10 B 2022-11-28 13:44:59 type_changed.txt
Also, this commit ensures that we always show the *new* type.
Previously, the command showed the old type if it was changed. Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
it's used by pxar-bin and proxmox-backup-client for
mounting, but pbs-client is used by more (eg. the
proxmox-backup-qemu library which really doesn't need to
pull in any fuse dependencies)
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Dominik Csapak [Tue, 29 Nov 2022 14:17:01 +0000 (15:17 +0100)]
tape: inventory: skip unassigned tapes
tapes that are labeled into a pool but are not in a media-set yet, belong
to the special 'all zero' media-set. these will never have a catalog on them,
so skip them
fixes the issue, that an inventory with 'catalog restore' aborted on
such a tape
Dominik Csapak [Tue, 29 Nov 2022 14:17:00 +0000 (15:17 +0100)]
tape: hide internal use of all zero uuid for unassigned tapes
a tape assigned to a pool but no media-set, gets the special 'all zero'
media set in it's MediaSetLabel. Instead of having that constant
scattered all over the code, hide this fact by using wrapper functions
to initialize it that way and to check for it
Thomas Lamprecht [Mon, 28 Nov 2022 16:03:39 +0000 (17:03 +0100)]
d/postinst: try to fixup installations with wrong .datastore.lck owner
Must be a rather ancient installation in that case as we create
new lockfiles with backup:backup since a while.
Note that this wasn't all to relevant until recently when we fixed a
TOCTOU for maintenance mode check by locking on datastore create,
which happens in the unpriv. proxy daemon too, e.g., for the
datastore status call.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Mon, 28 Nov 2022 13:00:14 +0000 (14:00 +0100)]
ui: datastore options: use new onSetValues over setValues
The `onSetValues` (pedant to `onGetValues`) got added relatively
recently to widget toolkits input panel. Using it avoids the need to
hard-code some "dynamic override" calling semantics.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Noel Ullreich [Fri, 25 Nov 2022 12:10:34 +0000 (13:10 +0100)]
docs: add section on ransomware and PBS help against it
Added a section on ransomware. This includes a bullet point in the
main features section and a section in the backup storage section.
The latter section lists mitigation resources in pbs as well as best
practices.
Updated capitalization to be consistent in main features. Imo, since
these are bullet points and not headings, they should be in lowercase
Signed-off-by: Noel Ullreich <n.ullreich@proxmox.com> Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com> Reviewed-by: Stefan Sterz <s.sterz@proxmox.com>
Dominik Csapak [Fri, 4 Nov 2022 09:49:34 +0000 (10:49 +0100)]
datastore: make 'filesystem' the default sync-level
rationale is that it makes the backup much safer than 'none', but does not
incur a big of a performance hit as 'file'.
here some benchmark:
data to be backed up:
~14GiB semi-random test images between 12kiB and 4GiB
that results in ~11GiB chunks (more than ram available on the target)
PBS setup:
virtualized (on an idle machine), PBS itself was also idle
8 cores (kvm64 on Intel 12700k) and 8 GiB memory
all virtual disks are on LVM with discard and iothread on
the HDD is a 4TB Seagate ST4000DM000 drive, and the NVME is a 2TB
Crucial CT2000P5PSSD8
i tested each disk with ext4/xfs/zfs (default created with the gui)
with 5 runs each, inbetween the caches are flushed and the filesystem synced
i removed the biggest and smallest result and from the remaining 3
results built the average (percentage is relative to the 'none' result)
So all in all, it does not seem to make a difference for nvme drives,
for hdds 'filesystem' increases backup time by ~10%, while
for 'file' it largely depends on the filesystem, but always
in the range of factor ~3 - ~4
Note that this does not take into account parallel actions, such as gc,
verify or other backups.