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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[ T: only bump minor version for a plain re-build, to avoid that
users are getting their hopes up to much for a lot new features ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Otherwise, calling 'make dsc' after 'make deb' leads to the source
package having the additional files:
debian/.debhelper/
debian/pve-zsync.substvars
which lintian helpfully complains about.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
If one of the features lz4_compress, zstd_compress or large_blocks is
actively used/required by the source dataset, but not enabled on the
destination, zfs send/recv will fail and recommend upgrading the pool.
It's not required that the target dataset is also compressed.
Specifying '--properties' to have the target inherit the compression
property even works during later syncs (but pre-existing data won't be
recompressed automatically then).
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The old name is confusing, because "encode" is usually not used when
converting from text to a data structure.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
by introducing a new dest-maxsnap parameter which can be used to override
maxsnap for the destination side.
This is useful for backups, as one can potentially save a lot of space on the
source side (or the destination side if one can come up with a use case for
that) by keeping fewer snapshots around.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Also drop the 'method' parameter which is not used consistently (e.g. ignored
in the later half of the very same function, in snapshot_exist, vm_exists,...),
and not documented. Simply rely on the presence of the IP address as is done in
many other places already.
In snapshot_add, there is no need to try and destroy the snapshot on the
destination (did happen previously, because $dest was passed along), because we
just failed to create the snapshot on the source side.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Changing maxsnap to something smaller can lead to left-over snaphsots otherwise,
as previously at most one snapshot would be removed, even if there are multiple
old snapshots according to the new setting.
Hopefully nobody relied on the fact that pve-zsync didn't clean up after itself
in such cases...
Negative values and 0 for 'maxsnap' should still be interpreted as infinity to
match the previous behavior.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
format_job expects the value to be set, so creating a job with '--maxsnap 0' led
to '--maxsnap' being written without an argument, and thus a (for zsync)
unparsable cron file.
However, issuing sync jobs via CLI with '--maxsnap 0' works with 0 being treated
as unlimited. There is a default value, so no need to worry about definedness,
simply pass along the value.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
so that people get to read a short description before viewing the
rather large full command and option synopsis.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
so one can set up jobs for guests with disks with the same name on different
storages. For example,
storageA:vm-123-disk-0
storageB:vm-123-disk-0
will be synced to
target/storageA/vm-123-disk-0
target/storageB/vm-123-disk-0
when the flag is specified.
The necessary parent file systems (one per storage ID) are created as needed.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
It's not possible to provide a false value. From the documentation for
GetOptionsFromArray:
The argument specification is optional. If omitted, the option is considered
boolean, a value of 1 will be assigned when the option is used on the
command line.
Make it clear that specifying the flag alone already enables it.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
by remembering the process via PID+start time+boot ID and checking for that
information in the new instance. If the old instance can't be found, the new
one will continue and register itself in the state.
After updating the pve-zsync package, if there is a waiting instance running the
old version, one more might be created, because there is no instance_id yet. But
the new instance will set the instance_id, which any later instance will see.
More importantly, if the state is wrongly 'waiting' or 'syncing', i.e.
because an instance was terminated before finishing, we don't abort anymore and
recover from the wrong state, thus fixing the bug.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
