mirror of https://github.com/snapotter-hq/SnapOtter.git synced 2026-08-03 07:46:42 +02:00

Files

T

SnapOtterandGitHub 4963ab3bbd feat(docs-i18n): translate all documentation into 20 languages

All 181 docs markdown files translated into 20 languages (apps/docs/<locale>/**). Companion to the i18n code PR; admin-merged because the file count exceeds GitHub's per-PR CI trigger limit. Validated by pnpm i18n:check (all surfaces, 0 stale/missing) and a clean all-locale docs build.

2026-07-11 13:52:47 +08:00

14 KiB

Raw Blame History

i18n_source_hash, i18n_provenance, i18n_output_hash

i18n_source_hash	i18n_provenance	i18n_output_hash
9a6abf3fc8ae	human	6122c38692ef

1.x से 2.0 में अपग्रेड करना

SnapOtter 1.x सब कुछ एक ही SQLite फ़ाइल में संग्रहीत करता था और एक ही container के रूप में चलता था। SnapOtter 2.0 PostgreSQL और Redis का उपयोग करता है। यह गाइड बिना डेटा खोए 1.x इंस्टॉल को 2.0 में ले जाने का तरीका बताती है।

संक्षेप में: अपने मौजूदा /data वॉल्यूम का पुनः उपयोग करें, और 2.0 पहली बूट पर आपके 1.x डेटाबेस को स्वचालित रूप से इम्पोर्ट कर लेता है। आपके उपयोगकर्ता, सहेजी गई फ़ाइलें, सेटिंग्स, API keys और pipelines सब साथ आ जाते हैं। पुराना डेटाबेस कभी संशोधित नहीं होता, इसलिए आप हमेशा रोल बैक कर सकते हैं।

::: tip हमारे 1.x उपयोगकर्ताओं के लिए एक नोट आप में से कई लोगों ने पहले दिन से SnapOtter पर भरोसा किया है, और आपकी प्रतिक्रिया ने इस रिलीज़ को आकार दिया है। 2.0 अंदरूनी तौर पर बहुत कुछ बदलता है, और यह गाइड इसलिए मौजूद है ताकि यह बदलाव आपको उन चीज़ों में से कुछ भी न खर्च कराए जिनकी आप परवाह करते हैं। आपके अकाउंट, फ़ाइलें, सेटिंग्स, API keys और pipelines साथ आते हैं, और आपका पुराना डेटाबेस कभी नहीं छुआ जाता। हमारे साथ अपग्रेड करने के लिए धन्यवाद। :::

शुरू करने से पहले: पूरे `/data` वॉल्यूम का बैकअप लें

यह हर बार सबसे पहले करें। पूरे /data वॉल्यूम का बैकअप लें, केवल snapotter.db फ़ाइल का नहीं।

यह क्यों मायने रखता है, यहाँ बताया गया है। 1.x SQLite को WAL मोड में चलाता है, इसलिए एक रुका हुआ 1.x container अक्सर अपने अधिकांश कमिट किए गए डेटा को snapotter.db-wal में छोड़ देता है, जिसके साथ एक लगभग-खाली snapotter.db होता है। केवल snapotter.db कॉपी करने से एक खाली डेटाबेस कैप्चर होता है और सब कुछ चुपचाप खो जाता है। वॉल्यूम snapotter.db, snapotter.db-wal, snapotter.db-shm, और आपकी files/ डायरेक्टरी को एक साथ रखता है, और इन्हें एक सेट के रूप में साथ ले जाना चाहिए।

# Adjust the volume name to match yours (see "Check your volume name" below).
docker run --rm -v SnapOtter-data:/data -v "$PWD":/backup \
  alpine tar czf /backup/snapotter-1x-data.tgz -C /data .

पहले 1.17.2 में अपग्रेड करें

2.0 में जाने से पहले अपने 1.x इंस्टॉल को नवीनतम 1.x रिलीज़ (1.17.2) में अपग्रेड करें। इससे 1.x अपने अंतिम स्कीमा माइग्रेशन चला पाता है, ताकि 2.0 एक ज्ञात, पूर्ण स्कीमा से इम्पोर्ट करे। किसी पुराने 1.x से सीधे 2.0 में अपग्रेड करना समर्थित नहीं है।

अपने वॉल्यूम का नाम जाँचें

इम्पोर्टर आपका डेटा केवल तभी देखता है जब 2.0 स्टैक वही वॉल्यूम माउंट करता है जो आपके 1.x इंस्टॉल ने उपयोग किया था। Docker वॉल्यूम नाम केस सेंसिटिव होते हैं, और पुराने README स्निपेट्स में एक लोअरकेस snapotter-data का उपयोग होता था जबकि Compose फ़ाइलें SnapOtter-data का उपयोग करती हैं। पुष्टि करें कि आपके पास कौन सा है:

docker volume ls | grep -i snapotter

अपने 2.0 कॉन्फ़िगरेशन में ठीक वही नाम उपयोग करें।

पथ A: सिंगल container (सबसे तेज़)

यदि आप SnapOtter को एक ही docker run के साथ चलाते हैं, तो ऐसा करना जारी रखें। जब आप DATABASE_URL या REDIS_URL सेट नहीं करते, तो 2.0 container के अंदर एक एम्बेडेड PostgreSQL और Redis बूट करता है, और पहली बूट पर /data/snapotter.db को स्वतः-पहचानता और इम्पोर्ट करता है।

docker run -d --name snapotter -p 1349:1349 \
  -v SnapOtter-data:/data \
  snapotter/snapotter:latest

लॉग में इस तरह की एक पंक्ति देखें:

Imported 1.x SQLite database: {"tables":{"users":2,"teams":1,...},"blobs":{"present":1,"missing":0}}

बस इतना ही। अपने मौजूदा क्रेडेंशियल के साथ लॉग इन करें।

पथ B: Compose (प्रोडक्शन के लिए अनुशंसित)

2.0 Compose स्टैक तीन सेवाएँ चलाता है (app, Postgres, Redis)। app सेवा के लिए अपने 1.x /data वॉल्यूम का पुनः उपयोग करें। app पहली बूट पर /data/snapotter.db को स्वतः-पहचानता है और इसे Postgres में इम्पोर्ट करता है।

services:
  SnapOtter:
    image: snapotter/snapotter:latest
    volumes:
      - SnapOtter-data:/data          # your existing 1.x volume
      - SnapOtter-workspace:/tmp/workspace
    environment:
      - DATABASE_URL=postgres://snapotter:snapotter@postgres:5432/snapotter
      - REDIS_URL=redis://:snapotter@redis:6379
    # ...

यदि आप पुराने डेटाबेस को स्पष्ट रूप से इंगित करना चाहें, तो SQLITE_MIGRATE_PATH=/data/snapotter.db सेट करें। एक स्पष्ट पथ हमेशा स्वतः-पहचान पर भारी पड़ता है।

पहले इम्पोर्ट का पूर्वावलोकन करें (वैकल्पिक)

बिना कुछ लिखे ठीक-ठीक देखने के लिए कि क्या इम्पोर्ट होगा, अपनी डेटाबेस फ़ाइल के विरुद्ध एक ड्राई रन चलाएँ:

pnpm --filter @snapotter/api migrate:sqlite -- /path/to/snapotter.db --dry-run

यह प्रति टेबल पंक्ति गणना, डिस्क पर मिली कितनी सहेजी-गई-लाइब्रेरी फ़ाइलें, और किसी भी जॉब स्थिति को जिसे वह सामान्यीकृत करेगा, प्रिंट करता है। इसे किसी चालू Postgres की आवश्यकता नहीं होती।

क्या साथ आता है, और क्या नहीं

साथ आता है:

उपयोगकर्ता, और लॉग इन करने की क्षमता। पासवर्ड हैश अपरिवर्तित रहते हैं, इसलिए वही उपयोगकर्ता नाम और पासवर्ड काम करते हैं।
Teams, सेटिंग्स (आपकी इंस्टेंस पहचान सहित), roles, API keys (वे काम करते रहते हैं), और सहेजी गई pipelines।
जॉब इतिहास रिकॉर्ड।
आपकी सहेजी-गई-फ़ाइल लाइब्रेरी, रिकॉर्ड और वास्तविक फ़ाइलें दोनों, क्योंकि /data/files वॉल्यूम पर संरक्षित रहता है।

साथ नहीं आता:

लॉगिन सत्र। अपग्रेड के बाद सभी एक बार साइन इन करते हैं। क्रेडेंशियल अपरिवर्तित रहते हैं, इसलिए यह एक बार का पुनः-लॉगिन है, इससे अधिक कुछ नहीं।
पुराने प्रोसेसिंग जॉब की इनपुट और आउटपुट फ़ाइलें। वे एक अस्थायी वर्कस्पेस में रहती थीं और डिज़ाइन के अनुसार चली जाती हैं। जॉब इतिहास रिकॉर्ड बने रहते हैं।
1.x से प्रति-उपयोगकर्ता एनालिटिक्स-सहमति फ़्लैग, जिनका कोई 2.0 समकक्ष नहीं है (2.0 एनालिटिक्स एक इंस्टेंस-स्तरीय सेटिंग है)।

इम्पोर्ट को बंद करना

यदि आप जानबूझकर एक ताज़ा डेटाबेस चाहते हैं, भले ही वॉल्यूम पर एक snapotter.db मौजूद हो, तो SQLITE_MIGRATE_PATH=off सेट करें।

यदि 2.0 इंस्टेंस में आपके पास पहले से डेटा है

इम्पोर्टर केवल एक खाली डेटाबेस में ही चलता है। यदि आपने 2.0 को ताज़ा शुरू किया (डेटा बनाते हुए), फिर बाद में एक पुराना snapotter.db माउंट किया, तो 2.0 इसे पहचानेगा लेकिन इम्पोर्ट नहीं करेगा, क्योंकि दो डेटासेट मर्ज करने से IDs टकरा सकती हैं। आपको लॉग में एक चेतावनी दिखेगी। 1.x डेटा इम्पोर्ट करने के लिए आपको एक खाली इंस्टेंस चाहिए:

यदि 2.0 इंस्टेंस में केवल डिफ़ॉल्ट एडमिन है (आपने वास्तव में इसका उपयोग नहीं किया), तो स्टैक रोकें, Postgres वॉल्यूम हटाएँ (SnapOtter-pgdata), और पुराने /data के मौजूद रहते हुए फिर से बूट करें। यह साफ़ इम्पोर्ट कर लेगा। इससे केवल फेंकने-योग्य Postgres डेटा मिटता है, आपका 1.x डेटाबेस नहीं।
यदि 2.0 इंस्टेंस में वास्तविक डेटा है जिसे आप रखना चाहते हैं, तो दोनों डेटासेट स्वतः-मर्ज नहीं किए जा सकते। जो आपको चाहिए उसे एक्सपोर्ट करें और 1.x डेटा को एक अलग ताज़ा डिप्लॉयमेंट में इम्पोर्ट करें।

रोल बैक करना

अपग्रेड आपके 1.x snapotter.db को कभी संशोधित या हटाता नहीं है। यदि आपको 1.x पर वापस जाना है, तो उसी वॉल्यूम के विरुद्ध 1.x इमेज पुनः डिप्लॉय करें। अपग्रेड के बाद 2.0 में आपने जो कुछ भी बनाया वह Postgres में रहता है और 1.x डेटाबेस में नहीं होगा, इसलिए यदि आप वापस जाने वाले हैं तो तुरंत रोल बैक करें।

14 KiB Raw Blame History