Encrypted backup और पुनर्प्राप्ति

Encrypted site backup बनाएँ, सत्यापित और स्थानांतरित करें तथा dashboard से सुरक्षा-जाँच वाली बहाली माँगें।

कार्यप्रवाह

तैयारी जाँचेंसक्रिय God खाते से Site Backups खोलें। पुष्टि करें कि backup प्रक्रिया configured और enabled है तथा दूरस्थ destination उपलब्ध है।
बनाएँ या मिलान करेंManual backup माँगें या remote inventory sync करें। दोनों काम queue में लगते हैं; सूचना archive पूरा होने का प्रमाण नहीं।
Archive सत्यापित करेंस्थिति, दर्ज SHA-256, remote verification, manifest, निर्माण समय और expiry जाँचें। पृष्ठ पर retention अवधि सात दिन है।
स्थानांतरित या restore करेंज़रूरत पर पात्र archive transfer करें। Restore के लिए पूरा, सत्यापित, न समाप्त archive और नए MFA के साथ स्पष्ट पुष्टि चाहिए।
काम पूरा होने तक देखेंRecent Operations में queued, running, completed या failed काम देखें। अगली माँग से पहले बताई विफलता सुलझाएँ।

पहुँच और तैयारी

Site Backups पृष्ठ केवल सक्रिय God खाते के लिए है। काम माँगने से पहले तैयारी संकेत देखें: configuration, enabled स्थिति, remote उपलब्धता, destination की तैयारी और retention। Backup में manifest और integrity hash वाला encrypted archive बनता है। केवल button दिखने से स्वस्थ backup न मानें; System Health अलग से आखिरी सफल सत्यापित backup बताता है। स्थिति unconfigured या unavailable हो तो बार-बार काम queue करने के बजाय platform operator को बताएँ।

Site Backups में हर तैयारी संकेत और retention अवधि जाँचें।
नया काम शुरू करने से पहले Recent Operations में पहले से queued या चल रहा काम देखें।
तैयारी असफल हो तो बिना secret वाली स्थिति दर्ज कर अधिकृत संचालन माध्यम से आगे भेजें।

बनाना और मिलान करना

Create manual backup माँगता है और Sync remote inventory का मिलान करता है। Worker असली काम करता है, इसलिए हर अनुरोध queued स्थिति लौटाता है। पृष्ठ refresh करके operation पंक्ति terminal स्थिति तक देखें। पूरे रिकॉर्ड में नाम वाला encrypted archive, checksum, खाली न होने वाला manifest और expiry होनी चाहिए। Queue की स्वीकृति, local-ready स्थिति या पुराना रिकॉर्ड सत्यापित remote backup नहीं है।

नया manual archive बनाने के लिए Create या केवल inventory मिलाने के लिए Sync चुनें।
स्थिति बदलने की प्रतीक्षा करें और सबसे नया backup रिकॉर्ड खोलें।
भरोसा करने से पहले complete स्थिति, hash, remote verification और भविष्य की expiry जाँचें।

सात दिन की retention

पृष्ठ में configured retention सात दिन है। निर्माण और expiry समय UTC में दिखते हैं; archive अभी पात्र है या नहीं तय करने के लिए इन्हीं का उपयोग करें। समाप्त archive बहाली के लिए मान्य नहीं। इस अवधि के भीतर recovery की योजना बनाएँ और transfer के बाद archive हमेशा उपलब्ध रहेगा, ऐसा न मानें। Backup संदर्भ का संचालन रिकॉर्ड स्वीकृत सीमित प्रणाली में रखें, सार्वजनिक दस्तावेज़ में नहीं।

चुने archive की UTC निर्माण और expiry तारीख पढ़ें।
हाल का ऐसा archive चुनें जो न समाप्त हो और remote verified हो।
ज़रूरी बिंदु expire हो गया हो तो restore न करें; आगे भेजें और अगला सत्यापित बिंदु लें।

Transfer और अखंडता

Checksum वाले complete, local-ready और कुछ failed records पर Transfer उपलब्ध है; worker स्थानांतरण और सत्यापन करता है। Restore की पात्रता अधिक कड़ी है: complete स्थिति, मिलता archive नाम, मान्य SHA-256, खाली न होने वाला manifest, remote verification और भविष्य की expiry। पृष्ठ checksum तथा verification स्थिति दिखाता है ताकि अधूरे या बेमेल रिकॉर्ड पहचानें। Managed प्रक्रिया के बाहर metadata न बदलें और archive बदलने की कोशिश न करें।

चुने रिकॉर्ड पर Transfer चलाकर operation पूरा होने की प्रतीक्षा करें।
Remote verification दर्ज और checksum मौजूद होने की पुष्टि करें।
Transfer विफल हो या integrity डेटा न हो तो failure code पढ़कर पात्रता bypass किए बिना आगे भेजें।

बहाली का अनुरोध

Restore बड़ा असर डालने वाला queued काम है, तत्काल पृष्ठ कार्रवाई नहीं। सक्रिय God उपयोगकर्ता ने पिछले दस मिनट में MFA पूरा किया हो। पुष्टि संवाद में कम-से-कम बारह वर्ण का कारण दें, ठीक backup पहचानकर्ता और दिखाया production host भरें तथा परिणाम स्वीकारने का checkbox चुनें। Server चुने archive और configured host से मान जाँचता है। सफल जमा केवल स्वीकृत अनुरोध दर्ज और queue करता है; इससे restore worker का काम पूरा होना सिद्ध नहीं होता।

केवल पूर्ण, remote-verified, न समाप्त पात्र archive के लिए Restore खोलें और नया MFA पूरा करें।
कारण, ठीक backup पहचानकर्ता और दिखाया host भरें; स्पष्ट पुष्टि चुनें।
एक बार जमा कर Recent Operations और स्थिति देखें; नए अनुरोध से पहले विफलता जाँचें।

विफलता सँभालें

पृष्ठ failure alerts, operation स्थिति और failure code दिखाता है। आम कारण हैं destination अनुपलब्ध, archive metadata अधूरा, remote verification विफल, recovery बिंदु expire या नया MFA न होना। चल रहा operation अभी जारी हो सकता है; duplicate जमा न करें। System Health में scheduler और disk स्थिति के साथ आखिरी सफल backup अलग दिखता है। बार-बार विफलता हो तो स्थिति और code बताएँ, पर secrets, निजी endpoint मान और ग्राहक डेटा रिपोर्ट में न रखें।

Recent Operations में operation प्रकार, स्थिति, समय और failure code पढ़ें।
संबंधित queue, disk, scheduler और backup संकेतों के लिए तैयारी और System Health देखें।
कारण समझने और पुराना operation terminal होने पर ही फिर प्रयास करें; बाकी platform समस्या आगे भेजें।

अक्सर पूछे जाने वाले प्रश्न

क्या सफलता सूचना का अर्थ backup तैयार है?

नहीं। अनुरोध queue हुआ है। पूरा रिकॉर्ड, checksum, remote verification और न समाप्त स्थिति जाँचें।

Archive कितने समय रखा जाता है?

Configured पृष्ठ सात दिन बताता है। हर रिकॉर्ड की expiry पंक्ति निर्णायक है।

Backup कौन बना या restore कर सकता है?

पृष्ठ केवल सक्रिय God खाते के लिए है और हर बदलाव में उसी उपयोगकर्ता का नया MFA चाहिए।

Restore उपलब्ध क्यों नहीं है?

रिकॉर्ड अधूरा, असत्यापित, मान्य manifest या checksum के बिना, अथवा expire हो सकता है। Restore केवल पात्र archive के लिए है।

Restore के लिए क्या पुष्टि चाहिए?

कम-से-कम बारह वर्ण का कारण, ठीक backup पहचानकर्ता, दिखाया host, परिणाम स्वीकारने का checkbox और नया MFA।

काम पूरा हुआ या नहीं कहाँ देखूँ?

Site Backups के Recent Operations में। केवल queued उत्तर पूरा होने का प्रमाण नहीं है।