आपका बैकअप चुपचाप उन यूज़र्स को ज़िंदा कर देता है जिन्हें आपने डिलीट किया था

हर incremental बैकअप चुपचाप एक ही धारणा बनाता है: जो बदला है उसका बैकअप लेने के लिए, वे rows ढूँढो जो बदली हैं। Azure Table Storage या DynamoDB जैसे key-value store पर "जो बदला है" का मतलब है "वे rows जिनका last-modified timestamp मेरे पिछले watermark से नया है।" टेबल पर चलिए, जो कुछ नया है उठा लीजिए, लिख दीजिए। तेज़, सस्ता, सही।

Writes के लिए सही। अब एक row डिलीट कीजिए।

उस row को कोई "deleted" फ़्लैग नहीं मिलता। उसे कोई नया timestamp नहीं मिलता। वह किसी recycle bin में नहीं जाती। वह बस अस्तित्व में रहना बंद कर देती है। इन stores में न delete markers हैं और न deletions के लिए कोई change feed, इसलिए डिलीट हुई row अपने पीछे ठीक-ठीक कुछ भी नहीं छोड़ती। आपका incremental बैकअप, जो नए timestamps को स्कैन करके बदलाव ढूँढता है, उस खाली जगह के ऊपर से गुज़र जाता है जहाँ कभी row हुआ करती थी, और उसे कुछ नहीं मिलता। मिलने को कुछ है ही नहीं। delete अदृश्य है।

यानी आपके बैकअप में वह row अब भी मौजूद है। और यहीं से data-loss की कहानी सुरक्षा की कहानी बन जाती है।

सोचिए कि किसी auth सिस्टम में delete का आम तौर पर मतलब क्या होता है। आपने वह यूज़र मज़े के लिए डिलीट नहीं किया था। आपने एक कर्मचारी को ऑफ़बोर्ड किया था। आपने एक ऐसा अकाउंट हटाया था जिसका पासवर्ड किसी breach dump में दिखा था। आपने token लीक होने के बाद एक OAuth grant रद्द किया था। आपने एक एडमिन की पहुँच उसी दिन छीनी थी जिस दिन वह गया। इनमें से हर एक सुरक्षा का फ़ैसला है, और deletes न देख पाने वाले बैकअप के आगे इनमें से एक भी फ़ैसला टिकता नहीं।

फिर आप restore करते हैं। शायद किसी असली आपदा के बाद, शायद बस एक staging clone बनाने के लिए। बैकअप ठीक वही करता है जो आपने कहा था: वह हर उस row को वापस रख देता है जिसे वह जानता है। ऑफ़बोर्ड किया गया कर्मचारी फिर से यूज़र है। breach हुआ पासवर्ड फिर से चालू है। रद्द किया गया grant फिर से काम करता है। हटाया गया एडमिन फिर से एडमिन है। आपके restore ने डेटा नहीं खोया। उसने आपके सुरक्षा फ़ैसले चुपचाप पलट दिए, और आपको एक ऐसा सिस्टम थमा दिया जो देखने में स्वस्थ है और अंदर से चुपचाप compromised। जो बैकअप delete भूल जाता है वह बिना बैकअप से भी बदतर है, क्योंकि आप उस पर भरोसा करते हैं।

इलाज यह है कि delete को row की ग़ैरमौजूदगी मानना बंद करें और उसे एक event मानना शुरू करें। Deletes भी डेटा हैं।

इसलिए हम deletes को उनकी अपनी टेबल देते हैं। सिस्टम का हर delete एक injected ITombstoneWriter से होकर गुज़रता है जो एक tombstone दर्ज करता है: key, और उसके मरने का समय। कोई ऐसा code path नहीं है जो tombstone छोड़े बिना कोई row डिलीट करे, क्योंकि delete और tombstone एक ही operation हैं। फिर incremental बैकअप एक ही watermark पर पकड़े गए दो हिस्सों का नाम है: upserts (नए timestamp वाली rows) और tombstones (पिछले watermark के बाद के deletes)। Restore दोनों को समय के क्रम में दोबारा चलाता है, इसलिए delete ठीक write की तरह लागू होता है, और जो key डिलीट होकर बाद में फिर बनाई गई हो वह उसी नतीजे पर पहुँचती है जो आख़िर में हुआ था। उस खाली जगह के साथ आख़िरकार एक रिकॉर्ड जुड़ गया है।

बस यही पूरी तरकीब है, और यह छोटी है। लेकिन इसकी अहमियत छोटी नहीं।

यह पैटर्न Table Storage और DynamoDB से आगे तक जाता है। जो भी सिस्टम delete को "row चली गई" के रूप में मॉडल करता है, वह deletes का बैकअप, replication या sync नहीं कर सकता, क्योंकि ले जाने को कुछ है ही नहीं। यह उन भोले event replays में दिखता है जो सिर्फ़ creates और updates दोबारा चलाते हैं। यह उन caches में दिखता है जो expire तो होते हैं पर कभी invalidate नहीं होते। यह उन read replicas में दिखता है जो बहक जाती हैं क्योंकि delete कभी पहुँचा ही नहीं। और यह ठीक वहाँ सबसे ख़तरनाक है जहाँ deletes ही सुरक्षा लागू करने का ज़रिया हैं, और identity सिस्टम में वह जगह हर जगह है: revocation, ऑफ़बोर्डिंग, rotation, lockout। अगर आपकी durability की कहानी सिर्फ़ मौजूद चीज़ों का हिसाब रखती है, तो वह उन चीज़ों को पूरी वफ़ादारी से सहेज लेगी जिन्हें ग़ायब करने में आपने मेहनत लगाई थी।

तो अपने बैकअप का ऑडिट एक सवाल से कीजिए: अगर मैं अभी एक यूज़र डिलीट करूँ, बैकअप लूँ, और उसे restore करूँ, तो क्या वह यूज़र ग़ायब रहेगा? अगर ईमानदार जवाब है "पक्का नहीं कह सकता," तो आपका बैकअप उल्टी दिशा में चलती टाइम मशीन है। वह आपको आपकी ग़लतियों से नहीं बचाता। वह उन्हें ज़िंदा कर देता है: वह पासवर्ड जो आपने बदला था, वह कर्मचारी जिसे आपने ऑफ़बोर्ड किया था, वह token जो आपने रद्द किया था।

Deletes भी डेटा हैं। उनका बैकअप भी वैसे ही लीजिए।

और अगर आप चाहते हैं कि आपके बैकअप हर delete का सम्मान करें, बिना इसके कि आपको यह ख़ुद साबित करना पड़े, तो प्लेटफ़ॉर्म इसी लिए होता है। Authagonal हर delete का tombstone बनाता है, ताकि restore कभी कोई रद्द की गई credential वापस न ले आए।