What happens to in-flight transactions that straddle a YugabyteDB backup boundary after restore?

Transactional Atomicity at the Backup Boundary

In YugabyteDB (version 2.18 and later), a restored universe guarantees full atomicity for distributed transactions. If a transaction was in-flight when the Hybrid Logical Clock (HLC) snapshot was taken, it is treated as if it never occurred. No subset of a distributed transaction's writes will survive a restore; either the entire transaction committed before the snapshot HLC and is fully present, or it is entirely absent.

How Boundary Transactions are Resolved

YugabyteDB utilizes a consistent distributed snapshot mechanism. The backup process identifies a specific HLC timestamp as the cutoff point. The resolution of transactions straddling this boundary follows these rules:

• Committed before HLC: The transaction is fully captured in the backup.
• In-flight/Preparing at HLC: Even if some tablets had already processed the writes (but the transaction had not reached a final commit state across all participants), those writes are excluded from the snapshot.
• Committed after HLC: The transaction is ignored.

Because the restore process replays the state of the tablets exactly as they existed at the snapshot HLC, the "partial apply" anomaly is avoided by design. The restored state represents a consistent point-in-time view of the database.

Verification and Diagnostics

It is important to distinguish between data integrity and transactional completeness when using administrative tools:

Tool/Method	Scope of Validation	Detects Partial Transactions?
yb-admin verify_backup	Byte-level tablet checksums vs. backup metadata.	No
Tablet/Transaction Logs	Commit/Abort entries relative to the snapshot HLC.	Yes

yb-admin verify_backup validates that the restored tablet data matches the backup source exactly. It does not analyze the logical completeness of transactions; it only ensures that the bytes restored are the bytes that were backed up.

Observing Boundary Decisions

To verify the fate of a specific transaction, you must examine the transaction logs (yb-txn-logs) or tablet logs. Look for the commit entries associated with the transaction ID around the snapshot HLC. If a transaction was in-flight during the backup, you will find no corresponding commit record for that transaction within the snapshot's timestamp range.

Required Diagnostic Detail: To provide a more tailored verification strategy, please specify if you are using Full or Incremental backups, as the chain of HLC snapshots may affect how you trace transaction boundaries across multiple restore points.