IMHO no and there is no reason. Is the backup OK? Just read it. Any
error will be reported. Physical errors are reported by the hardware.
Is backup altered by hostile user? Protect it using RACF or else.
However educated and authorized user may alter backup and re-create hash.
Do you want to sleep safely? Then don't think about backup ;-)
Or just make your backup safe enough for your needs. It may mean two
copies, two copies in two locations, 4 copies in two location, 6 copies
in 3 locations, one really far. Or 8 copies in 4 locations...
However you will never be 100% safe. It is hard to imagine an flood with
diameter of 2000 miles, but terrorist attack against YOUR COMPANY can
cover all your datacenters at the time. It is unlikely, but adding
datacenters will not help you in that case. Keeping addresses in secret
is rather hard and will become useless after first disclosure.
This is important and sometimes hard to explain: we are not talking
about two or three random attacks which accidentally happened one day
and accidentally covered our datacenters. This is about ONE terrorist
action with two or three threads.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 08.07.2020 o 17:54, kekronbekron pisze:
Dumb question - can integrity checks for backups be done with dump
hashes/signatures, either in software or in the storage array (if the array
maintains metadata about files/objects) ?
If there's an automated flow for this, many teams could sleep peacefully,
knowing that backups are in good condition, without having to actually pick one
and test the flow.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, July 8, 2020 8:56 PM, Glenn Wilcock <wilc...@us.ibm.com> wrote:
Hi All,
I want to give another perspective on the need for backup copies. The focus
here is on physical loss of storage. With replication, and many clients having
2, 3 and even 4 sites, the probability of needing a backup copy to recover from
a physical loss of data really has decreased. (Still there, none the less).
BUT, the probability for logical data corruption has INCREASED. Accidental and
malicious data corruption is instantly mirrored to all replication copies,
making them useless. Working in HSM, I regularly see calls requesting
assistance in recovering large amounts of data from backup copies. We're all
human and we all make mistakes. Some of those mistakes result in data loss.
Also, all products have programming defects and some of those defects result in
data loss. This speaks nothing to the current environment where governments are
mandating policies and procedures for protecting against malicious data
destruction. Your only hope for recovery is a PiT backup prior to the data
loss/corruption. Not all loss/corruption will be found immediately. So, your
ability to recover is a factor of how long it takes you to determine that there
was corruption/loss and how much your willing to invest in keeping backup
copies for at least that long.
Glenn Wilcock
DFSMS Chief Product Owner
======================================================================
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza)
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać
karze.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237,
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
01.01.2020 r. wynosi 169.401.468 złotych.
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169.401.468 as at 1 January 2020.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
