IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
we use 'enable' property here with a default of true, so change
the dataIndex and the renderer to reflect that
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>
instead of hardcoding the default deep inside the code. This makes it
much easier to see what is the actual default
the first instance of ChunkOrder::None was only for the test case, were
the ordering doe not matter
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>
Add a simple edit window with 2 combo boxes for `sync-level` and
`chunk-order`.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ T: rework commit message/subject a bit ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this section needs general rework/expansion but to be able to link to
it already now add a reference and only do a minimal title update.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
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)
result:
test none filesystem file
hdd - ext4 125.67s 140.39s (+11.71%) 358.10s (+184.95%)
hdd - xfs 92.18s 102.64s (+11.35%) 351.58s (+281.41%)
hdd - zfs 94.82s 104.00s (+9.68%) 309.13s (+226.02%)
nvme - ext4 60.44s 60.26s (-0.30%) 60.47s (+0.05%)
nvme - xfs 60.11s 60.47s (+0.60%) 60.49s (+0.63%)
nvme - zfs 60.83s 60.85s (+0.03%) 60.80s (-0.05%)
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.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we can still do that as notifications for prune jobs weren't released
yet.
We may want to evaluate if we adapt (some) other notification types
too on next major release.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
under some conditions, the smartctl exitcode sets bit 2, even if the
smartctl call succeeded, but has e.g. some warnings derived from the
attributes
we do the same in pve, but it is only the first step in fixing #4353, since
we probably should parse the smartcl output better to include
such warnings
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
