Weaviate expiry visibility versus deletion
Does hiding expired Weaviate objects from queries establish that TTL deletion ran?
The pinned Weaviate TTL documentation separates expiry from scheduled deletion. The OBJECTS_TTL_DELETE_SCHEDULE setting enables the background deletion schedule; without it expired objects are not deleted. Query exclusion can hide expired objects before that deletion. A query with no expired results therefore does not establish that the deletion job ran or that residual copies were removed.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Deletion execution and backup disposition remain unobserved.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate bounded bulk deletion
Can one successful Weaviate filter deletion remove every matching object?
The pinned Weaviate deletion guide limits a multi-object deletion to QUERY_MAXIMUM_RESULTS, whose documented default is 10,000. It instructs callers to repeat deletion until no matching objects remain; deletion order is by UUID. Dry-run counts and verbose per-object outcomes are available. A successful bounded batch alone does not establish exhaustion of the intended tenant and filter scope.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Concurrent writes and other copies were not assessed.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate absent-object delete acknowledgements
Does a successful Weaviate delete prove that the target object existed before deletion?
The pinned guide distinguishes deletion responses by replication topology. A missing ID on an unreplicated single shard with replication factor one returns 404, while replicated configurations can return success for a missing object. Client handling of 404 also differs. The acknowledgement must be interpreted with topology and client semantics; it does not reconstruct prior existence or establish deletion of every replica or backup.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual replica convergence and backup erasure are unknown.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate preview export scope
Does a successful Weaviate Parquet export include later writes and all tenants?
The pinned export guide describes a preview feature introduced in v1.37, disabled by default and unavailable in Weaviate Cloud. Its snapshot fixes the data and tenant list when export starts. Later writes and newly created tenants are outside that snapshot; HOT and COLD tenants are included while OFFLOADED tenants are skipped with shard status. A completion status needs reconciliation against that declared scope before an exit export is accepted.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Destination portability and buyer export completeness were not tested.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate deleted collections and dangling aliases
Does deleting a Weaviate collection automatically remove every alias that points to it?
The pinned collection-alias guide defines an alias as a routing pointer for object operations and queries. Removing it removes the pointer, not its target collection. Conversely, deleting a collection does not automatically remove its aliases. An alias change or disappearance is therefore routing evidence, not proof of collection deletion or a complete migration.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Residual collections, backups and destination contents are not established.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate per-object import failures
Can a completed Weaviate batch import conceal failed objects or references?
The pinned import guide permits individual objects to fail while other objects continue. It exposes per-object failures and client-specific error reporting, including failed objects and references after Python batching. Completion of the surrounding batch is not an all-records receipt. Migration acceptance needs submitted identifiers reconciled against per-object results and the intended reference graph.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Semantic equivalence of embeddings and references has not been verified.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate tenant offload initiation
Does the Weaviate offload timeout bound completion of tenant data transfer?
The pinned tenant-offloading documentation describes OFFLOAD_TIMEOUT as a limit for starting the offload operation, with a documented default of 120 seconds. Transfer proceeds asynchronously after initiation. That setting is not a maximum transfer duration, nor does successful initiation establish that the tenant data reached the offload destination.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Transfer duration, destination completeness and source residuals remain unobserved.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate incremental restore dependencies
Can an older Weaviate full backup be deleted while dependent incremental backups are retained?
The pinned backup guide states that incremental backups can reference unchanged files in earlier backups, including through a chain of incremental bases. Restore follows the chain to obtain those files. Every base and intermediate backup on which a retained backup depends must therefore remain available. Keeping only the newest incremental archive is not evidence of an independently restorable copy.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No actual dependency graph or restore was tested.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate redacted backup dependency metadata
Does an empty Weaviate backup base ID prove that a backup is full?
The pinned guide says the list-side incremental_base_backup_id field, introduced in v1.37.6, is only populated for a confirmed root user. Other callers receive an empty value even when a backup is incremental and they otherwise have backup permissions. An empty list value is therefore ambiguous without caller identity and independent chain evidence; it cannot classify the backup as self-contained.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The actual caller role and backup dependency are unknown.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate restored data and omitted access configuration
Does restoring a Weaviate collection automatically restore its RBAC users and roles?
The pinned backup guide states that RBAC roles and users are not restored by default. The restore options rolesOptions and usersOptions default to noRestore; selecting all enables restoration, with those options documented from v1.32.0. A data restore must therefore be reconciled separately with the intended access configuration rather than treated as proof that previous authority boundaries were recreated.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Effective access after restore and source configuration completeness were not tested.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Weaviate restore cancellation boundary
Can a Weaviate restore still be cancelled once it reaches FINALIZING?
The pinned backup guide permits cancellation in STARTED, TRANSFERRING and TRANSFERRED, but not FINALIZING, when schema changes are being committed through Raft. CANCELLING and CANCELED are separate states. A cancellation request must therefore be reconciled with the operation phase and terminal result; it cannot be represented as a guaranteed rollback after finalisation begins.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No buyer cancellation, rollback or residual staged-data cleanup was observed.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic forgotten snapshots and retained data
Does restic forget immediately remove the backed-up file data from its repository?
In restic v0.19.1, forget removes snapshot references. Repository data no longer needed by retained snapshots is reclaimed by prune, which checks remaining references and may repack partly used files. Data still referenced by another snapshot remains needed. Removing a snapshot reference is therefore distinct from repository reclamation and from physical erasure by the underlying storage service.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Underlying media erasure, provider replicas and other repositories are not established.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic retention grouping
Does restic keep-last apply one retention count across every backed-up host and path?
restic v0.19.1 groups snapshots by host name and paths before applying a retention policy independently to each group. group-by can change those keys or disable grouping, while host and tag filters further restrict selection. A keep count without its grouping and filtering context cannot establish which backup sets were retained or removed.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No buyer retention selection or legal retention requirement was evaluated.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic retention window anchor
Is restic keep-within measured back from the time the retention job runs?
The v0.19.1 retention guide measures keep-within against the latest snapshot, rather than simply the current wall clock. Calendar keep options count periods containing snapshots and use natural boundaries; future-dated snapshots are ignored by duration-related options and are not removed by them. An apparently old snapshot set therefore needs its timestamps and policy basis reconciled before declaring a retention breach or deletion completion.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The accuracy of snapshot timestamps and buyer policy applicability are unknown.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic append-only retention decisions
Does an append-only restic repository prevent a compromised writer from influencing later retention?
The v0.19.1 guide warns that an append-only writer can add misleading snapshots whose timestamps displace legitimate snapshots under some count or calendar retention policies when an administrator later runs forget. It recommends separate secured maintenance access and a keep-within policy, while documenting that protection still depends on the retention window and correct time. Append-only access alone does not validate the snapshots chosen for retention.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No compromise, attack or buyer repository integrity was independently assessed.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic structural checks and payload reads
Does a successful default restic check verify every stored backup payload byte?
restic v0.19.1 distinguishes the default repository-structure check from reading actual pack data. check --read-data reads all packs, while data-subset options limit that work. A successful default check therefore supports structural consistency within its checks, not a claim that every stored data payload was read or that an application restore succeeded.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Application recoverability and all payload contents were not verified here.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic sampled integrity coverage
Do repeated random restic data-subset checks guarantee that every pack has been inspected?
The v0.19.1 guide allows a fixed n/t subset partition or a random percentage/size subset for pack-data checking. Repeating random subsets does not guarantee complete repository coverage, even across many runs. A partitioned plan can cover the specified partitions, but its receipts and repository scope must be retained rather than inferred from the number of successful random checks.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual coverage of a changing buyer repository is not known.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic snapshot selection versus restored scope
Does restic restore --path restrict restoration to only that path inside the snapshot?
The restic v0.19.1 restore guide says --path selects a snapshot and does not restrict which files inside it are restored. A snapshot selected by one path can contain other paths that are also restored. File-scope selection instead uses include/exclude options or snapshot:subfolder syntax, with filter paths interpreted relative to that selected subfolder.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual restored content and authorisation were not inspected.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic restore content shortcuts
Does restic restore --overwrite if-changed compare all existing file bytes before deciding they match?
The v0.19.1 guide says if-changed assumes files with matching size and modification time are current, checking full content when those attributes differ. The default always mode verifies existing content and restores mismatching parts. Interrupted in-place restoration can leave partial results. Matching metadata under if-changed therefore does not establish byte equality or completed recovery.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Target contents and restoration completeness remain unverified.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic recovery deletion scope
Does restic restore --delete remove every extra file from the entire target tree?
The v0.19.1 guide defines --delete as removal of target files absent from the snapshot within the selected restore scope. Include/exclude options restrict which files or directories are subject to deletion. Using --target with --delete requires an include or exclude option, and the guide recommends a verbose dry run. Completion cannot establish removal of extras outside that selected scope.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No cleanup operation or residual file inventory was examined.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
restic Windows security descriptor restoration
Does restoring files with restic on Windows always restore their complete security descriptors?
The v0.19.1 restore guide requires SeRestorePrivilege, SeSecurityPrivilege and SeTakeOwnershipPrivilege, or administrator operation, for full Windows security-descriptor restoration. Without all required privileges only the DACL is restored. Symlink restoration has a separate privilege requirement. File-content recovery alone therefore does not establish equivalent security metadata on the destination.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Effective destination permissions and audit configuration were not tested.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero existing resources and volume data
Does Velero existing-resource-policy update restore the data in an existing persistent volume?
The v1.18.4 restore guide limits existing-resource update to Kubernetes resource data such as its spec. It explicitly says PVC update does not restore or overwrite the PV data. Updates are best effort; a failed patch can produce a warning and fall back to non-destructive handling without failing the restore. Restore labels or a completed workflow therefore do not establish that volume contents were recovered.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual volume recovery and application consistency are unknown.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero ServiceAccount merge exceptions
Does Velero default non-destructive restore leave every existing ServiceAccount unchanged?
The v1.18.4 guide documents ServiceAccounts as an exception to default existing-resource skipping. Velero attempts to merge backed-up fields into an existing ServiceAccount, appending Secrets and ImagePullSecrets and adding absent labels and annotations while retaining existing ones. Default non-destructive restore is therefore not a promise that every existing identity configuration is untouched.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Referenced secret contents and effective authorisation were not assessed.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero restored status fields
Does Velero restore the status of every Kubernetes object along with its spec?
The v1.18.4 guide says status is removed by default before object restoration because controllers typically reconcile it. Selected resource types or object annotations can request status restoration, which requires a separate update after creation. A restored spec therefore cannot stand in for retained status history, and restored historical status alone does not establish current runtime health.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Buyer controller behaviour and actual health remain unknown.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero backup TTL and deletion failures
Does reaching a Velero backup TTL prove that its backup files and snapshots were deleted?
The v1.18.4 guide applies expiry through the garbage-collection controller, whose documented default reconciliation interval is one hour. Expiry targets the backup resource, object-storage backup file, PV snapshots and associated restores. Failed deletion can be labelled with reasons including an unavailable or read-only backup storage location. A passed TTL alone does not establish successful removal of those objects.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Provider residual copies and successful deletion of a buyer backup were not verified.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero backup records and object storage
Does deleting a Kubernetes Velero Backup object establish removal of its object-storage archive?
The v1.18.4 guide treats object storage as the source of truth and synchronises properly formatted stored backups back into missing Kubernetes Backup resources. A Completed resource missing its archive is removed from Kubernetes; Failed and PartiallyFailed resources are not removed by that sync rule. Resource presence or absence alone therefore does not establish the corresponding archive disposition.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Underlying archive retention and physical erasure remain unobserved.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero live-filesystem consistency
Does Velero File System Backup capture all files at a single atomic point in time?
The v1.18.4 File System Backup guide describes beta-quality support that reads the live filesystem rather than taking a single storage snapshot. Files are consequently not captured at the same point in time. Suitability for a stateful application depends on its consistency controls and recovery validation, not only a successful transfer of files.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Application consistency and recoverability were not tested.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero volume backup mechanism coverage
Does enabling Velero File System Backup also produce a native snapshot of the same volume?
The v1.18.4 guide states that File System Backup and native/CSI snapshots are mutually exclusive for the same volume. When FSB runs, the snapshot is skipped; opting out of FSB allows a snapshot attempt if configured. Neither a global feature setting nor an opt-out establishes that both mechanisms completed, so recovery coverage must be mapped per volume to its actual backup result.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No buyer volume inventory or backup artifact was inspected.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero backup repository password changes
Can changing the Velero repository credential secret after the first backup preserve access to earlier backups automatically?
The v1.18.4 FSB guide says the backup repository is created on the first backup targeting it and the custom repository password should be set before that operation. Changing the secret password after repository creation prevents Velero from connecting to older backups. Editing the Kubernetes secret is therefore not documented as an automatic re-encryption or password migration of existing archives.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No password, key material or buyer restore was accessed.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero backup API-version compatibility
Can Velero restore a resource when the target cluster lacks the API version used in the backup?
The v1.18.4 guide backs up resources using the source Kubernetes API server preferred version for each group/resource. That same API group/version must exist on the target for restoration; it need not be the target preferred version. A target cluster exposing a different version of the resource does not by itself establish compatibility.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Conversion behaviour or a buyer migration was not independently tested.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Velero backup hooks and consistency evidence
Does a Velero backup completing establish that its pre-backup consistency hook succeeded?
The v1.18.4 hook guide allows Fail or Continue handling for non-zero hook exit codes, with Fail as the default, and treats a hook exceeding its timeout as an error. The documented default timeout is 30 seconds. A backup configured to continue after a hook error needs the hook result reconciled separately before it can support an application-consistency claim.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The hook command effect and application state were not observed.
- No independently verified physical deletion, complete recovery, legal compliance or security assurance.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review