On 11/1/17 11:33 PM, Stack wrote:
On Wed, Nov 1, 2017 at 5:08 PM, Vladimir Rodionov<[email protected]>
wrote:
There is no way to validate correctness of backup in a general case.
You can restore backup into temp table, but then what? Read rows one-by-one
from temp table and look them up
in a primary table? Won't work, because rows can be deleted or modified
since the last backup was done.
Replication has a verity table tool.
You can ask a cluster not delete rows.
You can read at a specific timestamp.
Or you could create backups during an extended ITBLL. When ITBLL completes,
verify it on src cluster. Create a table from the increment backups. Verify
in the restore.
Etc.
St.Ack
I can definitely see a benefit of a tool which verifies the data
collected for a backup which:
1. Is batch in nature
2. Is ad-hoc (not intrinsically run for every backup session)
3. Relies/is-built on existing tooling (snapshots or other
verification-like code)
Thanks Stack. I think this is some good teasing of requirements from an
otherwise very broad and untenable problem statement that we started
with (which lead to the knee-jerk).
