Databricks: RESTORE or CLONE that changes table partitioning may now be blocked - what changed on 1 September 2026 and how to work with it

#What changed

The Databricks Runtime maintenance updates dated 1 September 2026 for 17.3 LTS, 18 LTS and 18.2 include this behaviour change:

RESTORE and CLONE commands that alter the partitioning of a table may be blocked when the source and target share a common file.

You're most likely to hit it when:

• You RESTORE a table to a version from before someone re-partitioned it (for example, before a REPLACE TABLE ... PARTITIONED BY or an overwrite with a new partition scheme), and the old and new versions still reference some of the same files.
• You SHALLOW CLONE a table onto an existing target that has a different partitioning, where the clone would reference the same underlying files.

Clusters pick up maintenance updates when they restart, so a job that worked in August can fail after a routine restart in September without any code change.

#Why it's blocked

Delta files written under one partition layout carry partition values in the transaction log for that layout. If two table versions (or two tables) with different partitioning point at the same physical file, the metadata about that file can disagree, which risks wrong results or broken maintenance (VACUUM, OPTIMIZE). Blocking the command is safer than silently producing an inconsistent table.

#1. Confirm it's this

DESCRIBE HISTORY main.sales.orders;
DESCRIBE DETAIL main.sales.orders;   -- partitionColumns now

In the history, look for an operation between the current version and the target version that changed partitioning (CREATE OR REPLACE TABLE, REPLACE TABLE AS SELECT, overwrite with overwriteSchema and new partitionBy). The operationParameters column shows partitionBy for those operations:

from delta.tables import DeltaTable
(DeltaTable.forName(spark, "main.sales.orders").history()
   .where("version >= 120")
   .select("version", "timestamp", "operation", "operationParameters.partitionBy")
   .orderBy("version").show(truncate=False))

If partitioning differs and the command fails, this change is the likely cause. Check the exact error text in the driver log for confirmation.

#2. Getting back to an old version anyway

Instead of RESTORE, rewrite the old version as a new set of files:

-- write the old data with the old partitioning, as new files
CREATE OR REPLACE TABLE main.sales.orders
PARTITIONED BY (order_date)
AS SELECT * FROM main.sales.orders VERSION AS OF 120;

Or use a DEEP CLONE of the old version into a new table, check it, then swap names:

CREATE TABLE main.sales.orders_restored
DEEP CLONE main.sales.orders VERSION AS OF 120;
-- validate counts, then
ALTER TABLE main.sales.orders RENAME TO main.sales.orders_broken;
ALTER TABLE main.sales.orders_restored RENAME TO main.sales.orders;

Renaming changes the table's identity: re-apply grants, and update anything that references the table by ID (streaming checkpoints, Delta Sharing, lineage). Streaming readers of the table need a new checkpoint.

#3. Clones in environment refreshes

If you refresh dev/test copies with SHALLOW CLONE onto existing targets, and the production table's partitioning changed:

• Drop the target first and clone fresh, or
• Use DEEP CLONE for the refresh.

#4. Changing partitioning on purpose

Plan it as a rewrite, not a metadata trick. For many tables, liquid clustering is a better choice than partition columns, because you can change clustering keys later without rewriting the table. Moving a partitioned table to liquid clustering is itself a rewrite:

CREATE OR REPLACE TABLE main.sales.orders
CLUSTER BY (customer_id, order_date)
AS SELECT * FROM main.sales.orders;

After that, ALTER TABLE ... CLUSTER BY (...) changes keys without a full rewrite. Check the current Databricks documentation for conversion options on your runtime.

#Checklist

• Failing RESTORE/CLONE matched to a partitioning change in table history
• Recovery done with CREATE OR REPLACE AS SELECT or DEEP CLONE of the old version
• Grants, streaming checkpoints and shares re-applied after a swap
• Environment refresh jobs use fresh clones or DEEP CLONE
• Future partitioning changes planned as rewrites, or liquid clustering used

#Sources

• Databricks Runtime maintenance updates