SnapOtter/apps/docs/th/guide/upgrading.md

---
i18n_source_hash: 9a6abf3fc8ae
i18n_provenance: human
i18n_output_hash: a1ade9bc05db
---
# การอัปเกรดจาก 1.x เป็น 2.0 {#upgrading-from-1-x-to-2-0}

SnapOtter 1.x จัดเก็บทุกอย่างในไฟล์ SQLite ไฟล์เดียวและทำงานเป็นคอนเทนเนอร์เดียว SnapOtter 2.0 ใช้ PostgreSQL และ Redis คู่มือนี้อธิบายขั้นตอนการย้ายการติดตั้ง 1.x ไปยัง 2.0 โดยไม่สูญเสียข้อมูล

โดยสรุป: ใช้โวลุ่ม `/data` เดิมของคุณซ้ำ แล้ว 2.0 จะนำเข้าฐานข้อมูล 1.x ของคุณโดยอัตโนมัติในการบูตครั้งแรก ผู้ใช้ ไฟล์ที่บันทึกไว้ การตั้งค่า API key และไปป์ไลน์ของคุณจะถูกย้ายมาด้วย ฐานข้อมูลเดิมจะไม่ถูกแก้ไข ดังนั้นคุณสามารถย้อนกลับได้เสมอ

::: tip หมายเหตุถึงผู้ใช้ 1.x ของเรา
พวกคุณหลายคนไว้วางใจ SnapOtter มาตั้งแต่วันแรก และคำติชมของคุณได้หล่อหลอมรีลีสนี้ 2.0 เปลี่ยนแปลงหลายอย่างเบื้องหลัง และคู่มือนี้มีอยู่เพื่อให้การย้ายไม่ทำให้คุณต้องเสียสิ่งที่คุณใส่ใจ บัญชี ไฟล์ การตั้งค่า API key และไปป์ไลน์ของคุณจะถูกย้ายมา และฐานข้อมูลเดิมของคุณจะไม่ถูกแตะต้อง ขอบคุณที่อัปเกรดไปพร้อมกับเรา
:::

## ก่อนเริ่ม: สำรองข้อมูลโวลุ่ม `/data` ทั้งหมด {#before-you-start-back-up-the-whole-data-volume}

ทำสิ่งนี้ก่อนเสมอ ทุกครั้ง สำรองข้อมูลโวลุ่ม `/data` **ทั้งหมด** ไม่ใช่แค่ไฟล์ `snapotter.db`

นี่คือเหตุผลว่าทำไมมันจึงสำคัญ 1.x รัน SQLite ในโหมด WAL ดังนั้นคอนเทนเนอร์ 1.x ที่หยุดทำงานมักจะทิ้งข้อมูลที่คอมมิตไว้ส่วนใหญ่ไว้ใน `snapotter.db-wal` ข้าง ๆ `snapotter.db` ที่แทบว่างเปล่า การคัดลอกเฉพาะ `snapotter.db` จะได้ฐานข้อมูลที่ว่างเปล่าและสูญเสียทุกอย่างไปแบบเงียบ ๆ โวลุ่มบรรจุ `snapotter.db`, `snapotter.db-wal`, `snapotter.db-shm` และไดเรกทอรี `files/` ของคุณไว้ด้วยกัน และต้องเดินทางไปพร้อมกันเป็นชุด

```bash
# 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 ก่อน {#upgrade-to-1-17-2-first}

อัปเกรดการติดตั้ง 1.x ของคุณให้เป็นรีลีส 1.x ล่าสุด (1.17.2) ก่อนย้ายไปยัง 2.0 นั่นช่วยให้ 1.x รันการย้ายสคีมาสุดท้ายของตัวเอง ดังนั้น 2.0 จึงนำเข้าจากสคีมาที่รู้จักและครบถ้วน การอัปเกรดจาก 1.x รุ่นเก่ากว่าไปยัง 2.0 โดยตรงไม่ได้รับการรองรับ

## ตรวจสอบชื่อโวลุ่มของคุณ {#check-your-volume-name}

ตัวนำเข้าจะเห็นข้อมูลของคุณก็ต่อเมื่อสแตก 2.0 เมานต์โวลุ่มเดียวกับที่การติดตั้ง 1.x ของคุณใช้ ชื่อโวลุ่มของ Docker เป็นแบบตัวพิมพ์ใหญ่เล็กมีผล และสนิปเพ็ต README รุ่นเก่าใช้ `snapotter-data` ตัวพิมพ์เล็ก ในขณะที่ไฟล์ Compose ใช้ `SnapOtter-data` ยืนยันว่าคุณมีตัวไหน:

```bash
docker volume ls | grep -i snapotter
```

ใช้ชื่อนั้นให้ตรงเป๊ะในการกำหนดค่า 2.0 ของคุณ

## เส้นทาง A: คอนเทนเนอร์เดียว (เร็วที่สุด) {#path-a-single-container-quickest}

หากคุณรัน SnapOtter ด้วย `docker run` เดียว ก็ทำแบบนั้นต่อไป 2.0 จะบูต PostgreSQL และ Redis แบบฝังตัวภายในคอนเทนเนอร์เมื่อคุณไม่ได้ตั้งค่า `DATABASE_URL` หรือ `REDIS_URL` และตรวจจับพร้อมนำเข้า `/data/snapotter.db` โดยอัตโนมัติในการบูตครั้งแรก

```bash
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 (แนะนำสำหรับการใช้งานจริง) {#path-b-compose-recommended-for-production}

สแตก Compose ของ 2.0 รันสามบริการ (แอป, Postgres, Redis) ใช้โวลุ่ม `/data` ของ 1.x ซ้ำสำหรับบริการแอป แอปจะตรวจจับ `/data/snapotter.db` และนำเข้าสู่ Postgres โดยอัตโนมัติในการบูตครั้งแรก

```yaml
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` พาธที่ระบุชัดเจนจะมีผลเหนือการตรวจจับอัตโนมัติเสมอ

## ดูตัวอย่างการนำเข้าก่อน (ไม่บังคับ) {#preview-the-import-first-optional}

หากต้องการดูว่าจะนำเข้าอะไรบ้างอย่างแม่นยำโดยไม่เขียนอะไรลงไป ให้รันแบบ dry run กับไฟล์ฐานข้อมูลของคุณ:

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

มันจะพิมพ์จำนวนแถวต่อตาราง จำนวนไฟล์ในไลบรารีที่บันทึกไว้ที่พบบนดิสก์ และสถานะงานใด ๆ ที่มันจะทำให้เป็นปกติ มันไม่ต้องการ Postgres ที่กำลังรันอยู่

## อะไรถูกย้ายมา และอะไรไม่ถูกย้าย {#what-carries-over-and-what-does-not}

ถูกย้ายมา:

- ผู้ใช้ และความสามารถในการเข้าสู่ระบบ แฮชรหัสผ่านไม่เปลี่ยนแปลง ดังนั้นชื่อผู้ใช้และรหัสผ่านเดิมยังใช้งานได้
- ทีม การตั้งค่า (รวมถึงข้อมูลระบุตัวตนของอินสแตนซ์) บทบาท API key (ยังใช้งานได้ต่อไป) และไปป์ไลน์ที่บันทึกไว้
- ระเบียนประวัติงาน
- ไลบรารีไฟล์ที่บันทึกไว้ของคุณ ทั้งระเบียนและตัวไฟล์จริง เพราะ `/data/files` ถูกรักษาไว้บนโวลุ่ม

ไม่ถูกย้ายมา:

- เซสชันการเข้าสู่ระบบ ทุกคนต้องเข้าสู่ระบบหนึ่งครั้งหลังการอัปเกรด ข้อมูลรับรองไม่เปลี่ยนแปลง ดังนั้นเป็นแค่การเข้าสู่ระบบใหม่ครั้งเดียว ไม่มีอะไรมากกว่านั้น
- ไฟล์อินพุตและเอาต์พุตของงานประมวลผลเดิม สิ่งเหล่านั้นอยู่ในพื้นที่ทำงานชั่วคราวและหายไปโดยการออกแบบ ระเบียนประวัติงานยังคงอยู่
- แฟล็กการยินยอมด้านการวิเคราะห์เฉพาะผู้ใช้จาก 1.x ซึ่งไม่มีสิ่งเทียบเท่าใน 2.0 (การวิเคราะห์ของ 2.0 เป็นการตั้งค่าระดับอินสแตนซ์)

## การปิดการนำเข้า {#turning-the-import-off}

หากคุณตั้งใจต้องการฐานข้อมูลใหม่เอี่ยมแม้ว่าจะมี `snapotter.db` อยู่บนโวลุ่ม ให้ตั้งค่า `SQLITE_MIGRATE_PATH=off`

## หากคุณมีข้อมูลในอินสแตนซ์ 2.0 อยู่แล้ว {#if-you-already-have-data-in-the-2-0-instance}

ตัวนำเข้าจะทำงานเฉพาะกับฐานข้อมูลที่ว่างเปล่าเท่านั้น หากคุณเริ่ม 2.0 ใหม่เอี่ยม (สร้างข้อมูล) แล้วภายหลังเมานต์ `snapotter.db` เดิม 2.0 จะตรวจจับมันแต่จะไม่นำเข้า เพราะการรวมสองชุดข้อมูลอาจชนกันที่ ID คุณจะเห็นคำเตือนในบันทึก หากต้องการนำเข้าข้อมูล 1.x คุณต้องมีอินสแตนซ์ที่ว่างเปล่า:

- หากอินสแตนซ์ 2.0 มีเพียงผู้ดูแลระบบเริ่มต้น (คุณยังไม่ได้ใช้งานจริง) ให้หยุดสแตก ลบโวลุ่ม Postgres (`SnapOtter-pgdata`) แล้วบูตอีกครั้งโดยมี `/data` เดิมอยู่ มันจะนำเข้าได้อย่างสะอาด สิ่งนี้ล้างเฉพาะข้อมูล Postgres แบบทิ้งได้เท่านั้น ไม่ใช่ฐานข้อมูล 1.x ของคุณ
- หากอินสแตนซ์ 2.0 มีข้อมูลจริงที่คุณต้องการเก็บไว้ สองชุดข้อมูลไม่สามารถรวมกันโดยอัตโนมัติได้ ให้เอ็กซ์พอร์ตสิ่งที่คุณต้องการและนำเข้าข้อมูล 1.x ไปยังการปรับใช้ใหม่เอี่ยมแยกต่างหาก

## การย้อนกลับ {#rolling-back}

การอัปเกรดจะไม่แก้ไขหรือลบ `snapotter.db` 1.x ของคุณ หากคุณต้องการกลับไปใช้ 1.x ให้ปรับใช้อิมเมจ 1.x อีกครั้งกับโวลุ่มเดียวกัน สิ่งที่คุณสร้างใน 2.0 หลังการอัปเกรดอยู่ใน Postgres และจะไม่อยู่ในฐานข้อมูล 1.x ดังนั้นให้ย้อนกลับโดยเร็วหากคุณจะทำ