Skip to main content

​
openclaw backup

OpenClaw की स्थिति, कॉन्फ़िगरेशन, प्रमाणीकरण प्रोफ़ाइलों, चैनल/प्रदाता क्रेडेंशियल्स, सत्रों और वैकल्पिक रूप से कार्यस्थानों के लिए एक स्थानीय बैकअप संग्रह बनाएँ।

​
टिप्पणियाँ

  • संग्रह में समाधान किए गए स्रोत पथों और संग्रह लेआउट के साथ एक manifest.json अंतर्निहित होता है।
  • डिफ़ॉल्ट आउटपुट वर्तमान कार्यशील डायरेक्टरी में टाइमस्टैम्प वाला .tar.gz संग्रह है। टाइमस्टैम्प वाले फ़ाइल नाम आपकी मशीन के स्थानीय समय क्षेत्र का उपयोग करते हैं और उनमें UTC ऑफ़सेट शामिल होता है। यदि वर्तमान कार्यशील डायरेक्टरी बैकअप किए जा रहे स्रोत ट्री के भीतर है, तो OpenClaw डिफ़ॉल्ट संग्रह स्थान के लिए आपकी होम डायरेक्टरी का उपयोग करता है।
  • मौजूदा संग्रह फ़ाइलें कभी अधिलेखित नहीं की जातीं। स्वयं को शामिल होने से रोकने के लिए स्रोत स्थिति/कार्यस्थान ट्री के भीतर के आउटपुट पथ अस्वीकार कर दिए जाते हैं।
  • openclaw backup verify <archive> जाँचता है कि संग्रह में ठीक एक रूट मैनिफ़ेस्ट है, ट्रैवर्सल-शैली के संग्रह पथों और SQLite साइडकारों को अस्वीकार करता है, पुष्टि करता है कि मैनिफ़ेस्ट में घोषित प्रत्येक पेलोड मौजूद है, प्रत्येक SQLite स्नैपशॉट की फ़ाइल संरचना को सत्यापित करता है, और मानक OpenClaw डेटाबेस पर पूर्ण अखंडता एवं भूमिका जाँच चलाता है। समर्पित Plugin स्कीमा अपारदर्शी रहते हैं, क्योंकि उन्हें स्वामी द्वारा परिभाषित SQLite क्षमताओं की आवश्यकता हो सकती है। openclaw backup create --verify संग्रह लिखने के तुरंत बाद यह सत्यापन चलाता है।
  • openclaw backup create --only-config केवल सक्रिय JSON कॉन्फ़िगरेशन फ़ाइल का बैकअप लेता है।

​
SQLite स्नैपशॉट

जब व्यापक स्थिति संग्रह के बजाय किसी एक OpenClaw-स्वामित्व वाले SQLite डेटाबेस के लिए पोर्टेबल आर्टिफ़ैक्ट चाहिए, तब openclaw backup sqlite का उपयोग करें। स्नैपशॉट निर्माण ठीक एक नामित स्रोत स्वीकार करता है: रिपॉज़िटरी में प्रत्येक प्रतिबद्ध स्नैपशॉट के लिए एक डायरेक्टरी होती है। प्रत्येक स्नैपशॉट डायरेक्टरी में ठीक ये होते हैं:
  • manifest.json
  • database.sqlite
स्नैपशॉट निर्माण लाइव डेटाबेस को पढ़ने से पहले सत्यापित करता है, एक लंबा रीड ट्रांज़ैक्शन बनाए रखे बिना प्रतिबद्ध WAL स्थिति कैप्चर करने के लिए SQLite के ऑनलाइन बैकअप API का उपयोग करता है, लाइव डेटाबेस बंद करता है, निजी प्रति को VACUUM से संकुचित करता है, उत्पन्न डेटाबेस को फिर सत्यापित करता है, और मौजूदा पथों को अधिलेखित किए बिना पूर्ण डायरेक्टरी प्रकाशित करता है। वैश्विक स्नैपशॉट संकुचन से पहले अस्थायी डिलीवरी क्यू पंक्तियाँ हटा देते हैं, ताकि हटाए गए क्यू पेलोड खाली पृष्ठों में बने न रहें। लाइव .sqlite, -wal, -shm, या -journal फ़ाइलों को पोर्टेबिलिटी आर्टिफ़ैक्ट के रूप में कॉपी न करें। केवल पूर्ण स्नैपशॉट डायरेक्टरियाँ कॉपी करें। SQLite स्नैपशॉट में प्रमाणीकरण प्रोफ़ाइलें, सत्र स्थिति, Plugin स्थिति और अन्य संवेदनशील रिकॉर्ड हो सकते हैं। रिपॉज़िटरी को लाइव OpenClaw स्थिति डायरेक्टरी के समान अनुमतियों, एन्क्रिप्शन, अवधारण नीति और गंतव्य प्रतिबंधों से सुरक्षित रखें।

​
सत्यापित करना और पुनर्स्थापित करना

सत्यापन सख़्त मैनिफ़ेस्ट संरचना, आर्टिफ़ैक्ट का आकार और SHA-256, SQLite अखंडता, फ़ॉरेन की, स्कीमा संस्करण, डेटाबेस भूमिका एवं स्वामी और OpenClaw-स्वामित्व वाली इंडेक्स परिभाषाओं की जाँच करता है। सत्यापन निजी, सामग्री-पिन की गई प्रति की जाँच करता है, ताकि पथनाम रेस SQLite द्वारा जाँचे जाने वाले बाइट्स को बदल न सके। डिफ़ॉल्ट रूप से, वह अस्थायी प्रति स्नैपशॉट रिपॉज़िटरी के पास बनाई जाती है और कमांड लौटने से पहले हटा दी जाती है। स्टेजिंग रूट और उसकी पूर्वज शृंखला को अन्य उपयोगकर्ताओं द्वारा उसके प्रतिस्थापन को रोकना चाहिए। POSIX रूट वर्तमान उपयोगकर्ता के स्वामित्व में होने चाहिए और समूह/सभी के लिए लेखन योग्य नहीं होने चाहिए; /tmp जैसे स्टिकी पूर्वज उपयोगकर्ता-स्वामित्व वाली संतानों के लिए स्वीकार किए जाते हैं। स्टेजिंग को उजागर करने या प्रतिस्थापन योग्य बनाने वाले macOS ACL अनुदान अस्वीकार किए जाते हैं। Windows रूट और पूर्वज वर्तमान उपयोगकर्ता या किसी विश्वसनीय OS प्रिंसिपल के स्वामित्व में होने चाहिए और उनके ACL अविश्वसनीय स्टेजिंग पहुँच को अस्वीकार करने चाहिए। केवल-पठन माउंट या नेटवर्क शेयर के लिए समकक्ष एन्क्रिप्शन और गंतव्य नियंत्रण वाले स्टोरेज पर --scratch <existing-private-directory> दें। स्नैपशॉट निर्माण डेटाबेस बाइट्स को स्टेज या प्रकाशित करने से पहले रिपॉज़िटरी पर समान स्वामी, ACL, पूर्वज और पथ-पहचान जाँच लागू करता है। पुनर्स्थापन सत्यापन को दोहराता है और केवल नए लक्ष्य पर लिखता है। यह मौजूदा लक्ष्य, -wal, -shm, या -journal साइडकार को अस्वीकार करता है और लाइव OpenClaw डेटाबेस का स्थान पर प्रतिस्थापन कभी नहीं करता। लक्ष्य की पैरेंट डायरेक्टरी पर सत्यापन स्क्रैच जैसी ही पथ-सुरक्षा आवश्यकताएँ लागू होती हैं। पुनर्स्थापित डेटाबेस को सक्रिय करना एक स्पष्ट ऑफ़लाइन ऑपरेटर चरण बना रहता है। स्नैपशॉट रिपॉज़िटरी स्थानीय डायरेक्टरियाँ हैं। शेड्यूलिंग, अपलोड, अवधारण, वृद्धिशील WAL बंडल, फ़ेलओवर और बूट पर पुनर्स्थापन व्यवहार जानबूझकर इस कमांड के दायरे से बाहर हैं।

​
किसका बैकअप लिया जाता है

openclaw backup create आपके स्थानीय OpenClaw इंस्टॉलेशन से स्रोतों की योजना बनाता है:
  • स्थिति डायरेक्टरी (आमतौर पर ~/.openclaw)
  • सक्रिय कॉन्फ़िगरेशन फ़ाइल पथ
  • समाधान की गई credentials/ डायरेक्टरी, जब वह स्थिति डायरेक्टरी के बाहर मौजूद हो
  • वर्तमान कॉन्फ़िगरेशन से खोजी गई कार्यस्थान डायरेक्टरियाँ, जब तक आप --no-include-workspace न दें
प्रमाणीकरण प्रोफ़ाइलें और अन्य प्रति-एजेंट रनटाइम स्थिति, स्थिति डायरेक्टरी (agents/<agentId>/agent/openclaw-agent.sqlite) के अंतर्गत SQLite में रहती हैं, इसलिए वे स्थिति बैकअप प्रविष्टि में स्वतः शामिल हो जाती हैं। --only-config स्थिति, क्रेडेंशियल्स डायरेक्टरी और कार्यस्थान खोज को छोड़ देता है तथा केवल सक्रिय कॉन्फ़िगरेशन फ़ाइल पथ को संग्रहित करता है। संग्रह बनाने से पहले OpenClaw पथों को मानकीकृत करता है: यदि कॉन्फ़िगरेशन, क्रेडेंशियल्स डायरेक्टरी या कोई कार्यस्थान पहले से स्थिति डायरेक्टरी के भीतर है, तो उन्हें अलग शीर्ष-स्तरीय बैकअप स्रोतों के रूप में दोहराया नहीं जाता। अनुपस्थित पथ छोड़ दिए जाते हैं। संग्रह निर्माण के दौरान, OpenClaw tar द्वारा पढ़े जाने से पहले ज्ञात लाइव-परिवर्तन पथों को बाहर कर देता है। इससे फ़ाइल के दर्ज आकार और समवर्ती लेखन के बीच रेस से बचाव होता है। फ़िल्टर प्रत्येक बैकअप की गई स्थिति डायरेक्टरी के अंतर्गत स्थिति-सापेक्ष ये नियम लागू करता है: ये नियम स्थिति डायरेक्टरी के बाहर की कार्यस्थान फ़ाइलों को फ़िल्टर नहीं करते। ये तालिका से मेल खाने वाली पूर्ण ट्रांसक्रिप्ट और लॉग फ़ाइलों को भी छोड़ देते हैं, इसलिए आवश्यकता होने पर उन रिकॉर्ड को अलग से बनाए रखें। JSON परिणाम का skippedVolatileCount बताता है कि कितनी फ़ाइलें जानबूझकर छोड़ी गईं। स्थिति डायरेक्टरी के अंतर्गत SQLite डेटाबेस को SQLite के ऑनलाइन बैकअप API से कैप्चर किया जाता है और VACUUM से ऑफ़लाइन संकुचित किया जाता है, ताकि हटाए गए पृष्ठों के अवशेष संग्रह में प्रवेश न करें और लाइव WAL/SHM फ़ाइलें कॉपी न हों। अनुपलब्ध स्वामी-परिभाषित SQLite क्षमताओं की आवश्यकता वाला Plugin-स्वामित्व वाला डेटाबेस प्रत्यक्ष फ़ाइल कॉपी का फ़ॉलबैक लेने के बजाय बंद होकर विफल हो जाता है। कार्यस्थान बैकअप के माध्यम से शामिल SQLite फ़ाइलें कार्यस्थान फ़ाइलों के रूप में कॉपी की जाती हैं और संकुचन गारंटी के अंतर्गत नहीं आतीं। स्थिति डायरेक्टरी के extensions/ ट्री के अंतर्गत इंस्टॉल किए गए Plugin स्रोत और मैनिफ़ेस्ट फ़ाइलें शामिल की जाती हैं, लेकिन उनके नेस्टेड node_modules/ निर्भरता ट्री पुनर्निर्माण योग्य इंस्टॉलेशन आर्टिफ़ैक्ट होने के कारण छोड़ दिए जाते हैं। किसी संग्रह को पुनर्स्थापित करने के बाद, यदि पुनर्स्थापित Plugin अनुपस्थित निर्भरताओं की सूचना देता है, तो openclaw plugins update <id> का उपयोग करें या openclaw plugins install <spec> --force से पुनः इंस्टॉल करें। स्थिति डायरेक्टरी के अंतर्गत इंस्टॉलर-प्रबंधित और पुनर्निर्माण योग्य रनटाइम रूट भी छोड़ दिए जाते हैं: dev/, git/, npm/, पुराना npm-runtime/, और tools/। इनमें आधिकारिक उपयोगकर्ता स्थिति के बजाय प्रबंधित चेकआउट, पैकेज ट्री और डाउनलोड किए गए रनटाइम होते हैं; पुनर्स्थापन के बाद संबंधित रनटाइम या Plugin को पुनः इंस्टॉल या अपडेट करें। इनमें से किसी रूट के भीतर स्पष्ट रूप से कॉन्फ़िगर की गई कॉन्फ़िगरेशन फ़ाइल, क्रेडेंशियल्स डायरेक्टरी या कार्यस्थान शामिल रहता है।

​
अमान्य कॉन्फ़िगरेशन व्यवहार

openclaw backup सामान्य कॉन्फ़िगरेशन पूर्व-जाँच को बायपास करता है, ताकि यह पुनर्प्राप्ति के दौरान भी सहायता कर सके। कार्यस्थान खोज एक मान्य कॉन्फ़िगरेशन पर निर्भर करती है, इसलिए कॉन्फ़िगरेशन फ़ाइल मौजूद लेकिन अमान्य होने और कार्यस्थान बैकअप अब भी सक्षम होने पर openclaw backup create तुरंत विफल हो जाता है। उस स्थिति में आंशिक बैकअप के लिए --no-include-workspace के साथ फिर चलाएँ: यह कार्यस्थान खोज को पूरी तरह छोड़ते हुए स्थिति, कॉन्फ़िगरेशन और बाहरी क्रेडेंशियल्स डायरेक्टरी को दायरे में रखता है। कॉन्फ़िगरेशन विकृत होने पर भी --only-config काम करता है, क्योंकि यह कार्यस्थान खोज के लिए कॉन्फ़िगरेशन को पार्स नहीं करता।

​
आकार और प्रदर्शन

OpenClaw कोई अंतर्निहित अधिकतम बैकअप आकार या प्रति-फ़ाइल आकार सीमा लागू नहीं करता। पाँच मिनट तक कोई डेटा उत्पन्न न करने वाला संग्रह लेखन अनिश्चितकाल तक अटके रहने के बजाय विफल हो जाता है और अपनी आंशिक अस्थायी फ़ाइल हटा देता है। अन्यथा व्यावहारिक सीमाएँ इनसे आती हैं:
  • अस्थायी संग्रह लेखन और अंतिम संग्रह के लिए उपलब्ध स्थान
  • बड़े कार्यस्थान ट्री को पढ़ने और उन्हें .tar.gz में संपीड़ित करने में लगने वाला समय
  • --verify या openclaw backup verify से संग्रह को दोबारा स्कैन करने में लगने वाला समय
  • गंतव्य फ़ाइल सिस्टम का व्यवहार: OpenClaw बिना अधिलेखन वाले हार्ड-लिंक प्रकाशन की माँग करता है, ताकि अंतिम संग्रह पथ कभी प्रगति पर चल रही प्रति को उजागर न करे; असमर्थित फ़ाइल सिस्टम कार्रवाई योग्य त्रुटि के साथ विफल होते हैं
यदि प्रकाशन के बाद अंतिम डायरेक्टरी की टिकाऊपन पुष्टि विफल हो जाती है, तो कमांड विफलता की सूचना देता है, लेकिन समवर्ती प्रतिस्थापन को हटाने का जोखिम लेने के बजाय पूर्ण अंतिम प्रविष्टि सुरक्षित रखता है। बड़े कार्यस्थान आमतौर पर संग्रह आकार के मुख्य कारक होते हैं। छोटे/तेज़ बैकअप के लिए --no-include-workspace या सबसे छोटे संग्रह के लिए --only-config का उपयोग करें।

​
संबंधित