Is there a checksum recorded in the dump?

[Mikhail Teterin]

Is there any kind of checksumming during DUMPing and LOADing, or is it
possible for a bit-flip to change a row's data from "A" to "a" and go
undetected?

During compressed dumps, there is libz's checksumming, but what about
the "raw" ones?

Also, are the original database's name and server recorded anywhere in the
dump?

Thanks!

-mi

[m***@peppler.org]

Post by Mikhail Teterin
Is there any kind of checksumming during DUMPing and
LOADing, or is it possible for a bit-flip to change a
row's data from "A" to "a" and go undetected?

As the database dump is a copy of the physical pages I
suspect that the same corruption check logic that ASE uses
for a database will be used in the dump.

Post by Mikhail Teterin
Also, are the original database's name and server recorded
anywhere in the dump?

The database name is recorded (at least I saw it running a
string command on a database dump), but I don't think that
the server name is stored anywhere.

Michael

[A.M.]

Post by m***@peppler.org

Post by Mikhail Teterin
Is there any kind of checksumming during DUMPing and
LOADing, or is it possible for a bit-flip to change a
row's data from "A" to "a" and go undetected?

As the database dump is a copy of the physical pages I
suspect that the same corruption check logic that ASE uses
for a database will be used in the dump.

But that doesn't involve anything with respect to
the contents of a field. There's nothing anywhere
on a page that checksums the contents of fields or
rows and, consequently, the same contents in a dump
file.

Post by m***@peppler.org

Post by Mikhail Teterin
Also, are the original database's name and server recorded
anywhere in the dump?

The database name is recorded (at least I saw it running a
string command on a database dump), but I don't think that
the server name is stored anywhere.

Unless you have a dump of master. But then the server
name is only in one of the rows of the sysservers table.
Its not used anywhere anyway hence you can load master
and tempdb elsewhere and load any database dump into
a database with a different name.

-am © MMVI

[Mikhail T.]

Post by A.M.

Post by m***@peppler.org
As the database dump is a copy of the physical pages I
suspect that the same corruption check logic that ASE uses
for a database will be used in the dump.

But that doesn't involve anything with respect to
the contents of a field. There's nothing anywhere
on a page that checksums the contents of fields or
rows and, consequently, the same contents in a dump
file.

So, does this mean, that a bit-flip somewhere in the dump may go unnoticed
and the server will load it?

We are compressing all dumps currently (thus utilizing the Zlib's own
checksumming), but it would be nice if the dump-loading code was making its
own verification of the uncompressed data...

Thanks!

-mi

[A.M.]

Post by Mikhail T.

Post by A.M.
But that doesn't involve anything with respect to
the contents of a field. There's nothing anywhere
on a page that checksums the contents of fields or
rows and, consequently, the same contents in a dump
file.

So, does this mean, that a bit-flip somewhere in the dump may go unnoticed
and the server will load it?

Yes, corrupted data is corrupted data. ASE doesn't
know if the contents of a field should be x or y.

Post by Mikhail T.
We are compressing all dumps currently (thus utilizing the Zlib's own
checksumming), but it would be nice if the dump-loading code was making its
own verification of the uncompressed data...

The only way to really do this is to have a checksum for
every field. This adds to the overall space used and there's
no guarantee that the checksum itself is not corrupt.
This is a fundamental problem.

-am © MMVI

[Jason L. Froebe [TeamSybase]]

Post by A.M.

Post by Mikhail T.

Post by A.M.
But that doesn't involve anything with respect to
the contents of a field. There's nothing anywhere
on a page that checksums the contents of fields or
rows and, consequently, the same contents in a dump
file.

So, does this mean, that a bit-flip somewhere in the dump may go unnoticed
and the server will load it?

Yes, corrupted data is corrupted data. ASE doesn't
know if the contents of a field should be x or y.

Post by Mikhail T.
We are compressing all dumps currently (thus utilizing the Zlib's own
checksumming), but it would be nice if the dump-loading code was making its
own verification of the uncompressed data...

The only way to really do this is to have a checksum for
every field. This adds to the overall space used and there's
no guarantee that the checksum itself is not corrupt.
This is a fundamental problem.
-am © MMVI

However, obtaining an overall md5sum (GNU Textutils - platform
independent) for each dump file does help detect corruption when the
file is restored from an archive.

[Mikhail T.]

Post by Jason L. Froebe [TeamSybase]
However, obtaining an overall md5sum (GNU Textutils - platform
independent) for each dump file does help detect corruption when the
file is restored from an archive.

Hence my question -- does Sybase's DUMP/LOAD mechanism do anything like
this?

Does not even have to be "crypto-strong" kind of checksumming (like MD5 or
SHA1) -- simple 32-bit would be sufficient to detect almost all storage
media rot (if not neccessarily a determined attempt to plant bogus data
into a dump)...

-mi

[A.M.]

Post by Mikhail T.
Hence my question -- does Sybase's DUMP/LOAD mechanism do anything like
this?

To which the answer is no.

Post by Mikhail T.
Does not even have to be "crypto-strong" kind of checksumming (like MD5 or
SHA1) -- simple 32-bit would be sufficient to detect almost all storage
media rot (if not neccessarily a determined attempt to plant bogus data
into a dump)...

If you can buy the Backup API you could write your own.
Other than that, you'd have to rely on the load and any
post load DBCC checks to spot any problems.

-am © MMVI