@astandrik/local-ydb-mcp
Unofficial stdio MCP server for operating Docker-based local-ydb deployments.
Website: local-ydb-toolkit.ydb-qdrant.tech.
Relationship to ydb/ydb-mcp
This package is complementary to the official ydb-platform/ydb-mcp server. Use ydb/ydb-mcp for general YDB database-level tools such as ad hoc SQL queries, query explanations, directory listing, and path inspection against an existing YDB endpoint.
Use @astandrik/local-ydb-mcp when an agent needs to operate Docker-based local-ydb environments themselves: host prerequisite checks, root or tenant bootstrap, database healthcheck diagnostics, dynamic-node lifecycle, GraphShard checks, table DDL generation/validation/application for local deployments, auth hardening, storage workflows, dump/restore, and version upgrades. Its local_ydb_sql tool is deliberately narrower than ydb/ydb-mcp: it runs managed YQL only against the selected configured local-ydb profile. Mutating tools are plan-first and require confirm: true before they execute changes.
MCP Client Config
This package requires Node.js 20.19 or newer.
Use npx so clients can run the server without a manual checkout:
{
"mcpServers": {
"local-ydb": {
"command": "npx",
"args": ["-y", "--prefer-online", "@astandrik/local-ydb-mcp@latest"],
"env": {
"LOCAL_YDB_TOOLKIT_CONFIG": "/path/to/local-ydb.config.json"
}
}
}
}
This form checks the npm registry when the MCP server starts, so clients pick up newly published versions after restarting the MCP client.
The config file is optional. If LOCAL_YDB_TOOLKIT_CONFIG is not set, the server reads local-ydb.config.json from the current working directory. A present but empty environment value is explicit and returns CONFIG_PATH_NOT_ABSOLUTE. If the implicit file is absent, the server uses a default local profile with ghcr.io/ydb-platform/local-ydb:stable-26-1-1. LOCAL_YDB_TOOLKIT_CONFIG and per-call configPath values must be absolute and must name a readable regular JSON file no larger than 1 MiB. The configured defaultProfile must name an existing profiles entry. Missing, unreadable, oversized, malformed, or schema-invalid explicit files fail closed and return a stable error code without exposing file contents, parser snippets, or the absolute path.
The named upstream default tag is mutable. Set profiles.<name>.image explicitly to control upgrades; use a digest for immutable pulls, noting that local_ydb_upgrade_version does not accept digest-pinned source profiles.
After a package update changes the implicit default, an existing stack created with the previous default will fail the profile compatibility check instead of mixing YDB images. Add the stack's current image reference to a file-backed profile before restart or bootstrap, then use local_ydb_upgrade_version for an intentional dump-and-rebuild upgrade.
Official MCP Registry metadata uses the name io.github.astandrik/local-ydb-mcp and is published from the repository root server.json after the matching npm version is available.
MCP Features
The server exposes local-ydb operation tools and static MCP prompts. Prompt
templates guide stack diagnosis, root database bootstrap, tenant topology
bootstrap, database diagnostics, schema generation/apply, version upgrades,
auth hardening, and storage group reduction. Prompts return workflow instructions only; they do not
execute commands. A prompt configPath, when supplied, must be an absolute path
just like the corresponding tool argument.
Mutating tools remain plan-only unless called with confirm: true.
The server exposes 39 tools. This index is generated from the runtime tool registry; edit toolDefinitions and run npm run docs:generate to update it.
Checks
| Tool | Mode | Description |
|---|
local_ydb_inventory | read-only | Read-only Docker inventory for a local-ydb target profile. Success returns ok=true, Docker CLI/daemon state, containers, volumes, and inspect data for configured containers that actually exist; Docker CLI, daemon, or inventory failures return ok=false with a reason and omit inventory arrays so failure cannot be mistaken for an empty host. SSH target or probe failures use docker-inventory-failed with conservative Docker availability flags. |
local_ydb_database_status | read-only | Read-only YDB admin database status for the configured tenant path. Returns the command, stdout, stderr, and ok flag; use this for tenant state before bootstrap/restart troubleshooting, and use local_ydb_tenant_check for scheme reachability. |
local_ydb_healthcheck | read-only | Read-only YDB monitoring healthcheck for the configured tenant or root database. Uses the official YDB CLI SelfCheck path, returns selfCheckResult, issue counts, issue types, capped raw output, and whether the database is healthy; a requested noCache/noMerge option rejected with the exact recognized two-line legacy parser signature is reported through optionResolution and warnings, while compatibilityFallback says whether a retry actually started. Use after local_ydb_status_report for database-level diagnostics. |
local_ydb_container_logs | read-only | Read recent Docker logs from the configured static or primary dynamic local-ydb container. Use when bootstrap, restart, or readiness checks fail; target selects the container role and lines controls the tail length. |
local_ydb_status_report | read-only | Read-only aggregate report for quick diagnosis. Runs local_ydb_inventory, local_ydb_auth_check, local_ydb_tenant_check, local_ydb_nodes_check, and local_ydb_healthcheck, returning each result; every component is isolated so an unexpected failure produces a safe component-shaped fallback and does not stop the remaining checks. |
local_ydb_tenant_check | read-only | Read-only check that uses the YDB CLI to verify the configured tenant path is reachable. Use after bootstrap or restore to confirm tenant metadata before node or GraphShard checks. |
local_ydb_scheme | read-only | Read-only YDB scheme list or describe with capped stdout/stderr. It uses the root database for rootDatabase paths and the tenant database otherwise; list supports recursive/long/onePerLine flags, describe supports stats, and incompatible flag combinations are rejected. |
local_ydb_nodes_check | read-only | Read-only check of dynamic node registration through viewer/json nodelist. Use after starting, adding, or removing dynamic nodes; use local_ydb_tenant_check first when tenant reachability is unknown. |
local_ydb_graphshard_check | read-only | Read-only GraphShard check through viewer/json capabilities and tabletinfo for the configured tenant. Returns graphShardExists, tablet ids, and viewer status details; use after tenant bootstrap when GraphShard support or tablet visibility is the specific question. |
local_ydb_auth_check | read-only | Read-only auth audit that checks anonymous viewer whoami status and configured YDB CLI tenant access, using root credentials when rootPasswordFile is configured. Use after auth hardening or password rotation to verify the expected posture. |
local_ydb_storage_placement | read-only | Read-only storage inspection that returns ReadStoragePool output and BSC physical placement. Use before adding or reducing storage groups to confirm the exact pool shape. |
local_ydb_storage_leftovers | read-only | Read-only search for candidate leftover local-ydb Docker volumes, dumps, and PDisk/data paths. It scans Docker volume names plus profile.storageSearchPaths and deletes nothing; use before local_ydb_cleanup_storage to decide exact paths or volumes to remove. |
local_ydb_list_versions | read-only | List published GHCR or Docker Hub tags for a local-ydb container image, with numeric version tags sorted newest first. Use before local_ydb_upgrade_version; registry pagination and authentication are restricted to trusted origins, and pageSize and maxPages bound pagination. |
local_ydb_pull_status | read-only | Check the status of a background Docker image pull started by local_ydb_pull_image. For known jobs it returns a monotonic progressPercent based on completed known Docker layers rather than bytes: 0-99 while running, 100 after successful completion, and the last observed value after failure. |
Schema
| Tool | Mode | Description |
|---|
local_ydb_generate_schema | read-only | Read-only structured YDB table DDL generator. It renders strict JSON specs for CREATE TABLE, ALTER TABLE, DROP TABLE, and secondary indexes, returns the generated script with official references and warnings, and can optionally validate through the YDB JS SDK without applying changes. |
local_ydb_apply_schema | plan-first mutation | Validate or apply YDB table DDL through the official YDB JS SDK. It accepts raw YQL DDL for PRAGMA plus CREATE TABLE, ALTER TABLE, and DROP TABLE; action=apply validates first and executes only with confirm=true. |
Sql
| Tool | Mode | Description |
|---|
local_ydb_sql | plan-first mutation | Run managed YQL v1 against the configured local-ydb target through Query Service. query uses SnapshotRO, explain returns plan/AST, and execute always runs EXPLAIN first and sends one NoTx execution only with confirm=true. |
Auth
| Tool | Mode | Description |
|---|
local_ydb_permissions | plan-first mutation | Inspect or change YDB scheme permissions for a path. The default list action is read-only; grant, revoke, set, clear, chown, and inheritance changes return a plan unless confirm=true. |
local_ydb_prepare_auth_config | plan-first mutation | Generate a hardened YDB config from the current static-node config. Use before local_ydb_write_dynamic_auth_config and local_ydb_apply_auth_hardening; without confirm=true this returns the planned write only. |
local_ydb_write_dynamic_auth_config | plan-first mutation | Write the text-proto dynamic-node auth token file needed for mandatory-auth startup. Use after choosing the SID for auth hardening; without confirm=true this returns the planned file write only. |
local_ydb_apply_auth_hardening | plan-first mutation | Apply a reviewed hardened YDB config file only after a full check-only static profile and configured-binding compatibility preflight succeeds before any config or container mutation; immutable mismatches require destroy followed by bootstrap. It then restarts the static node and recreates and verifies every configured dynamic node in index order even when no dynamic-node token file is configured. Exact-container running stability and IC registration must both pass before metadata verification, and rollback uses restart or bootstrap reconciliation after restoring the static config. Use only after preparing and reviewing the config; without confirm=true this returns the preflight/apply/recreate plan only. |
local_ydb_set_root_password | plan-first mutation | Rotate the runtime root password with ALTER USER and sync the host auth config and root password file to match. YDB may reject passwords that violate auth_config.password_complexity; this tool requires a non-empty password value. |
Storage
| Tool | Mode | Description |
|---|
local_ydb_add_storage_groups | plan-first mutation | Increase NumGroups for one tenant storage pool using the current ReadStoragePool definition. Without confirm=true this returns the DefineStoragePool plan, rollback, target pool, and target count; when the update succeeds it verifies NumGroups and tenant metadata. |
local_ydb_reduce_storage_groups | plan-first mutation | Reduce NumGroups for a tenant storage pool by dumping the tenant, rebuilding the profile stack with a smaller storagePoolCount, restoring the dump, and reapplying auth when needed. Before dump or destroy, it inspects every one-off dynamic node and preserves its exact gRPC, monitoring, and IC ports; an incomplete definition aborts the rebuild. |
local_ydb_cleanup_storage | plan-first mutation | Delete only the explicitly supplied local-ydb host paths or Docker volumes. Use after inspecting local_ydb_storage_leftovers; without confirm=true this returns the cleanup plan and removes nothing. |
Lifecycle
| Tool | Mode | Description |
|---|
local_ydb_pull_image | plan-first mutation | Plan or start a background Docker pull for a local-ydb image on the selected target. Without confirm=true it returns inspect and pull commands only; with confirm=true it returns a jobId for local_ydb_pull_status unless the image is already present. |
local_ydb_destroy_stack | plan-first mutation | Remove tenant metadata, local-ydb containers, network, and storage for a profile, with optional host-path cleanup. |
local_ydb_bootstrap_root_database | plan-first mutation | Bootstrap a plain local YDB database at /local with only a static node. Use for generic local database requests that do not need a CMS tenant, GraphShard, or dynamic nodes; an existing running or stopped static container is reused only when its image, network, data mount, complete port bindings, required environment, restart policy, and disabled healthcheck match the profile. Without confirm=true this returns the plan without executing it. |
local_ydb_bootstrap | plan-first mutation | Bootstrap a tenant topology: static node with GraphShard flags and loopback bindings for static plus every configured dynamic gRPC port, configured CMS tenant, and all dynamic nodes declared by profile.dynamicNodeCount. Before returning or executing a plan, configured container names must be distinct from the static container and all shared-network ports must be valid and unique. Nodes start in index order; before the next node starts, readiness requires the exact Docker container to be running, not restarting, stable by container ID and RestartCount across two checks, and registered by its IC port in viewer/json nodelist. An existing running or stopped static container is reused only after the full profile compatibility check, including every configured gRPC binding. Use only for tenant, GraphShard, dump/restore, or dynamic-node scenarios; without confirm=true this returns the full plan and creates nothing. |
local_ydb_check_prerequisites | plan-first mutation | Check target-host prerequisites for the Docker CLI and daemon, curl, ruby, and the configured rootPasswordFile when present. An unreachable SSH target returns unavailable=[target] without claiming tools are missing or proposing installation. Without confirm=true it returns the current snapshot and any apt-get plan; confirm=true may install only supported curl/ruby packages, then returns a refreshed post-install snapshot, and never starts or installs Docker. |
local_ydb_create_tenant | plan-first mutation | Create the configured CMS tenant when the static node is already running. Use before local_ydb_start_dynamic_node for tenant topologies; without confirm=true this returns the planned status/create command and creates nothing. |
local_ydb_start_dynamic_node | plan-first mutation | Start the configured primary dynamic tenant node for an existing CMS tenant. Before returning or executing a plan, it rejects a primary name that aliases the static container and ports that collide in the shared network namespace, including static IC port 19001. After checking that the image is present, it runs the full check-only static compatibility preflight, including the current image ID, immediately before the dynamic container start; a mismatch fails closed and requires destroy followed by bootstrap. The dynamic container is created but not started until its resolved image ID matches the static container, closing a concurrent named-tag refresh race. Use after local_ydb_create_tenant or when admin status is PENDING_RESOURCES; use local_ydb_add_dynamic_nodes for extra nodes. Without confirm=true this returns a plan only. |
local_ydb_restart_stack | plan-first mutation | Reconcile and restart the selected profile after inventory and a full check-only static compatibility preflight. Before stopping any container, require the existing static container to match the profile image, network, data mount, environment, restart policy, healthcheck, and exact loopback bindings for static gRPC, monitoring, and every configured dynamic gRPC port; configured binding changes require destroy followed by bootstrap. Then report missing configured and unexpected one-off dynamic containers, stop running dynamic containers before static, unconditionally recreate every configured node in index order including containers observed restarting, require each exact Docker container to be stably running plus registered by IC port, and restore only previously running unexpected containers without removing them. Because removed configured definitions cannot be recovered from inventory, rollback uses restart or bootstrap reconciliation. Without confirm=true this returns the restart plan only. |
local_ydb_upgrade_version | plan-first mutation | Upgrade a file-backed, volume-backed local-ydb profile to a target image tag. Use only for version upgrades on profiles without bindMountPath; before dump or destroy it inspects every one-off dynamic node and preserves its exact gRPC, monitoring, and IC ports, aborting on an incomplete definition. It then preflights source and target images, dumps, rebuilds, restores, reapplies auth when configured, recreates extra nodes, and performs final image verification. A verified mismatch leaves the profile unchanged; if final inventory is unavailable after successful rebuild phases, the response keeps command history, reports partial verification, and persists the target profile image. |
Dynamic Nodes
| Tool | Mode | Description |
|---|
local_ydb_add_dynamic_nodes | plan-first mutation | Add one-off dynamic tenant nodes beyond the declarative profile.dynamicNodeCount topology, one at a time. By default the first suffix is dynamicNodeCount + 1; an explicit startIndex must be greater than dynamicNodeCount, and port overrides remain available. Every planned name must be distinct from the static container and all configured plus one-off ports must be valid and unique in the shared network namespace. After each image-presence check, it repeats the full check-only static compatibility preflight, including the current image ID, immediately before each node start; a mismatch stops that node and all later nodes and requires destroy followed by bootstrap. Each dynamic container is created but not started until its resolved image ID matches the static container, closing a concurrent named-tag refresh race. Without confirm=true it returns container/port plans; with confirm=true each node must have a stable running exact Docker container and its IC port in viewer/json nodelist before tenant metadata is checked. |
local_ydb_remove_dynamic_nodes | plan-first mutation | Remove dynamic tenant suffix nodes one at a time and verify nodelist disappearance when the node IC port can be resolved. Without containers, nodeIds, or startIndex, only one-off suffixes above profile.dynamicNodeCount are eligible and the highest suffix is removed first. Explicit selectors or startIndex may remove a configured suffix and create drift that bootstrap or restart restores. Rollback guidance uses bootstrap/restart for configured nodes and add_dynamic_nodes with matching suffixes and ports for one-off nodes. The primary dynamicContainer is always protected. |
Backup Restore
| Tool | Mode | Description |
|---|
local_ydb_list_dumps | read-only | Read-only list of available tenant dumps under profile.dumpHostPath. Use before restore to choose a dumpName; it only reports top-level dump directories that contain the existing tenant dump folder. |
local_ydb_dump_tenant | plan-first mutation | Dump the configured tenant or a tenant-relative path using a local-ydb helper container on the static container network. It creates profile.dumpHostPath/dumpName, excludes .sys objects, writes the dump under dumpName/tenant, and without confirm=true returns the mkdir/helper-container plan only. |
local_ydb_restore_tenant | plan-first mutation | Restore the configured tenant or destination path from a dump under profile.dumpHostPath, with optional post-restore scheme describe and bounded count-query verification. Use after bootstrap or rebuild when the target tenant is ready; without confirm=true this returns the restore plan and does not write data. |
Managed SQL/YQL
local_ydb_sql uses YDB Query Service for managed YQL v1 against the selected configured local-ydb profile:
| Action | Behavior |
|---|
query (default) | Executes in SnapshotRO; confirm is ignored and never enables writes. |
explain | Uses Query Service EXPLAIN and returns a plan or AST without executing the YQL. |
execute without confirm=true | Runs the mandatory EXPLAIN preflight only and returns outcome: "planned". |
execute with confirm=true | After a successful preflight, sends exactly one NoTx execution. There are no automatic retries. |
The script must be well-formed Unicode and is limited to 1,048,576 characters; lone UTF-16 surrogates are rejected before hashing or protobuf encoding. One deadline covers connection, session, preflight, and execution: timeoutMs defaults to 120,000 and is capped at 600,000. maxRows defaults to 100 and is capped at 10,000 per result set, but the first row-limit hit stops all further result capture: read-only execution is cancelled, while confirmed NoTx execution drains without capturing later output. maxOutputBytes defaults to 65,536 and is capped at 1 MiB across captured issues, plan/AST, column metadata, and complete rows; partial JSON values are never returned.
Parameters use bare names matching [A-Za-z_][A-Za-z0-9_]*. The tool sorts names and prepends deterministic DECLARE $name AS Type; statements. Recursive descriptors support primitive/Decimal, Optional, List, Tuple, Struct, and Dict types, with limits of 100 parameters, depth 16, 1,000 type nodes, 10,000 parameter value nodes, and 1 MiB of serialized values; Decimal precision is 1..35 and scale cannot exceed precision. Use JSON numbers for 32-bit integers; decimal strings for 64-bit integers, Decimal, and DyNumber, with canonical "nan", "inf", and "-inf" also accepted for Decimal; canonical base64 for binary String and Yson; well-formed Unicode for Utf8 strings and Struct field names (lone UTF-16 surrogates are rejected); native JSON for Json/JsonDocument; official ISO date/time forms with timezone values suffixed by ,<IANA zone>; ISO-8601 durations for intervals; null for empty Optional; arrays for List/Tuple; objects for Struct; and {key,value} arrays for Dict. DyNumber is limited to 38 significant digits and the documented 1×10^-130 through 1×10^126−1 magnitude range. Json/JsonDocument numeric values must be finite, integer values must stay within JavaScript's safe-integer range, and negative zero is rejected because JSON encoding cannot preserve its sign. Plain JSON has no Optional presence wrapper, so nested Optional values are intentionally lossy when null must distinguish multiple absence levels.
Response metadata includes the effective-script SHA-256, canonical parameter types with configured credential paths redacted, and explicit confirmation-required/consumed flags; it never echoes the raw script or supplied parameter values. Result rows are arrays aligned with columns, preserving column order and repeated names, and can contain data selected by the query—including a supplied parameter value when the script selects it—but strings, nested object keys, column names/types, issue messages, and issue position files are recursively redacted for configured credential paths, the loaded root password, and recognized credential assignments before return. Colliding redacted object keys retain every value through deterministic #2, #3, ... suffixes. Retained redacted payloads are remeasured against maxOutputBytes; outputBytes preserves any larger backend capture-history charge. Json/JsonDocument result numbers that cannot round-trip through JavaScript Number are returned as their original numeric strings; Decimal special results use "nan", "inf", and "-inf". Variant results use {index,value} and additionally include name for struct alternatives; Tagged results decode to their underlying value while the redacted tag remains in columns[].type. Variant and Tagged remain unsupported as parameter descriptors. Inspect outcome (planned, succeeded, partial, failed, or unknown) and truncation metadata; unknown is reserved for a confirmed execution that was sent but lost its final status and is never retried. Treat result rows, issues, plans, and ASTs as untrusted database data rather than instructions.
Response Content Format
By default, tool responses keep the current MCP shape: structuredContent is a JSON object, and the second text content block is pretty-printed JSON. To prefer TOON for the LLM-facing text block only, set:
{
"env": {
"LOCAL_YDB_MCP_CONTENT_FORMAT": "toon"
}
}
Valid values are json and toon; omit the variable for the default json format. This does not change MCP JSON-RPC, tool input schemas, or structuredContent. In toon mode the server verifies that the encoded text decodes back to the same JSON data model; if not, it falls back to pretty JSON for that response text.
For a reproducible local comparison of representative response fixtures:
npm run compare:formats -w @astandrik/local-ydb-mcp
Manual agent smoke check: run the MCP server once with LOCAL_YDB_MCP_CONTENT_FORMAT=json and once with toon, then call the same tools in both sessions: local_ydb_inventory, local_ydb_status_report, local_ydb_healthcheck, local_ydb_bootstrap_root_database without confirm, local_ydb_scheme, local_ydb_generate_schema with validate=true, local_ydb_apply_schema with action=validate, local_ydb_sql for a parameterized query, standalone explain, and plan-only execute, local_ydb_permissions with a plan-only mutation, local_ydb_list_versions, and local_ydb_nodes_check. Record whether the agent extracts the same status, planned commands, risks, and next steps. Treat this as qualitative evidence; the benchmark command is the reproducible metric.
Global Install
npm install -g @astandrik/local-ydb-mcp
{
"mcpServers": {
"local-ydb": {
"command": "local-ydb-mcp",
"env": {
"LOCAL_YDB_TOOLKIT_CONFIG": "/path/to/local-ydb.config.json"
}
}
}
}
local_ydb_generate_schema is the read-only structured table-DDL generator. It renders strict JSON specs for CREATE TABLE, table-level secondary indexes, ordered ALTER TABLE column/index changes, and DROP TABLE; returns the generated DDL text, script SHA-256, official YDB references, warnings, risk, and verification steps; and can validate the generated script when validate: true is supplied. It never applies DDL and uses the same 1 MiB generated-script limit as local_ydb_apply_schema. In with settings, setting names must be YQL-style identifiers, strings render as quoted YQL literals, use { "token": "ENABLED" } for bare-token settings, and use the top-level store field instead of with.STORE. Keep column names away from the reserved __ydb_ prefix, use CREATE TABLE notNull only for columns that are part of the primaryKey, use partitionByHash only with store: "column" and primary key columns, keep column-oriented primary keys NOT NULL and within the documented supported key types, keep secondary/vector indexes on row-oriented tables, use global secondary indexes without creation-time with settings, keep unique indexes synchronous, keep ALTER TABLE ADD COLUMN to name/type only, reject duplicate add/drop column/index actions in one spec, keep indexes off columns added or dropped in the same alterTable spec, provide a non-unique global: true, sync: "sync" vector index with complete vector_kmeans_tree settings, expect a warning when creating a table with a vector index because adding the index after representative data is preferred, and rely on type-aware defaults such as Utf8('x'), Uint64('1'), or Date('2026-05-27').
Mutating tools are plan-only unless called with confirm: true. local_ydb_apply_schema is the table-DDL apply path: it validates raw or generated YQL DDL through the official @ydbjs/* SDK, supports PRAGMA, CREATE TABLE, ALTER TABLE, and DROP TABLE, and applies only after validation succeeds and confirm: true is present. Responses report the script SHA-256 and capped YDB issue text without echoing the raw script or credential paths. For table creation, prefer a CMS tenant path such as /local/example; a root-only /local stack can validate DDL through the static endpoint, but YDB rejects storage-backed table creation there when the root database has no tenant storage pools.
The server includes a root-only local_ydb_bootstrap_root_database tool for starting /local with just the static node, a tenant-oriented local_ydb_bootstrap tool for GraphShard-ready dynamic-node topologies, a read-only local_ydb_list_versions tool for discovering published local-ydb image tags with numeric versions sorted newest first, background image-pull tools (local_ydb_pull_image and local_ydb_pull_status) for slow registry downloads, local_ydb_generate_schema and local_ydb_apply_schema for table DDL generation/validation/application, local_ydb_list_dumps plus dump/restore tools for tenant-wide or tenant-relative backup operations, and a high-risk local_ydb_upgrade_version tool that upgrades a file-backed profile by image preflight, dump, rebuild, restore, auth reapply, image verification, and profile-image persistence. A verified mismatch leaves the profile unchanged; unavailable final inventory after completed rebuild phases returns partial verification and persists the target image. Bind-mounted data profiles are not supported by the automatic upgrade path.
local_ydb_dump_tenant and local_ydb_restore_tenant accept path while preserving existing tenant-wide defaults. Dump path is the source object or directory for ydb tools dump -p; restore path is the destination directory for ydb tools restore -p. Use local_ydb_list_dumps before restore to choose a dumpName, and use optional describePaths plus bounded whole-table countQueries such as SELECT COUNT(*) FROM \dir/table`;` when a restore needs post-command verification.