Conversation
gabriele-wolfox
force-pushed
the
dev/126
branch
5 times, most recently
from
August 31, 2026 07:48
c1b9f04 to
e424a8d
Compare
armru
force-pushed
the
dev/126
branch
2 times, most recently
from
September 2, 2026 11:07
1a8f9c7 to
e06c0f8
Compare
armru
approved these changes
Sep 2, 2026
jbattiato
force-pushed
the
dev/126
branch
2 times, most recently
from
September 7, 2026 09:10
63b598e to
f798f4b
Compare
jbattiato
approved these changes
Sep 7, 2026
fcanovai
force-pushed
the
dev/126
branch
2 times, most recently
from
September 9, 2026 15:46
43513fb to
0829176
Compare
fcanovai
approved these changes
Sep 9, 2026
Kopia repositories were created without a compression policy, so base backup data was stored uncompressed. Allow users to configure a compression policy repository-wide on the Server (applied to the global Kopia policy at server start) and per-cluster on the PluginConfiguration (applied to the cluster's own source, overriding the global policy). Both tier1 and tier2 are covered: tier1 is set through the Kopia server during the backup, while tier2 travels over gRPC and is applied by the backup consumer before the relay. The policy exposes the compression algorithm plus the optional minSize and maxSize bounds (in bytes) that restrict which files are compressed. Kopia's only-compress and never-compress extension lists are left out on purpose: they select files by extension, which does not fit a PostgreSQL data directory (relation files are numeric and carry no meaningful extension), and WAL files are compressed on a separate path regardless. Closes #126 Assisted-by: Claude Signed-off-by: Gabriele Quaresima <gabriele.quaresima@enterprisedb.com>
The policy builder emitted `--compression-min-size` and `--compression-max-size` only for non-zero values, so a bound written to the Kopia repository could never be removed: no value of the configuration field produced a flag that reset it, and files outside the stale range silently stayed uncompressed. Both bounds are now always emitted, with zero rendered as `inherit`, which Kopia resets to the value inherited from the parent policy. Document that removing the whole `compression` section still leaves the stored policy in place, and that `algorithm: none` is the way to stop compressing. Refs #126 Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
A `minSize` above a non-zero `maxSize` matches no file at all: Kopia accepts the policy and then skips compression for every file, so the resource reported compression as enabled while nothing was compressed. The range is now validated in the client policy, in the tier1 and tier2 server configuration, and through a CEL rule on the shared CRD type, so an inconsistent range is refused at admission. The check runs even when no algorithm is set, because the size bounds are applied independently of it. Refs #126 Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
CompressionServerConfig duplicated CompressionPolicy field-for-field in both core/pkg/config and operator/pkg/config, with only the algorithm validation and IsZero helper split unevenly between the two. Reuse CompressionPolicy for Tier1Config/Tier2Config.Compression in both modules instead, closing a sync gap between the two copies. Assisted-by: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Kopia's `--compression` flag accepts `inherit` just like the size bound flags do, resetting the stored value so the source falls back to its parent (or the repository default). buildCompressionPolicyArgs only used this for the size bounds, omitting the flag entirely for an empty algorithm, so a previously-set per-source or global override could never be cleared once written. Send `--compression=inherit` too when the algorithm is unset, and always apply the tier1/tier2/global compression policy instead of skipping the call when the configured policy is zero-valued. Removing a `compression` section now correctly resets that policy to inherit from its parent on the next backup (or server start, for the global policy), rather than leaving the last applied policy stuck in the repository. Drops the now-unused CompressionPolicy.IsZero helpers this uncovered. Assisted-by: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
…ly servers A read-only server requires tier2 but never takes backups, so it has no business writing to the shared tier2 global compression policy. Two gaps allowed it to anyway: - The CRD had no rule stopping tier2.compression from being set when mode is read-only, unlike tier1 and queue which are already forbidden in that mode. - applyGlobalCompressionPolicy for tier2 ran whenever tier2 was enabled, regardless of mode. Combined with the previous commit always applying the policy (even when unconfigured, to reset it to inherit), a read-only server would reset the shared tier2 global policy on every restart, clobbering whatever the tier1-enabled server that actually owns backups had configured. Add a CEL validation rule rejecting tier2.compression when mode is read-only, and gate the tier2 compression apply on tier1 being enabled so a read-only server never touches it, set or not. Assisted-by: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
…guration A read-only PluginConfiguration already forbids tier1 and requires tier2.enableBackup to be false, so no backup is ever taken from such a cluster. tier2.compression was still settable despite being dead config: it can never be applied, since backup run requires the tier1 client section (absent in read-only mode) before it ever reaches compression, and the cnpgi tier2 backup capability is disabled by the same enableBackup flag. Add a CEL validation rule rejecting it, matching the equivalent rule just added for the Server CRD's tier2.compression. Assisted-by: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
The compression feature provisions its own isolated namespace, RustFS bucket, and Klio Server per run, so it shares no state with other parallel e2e features and doesn't need to run serially. Signed-off-by: Francesco Canovai <francesco.canovai@enterprisedb.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds Kopia compression policy configuration for base backups, both per-server and per-cluster, covering tier1 and tier2 independently.
Closes #126.