On Thu, Nov 2, 2017 at 5:51 AM, Josh Elser <[email protected]> wrote:
> 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). > To be clear, I wasn't listing requirements. I was having trouble with the absolute "There is no way to validate correctness of backup in a general case." which is then seemingly being used to beat down any request for verification tooling/testing that shows backup/restore works properly. Good on you Josh, S
