วิธีตั้งค่าการสำรองข้อมูลฐานข้อมูลอัตโนมัติสำหรับ ownCloud Server

คุณจะพบจุดอ่อนในแผนสำรองข้อมูลในเวลาที่แย่ที่สุดเท่าที่จะเป็นไปได้: การอัปเกรดล้มเหลว ตารางฐานข้อมูลเสียหาย หรือเซิร์ฟเวอร์หายไป และ "การสำรองข้อมูล" เพียงอย่างเดียวคือสำเนาไฟล์ผู้ใช้ ซึ่งไม่เพียงพอสำหรับ ownCloud Server ฐานข้อมูลเก็บสถานะแอปพลิเคชันที่สำคัญ เช่น ผู้ใช้ การแชร์ เมตาเดต้าไฟล์ และข้อมูลการกำหนดค่า แผนการกู้คืนที่เชื่อถือได้จำเป็นต้องมีทั้งฐานข้อมูล ไฟล์ และการกำหนดค่าที่อยู่ในช่วงเวลาเดียวกัน

คู่มือนี้แสดงวิธีปฏิบัติในการสำรองข้อมูลฐานข้อมูล ownCloud บน Linux โดยอัตโนมัติ เริ่มต้นจากการสำรองข้อมูลด้วยตนเองและจบลงด้วยการตั้งเวลาสำรองข้อมูลที่ผ่านการตรวจสอบแล้ว ตัวอย่างเน้นที่ MySQL/MariaDB เนื่องจาก ownCloud แนะนำให้ใช้เอนจิ้นเหล่านั้น และยังมีตัวอย่าง PostgreSQL รวมอยู่ด้วย คำสั่งต่างๆ สอดคล้องกับเอกสารการดูแลระบบ ownCloud Server 11.0 ฉบับปัจจุบัน พร้อมทั้งระบุความแตกต่างของคำสั่งสำหรับการติดตั้งแบบดั้งเดิมที่ไม่ใช้ Docker

ก่อนอื่น ต้องเข้าใจว่าการสำรองข้อมูลฐานข้อมูลไม่ครอบคลุมอะไรบ้าง

การสำรองฐานข้อมูลเป็นเพียงส่วนหนึ่งของการสำรองข้อมูล ownCloud เท่านั้นเอกสารการสำรองข้อมูล ownCloud Server 11.0ระบุว่าฐานข้อมูลจะถูกสำรองพร้อมกับไดเร็กทอรีการกำหนดค่า ไดเร็กทอรีข้อมูล ไดเร็กทอรีแอปพลิเคชัน (ถ้ามี) และไฟล์ธีมที่กำหนดเอง ไดเร็กทอรีข้อมูลอาจมีคีย์การเข้ารหัสด้วย ดังนั้นการสำรองข้อมูลเฉพาะฐานข้อมูลจึงไม่สามารถสร้างเซิร์ฟเวอร์ขึ้นมาใหม่ได้อย่างสมบูรณ์หลังจากข้อมูลสูญหายทั้งหมด

ใช้ระบบอัตโนมัติที่ระบุไว้ด้านล่างสำหรับการปกป้องฐานข้อมูล แต่ควรใช้ควบคู่กับกลยุทธ์การสำรองข้อมูลระดับไฟล์หรือการสร้างสแนปช็อตสำหรับส่วนที่เหลือของการติดตั้ง ownCloud เมื่อคุณต้องการจุดกู้คืนที่สอดคล้องกันอย่างสมบูรณ์ ให้ประสานการดัมพ์ฐานข้อมูลและการสำรองไฟล์ในหน้าต่างการบำรุงรักษาเดียวกัน

ขั้นตอนที่ 1: ตรวจสอบว่า ownCloud ใช้ฐานข้อมูลใด

ก่อนที่จะเขียนคำสั่งสำรองข้อมูล ให้ระบุประเภทฐานข้อมูล โฮสต์ ชื่อฐานข้อมูล และผู้ใช้ ในการติดตั้ง ownCloud แบบคลาสสิก ค่าเหล่านี้มักจะอยู่ในconfig/config.php. นอกจากนี้ คุณยังสามารถตรวจสอบการกำหนดค่าระบบด้วยเครื่องมือบรรทัดคำสั่ง ownCloud ได้อีกด้วย ตัวอย่างเช่น จากไดเร็กทอรี ownCloud:

sudo -u www-data ./occ config:list system

ในการใช้งาน Docker Compose เอกสารปัจจุบันใช้คำสั่งต่างๆ เช่น:

docker compose exec owncloud occ config:list system

มองหาค่าต่างๆ เช่นdbtype, dbhost, dbname, และdbuserownCloud Server 11.0 รองรับ MySQL/MariaDB และ PostgreSQL อย่างเป็นทางการ โดยแนะนำให้ใช้ MySQL หรือ MariaDB สำหรับการใช้งานทั่วไป

ขั้นตอนที่ 2: สร้างพื้นที่สำรองข้อมูลที่ปลอดภัย

สร้างไดเร็กทอรีเฉพาะที่ไม่สามารถเข้าถึงได้ผ่านเว็บ การกำหนดให้ผู้ใช้ root เป็นเจ้าของถือเป็นค่าเริ่มต้นที่เหมาะสมเมื่อเรียกใช้งานงานที่กำหนดไว้จาก crontab ของผู้ใช้ root:

sudo mkdir -p /var/backups/owncloud-db
sudo chown root:root /var/backups/owncloud-db
sudo chmod 700 /var/backups/owncloud-db

ตรวจสอบพื้นที่ว่างด้วยคำสั่งdf -h /var/backups/owncloud-db`npm run data` งานสำรองข้อมูลที่ทำการเติมพื้นที่ดิสก์ของระบบโดยไม่แจ้งให้ทราบล่วงหน้า อาจทำให้เกิดปัญหาขัดข้องครั้งที่สองในขณะที่พยายามป้องกันปัญหาครั้งแรก

ขั้นตอนที่ 3: อย่าใส่ข้อมูลรับรองฐานข้อมูลลงในคำสั่ง cron

อย่าใส่รหัสผ่านฐานข้อมูลลงในบรรทัด crontab โดยตรง สำหรับ MySQL หรือ MariaDB ไฟล์ตัวเลือกไคลเอ็นต์ที่ root สามารถอ่านได้นั้นง่ายและใช้งานได้ดีกับงานอัตโนมัติ สร้าง/etc/owncloud/db-backup.cnf:

[client]
user=ownclouduser
password=REPLACE_WITH_DATABASE_PASSWORD
host=localhost

จากนั้นให้จำกัดขอบเขต:

sudo chown root:root /etc/owncloud/db-backup.cnf
sudo chmod 600 /etc/owncloud/db-backup.cnf

ใช้ค่าจริงจากไฟล์การกำหนดค่า ownCloud ของคุณ หากฐานข้อมูลของคุณอยู่บนเซิร์ฟเวอร์ระยะไกล ให้ตั้งค่าโฮสต์ให้เหมาะสม คู่มือ MySQL อธิบายไฟล์ตัวเลือกสำหรับโปรแกรมไคลเอ็นต์ และวิธีนี้จะช่วยหลีกเลี่ยงการเปิดเผยรหัสผ่านโดยตรงในคำสั่งที่กำหนดเวลาไว้

ขั้นตอนที่ 4: เรียกใช้การสำรองข้อมูลด้วยตนเองหนึ่งครั้งในโหมดบำรุงรักษา

ขั้นตอนการสำรองข้อมูลอย่างเป็นทางการของ ownCloud ระบุว่าให้ป้องกันการเข้าถึงตามปกติและตั้งค่าอินสแตนซ์ให้อยู่ในโหมดบำรุงรักษา ก่อนที่จะสำรองข้อมูลฐานข้อมูล สำหรับการใช้งาน Docker Compose:

docker compose exec owncloud occ maintenance:mode --on

สำหรับการติดตั้งแบบดั้งเดิมจากไดเร็กทอรี ownCloud:

sudo -u www-data ./occ maintenance:mode --on

โหมดบำรุงรักษาจะปิดกั้นกิจกรรมของผู้ใช้ตามปกติในขณะที่กำลังสร้างจุดกู้คืน นั่นหมายความว่างานอัตโนมัติควรทำงานในช่วงเวลาที่มีการใช้งานน้อย และต้องปิดโหมดบำรุงรักษาเสมอ แม้ว่าการสำรองข้อมูลจะล้มเหลวก็ตาม

สำหรับ MySQL หรือ MariaDB ให้ทดสอบการดัมพ์ข้อมูลด้วยตนเอง:

sudo mysqldump   --defaults-extra-file=/etc/owncloud/db-backup.cnf   --single-transaction   --quick   owncloud   | gzip -c > /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).sql.gz

เอกสารประกอบของ ownCloud ใช้ตัว เลือก `mysqldump` ส่วนเอกสารอ้างอิง mysqldumpmysqldump --single-transactionของ MySQL เองอธิบายว่า ตัวเลือกนี้ สร้างสแนปช็อตที่สอดคล้องกันสำหรับตารางธุรกรรม เช่น InnoDB โดยไม่ต้องล็อกตารางตลอดระยะเวลาการสำรองข้อมูลตัวเลือกนี้จะสตรีมแถวแทนที่จะบัฟเฟอร์ตารางขนาดใหญ่ไว้ในหน่วยความจำ--single-transaction--quick

เมื่อการสำรองข้อมูลด้วยตนเองเสร็จสมบูรณ์แล้ว ให้ปิดโหมดบำรุงรักษาโดยใช้คำสั่งที่เกี่ยวข้อง:

docker compose exec owncloud occ maintenance:mode --off

หรือ:

sudo -u www-data ./occ maintenance:mode --off

ขั้นตอนที่ 5: ใส่ตรรกะการสำรองข้อมูลลงในสคริปต์ที่ปลอดภัยจากความล้มเหลว

สคริปต์ควรหยุดทำงานเมื่อเกิดข้อผิดพลาด บันทึกเวลา เปิดใช้งานโหมดบำรุงรักษา สร้างไฟล์สำรองข้อมูล ตรวจสอบไฟล์บีบอัด ใช้ระยะเวลาการเก็บรักษา และตรวจสอบให้แน่ใจว่าได้ปิดใช้งานโหมดบำรุงรักษาเมื่อสิ้นสุดการทำงาน ตัวอย่างต่อไปนี้สมมติว่าเป็นการติดตั้งแบบคลาสสิกที่/var/www/owncloudและฐานข้อมูล MySQL/MariaDB ที่ชื่อว่าowncloud:

#!/bin/bash
set -Eeuo pipefail

OC_ROOT="/var/www/owncloud"
BACKUP_DIR="/var/backups/owncloud-db"
DB_NAME="owncloud"
MYSQL_CNF="/etc/owncloud/db-backup.cnf"
STAMP="$(date +%Y%m%d-%H%M%S)"
OUT="$BACKUP_DIR/owncloud-db-$STAMP.sql.gz"

cleanup() {
  cd "$OC_ROOT"
  sudo -u www-data ./occ maintenance:mode --off || true
}
trap cleanup EXIT

mkdir -p "$BACKUP_DIR"
cd "$OC_ROOT"
sudo -u www-data ./occ maintenance:mode --on

mysqldump   --defaults-extra-file="$MYSQL_CNF"   --single-transaction   --quick   "$DB_NAME" | gzip -c > "$OUT"

test -s "$OUT"
gzip -t "$OUT"

find "$BACKUP_DIR"   -type f   -name 'owncloud-db-*.sql.gz'   -mtime +14   -delete

บันทึกไฟล์/usr/local/sbin/owncloud-db-backup.shเป็น .document ...chmod 700occ

ขั้นตอนที่ 6: ตั้งเวลาด้วย cron

หลังจากรันด้วยตนเองสำเร็จแล้ว ให้กำหนดเวลาการทำงานของสคริปต์ เปิด crontab ของผู้ใช้ root:

sudo crontab -e

สำหรับการวิ่งประจำวันเวลา 02:15 น.:

15 2 * * * /usr/local/sbin/owncloud-db-backup.sh >> /var/log/owncloud-db-backup.log 2>&1

เลือกเวลาที่ตรงกับรูปแบบการใช้งานจริงของคุณ หากฐานข้อมูลมีขนาดใหญ่ ให้วัดระยะเวลาที่การเรียกใช้งานด้วยตนเองก่อน เนื่องจากโหมดบำรุงรักษาจะทำให้เกิดการหยุดชะงักของบริการที่เห็นได้ชัด นอกจากนี้ ตรวจสอบให้แน่ใจว่า cron มีสภาพแวดล้อมที่คาดเดาได้: ใช้พาธแบบสัมบูรณ์ในสคริปต์หากคำสั่งที่จำเป็นไม่ได้อยู่ในค่าเริ่มต้นของPATHcron

ขั้นตอนที่ 7: ตรวจสอบความถูกต้องของข้อมูลสำรองทุกครั้ง แทนที่จะเชื่อถือเวลาประทับเพียงอย่างเดียว

ไฟล์ที่มีวันที่ปัจจุบันไม่ใช่หลักฐานยืนยันว่าสามารถกู้คืนข้อมูลสำรองได้ อย่างน้อยที่สุด ตรวจสอบให้แน่ใจว่าไฟล์นั้นไม่ว่างเปล่า การบีบอัดด้วย gzip ไม่พบความเสียหาย และบันทึกการทำงานไม่มีข้อผิดพลาดใดๆ

ls -lh /var/backups/owncloud-db/
gzip -t /var/backups/owncloud-db/owncloud-db-YYYYMMDD-HHMMSS.sql.gz
tail -n 100 /var/log/owncloud-db-backup.log

เพื่อการทดสอบที่เข้มงวดมากขึ้น ให้กู้คืนข้อมูลสำรองล่าสุดลงในฐานข้อมูลชั่วคราวบนระบบที่ไม่ใช่ระบบใช้งานจริง อย่าทดสอบการกู้คืนโดยการเขียนทับฐานข้อมูลที่ใช้งานอยู่ การทดสอบการกู้คืนจริงจะตรวจสอบมากกว่าแค่ความสมบูรณ์ของไฟล์: มันจะตรวจสอบข้อมูลประจำตัว สิทธิ์การเข้าถึงฐานข้อมูล ความเข้ากันได้ของข้อมูลสำรอง และขั้นตอนการกู้คืนที่ทีมของคุณจะใช้จริง

ขั้นตอนที่ 8: ตรวจสอบว่า ownCloud กลับมาใช้งานได้ตามปกติแล้วหรือไม่

หลังจากสคริปต์ทำงานเสร็จสิ้น โหมดบำรุงรักษาควรปิดลง และผู้ใช้ควรจะสามารถเข้าสู่ระบบได้ตามปกติ ตรวจสอบอินเทอร์เฟซเว็บและตรวจสอบบันทึกการสำรองข้อมูล ระบบอัตโนมัติที่มีประสิทธิภาพไม่ได้หมายถึงแค่การสร้างไฟล์สำรองข้อมูลเท่านั้น แต่ยังหมายถึงระบบที่ล้มเหลวอย่างปลอดภัยและไม่ทำให้บริการติดอยู่ในโหมดบำรุงรักษาด้วย

หากใช้ PostgreSQL จะมีการเปลี่ยนแปลงอะไรบ้าง?

เอกสารเกี่ยวกับการสำรองข้อมูลของ ownCloud ใช้pg_dumpรูปแบบไฟล์เก็บถาวรสำหรับ PostgreSQL เอกสาร pg_dump อย่างเป็นทางการ ของ PostgreSQL ระบุว่า การสร้างไฟล์ส่งออกที่สอดคล้องกันแม้ในขณะที่ฐานข้อมูลกำลังถูกใช้งานอยู่ บทเกี่ยวกับการสำรองและกู้คืนข้อมูลของ PostgreSQLpg_dumpที่ครอบคลุมกว่านั้นยังแยกความแตกต่างระหว่างการดัมพ์แบบลอจิกกับการสำรองข้อมูลระบบไฟล์และการเก็บถาวรอย่างต่อเนื่องด้วย

คำสั่งง่ายๆ ที่ใช้กับ ownCloud คือ:

PGPASSWORD="REPLACE_WITH_PASSWORD" pg_dump owncloud   -h localhost   -U ownclouduser   -F tar   -f /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).tar

สำหรับการทำงานแบบอัตโนมัติ ควรเลือกใช้กลไกการสร้างไฟล์รหัสผ่านที่ PostgreSQL รองรับแทนการฝังไว้PGPASSWORDในสคริปต์ และคงหลักการบำรุงรักษา การเก็บรักษา การบันทึก และการทดสอบการกู้คืนไว้เช่นเดิม

คุณควรเก็บสำเนาสำรองไว้กี่ชุด?

ไม่มีระยะเวลาการเก็บรักษาข้อมูลใดที่เหมาะสมกับเซิร์ฟเวอร์ ownCloud ทุกเครื่อง ควรเลือกระยะเวลาการเก็บรักษาข้อมูลให้เหมาะสมกับความเร็วในการเปลี่ยนแปลงของข้อมูล พื้นที่จัดเก็บข้อมูลที่มีอยู่ และระยะเวลาที่คุณอาจต้องการกู้คืนข้อมูลย้อนหลัง การสำรองข้อมูลฐานข้อมูลวันละ 14 ครั้งเป็นตัวอย่างที่เหมาะสมสำหรับเซิร์ฟเวอร์ขนาดเล็ก แต่ไม่ใช่ข้อกำหนดที่ใช้ได้กับทุกเซิร์ฟเวอร์

การตรวจสอบตนเองครั้งสุดท้าย

การสำรองข้อมูลฐานข้อมูลอัตโนมัติของคุณจะพร้อมใช้งานก็ต่อเมื่อข้อความต่อไปนี้เป็นจริงทั้งหมด:

• คุณทราบแล้วว่าเซิร์ฟเวอร์ใช้ MySQL/MariaDB หรือ PostgreSQL และได้ตรวจสอบชื่อฐานข้อมูลและโฮสต์ที่ถูกต้องแล้ว
• โฟลเดอร์สำรองข้อมูลได้รับการปกป้องและมีพื้นที่ว่างเพียงพอ
• ข้อมูลประจำตัวจะไม่ถูกเปิดเผยในคำสั่ง crontab
• การสำรองข้อมูลด้วยตนเองเสร็จสมบูรณ์ก่อนที่จะเปิดใช้งานการตั้งเวลา
• สคริปต์จะออกจากโหมดบำรุงรักษาเสมอ แม้หลังจากที่การสำรองข้อมูลล้มเหลวก็ตาม
• งานที่กำหนดไว้จะเขียนบันทึกและสร้างไฟล์สำรองข้อมูลที่ไม่ว่างเปล่าตรงเวลา
• การกำจัดกองขยะเก่าจะดำเนินการตามนโยบายการรักษาพื้นที่อย่างรอบคอบ
• การกู้คืนข้อมูลสำรองล่าสุดไปยังฐานข้อมูลที่ไม่ใช่ฐานข้อมูลใช้งานจริงสำเร็จแล้ว
• การสำรองข้อมูลฐานข้อมูลจะดำเนินการควบคู่ไปกับการสำรองข้อมูล ownCloud, การตั้งค่า และไดเร็กทอรีอื่นๆ ที่จำเป็น

หากการตรวจสอบใดๆ ล้มเหลว ให้แก้ไขจุดนั้นก่อนที่จะพึ่งพาการทำงานอัตโนมัติ ระบบสำรองข้อมูลจะมีประโยชน์ก็ต่อเมื่อได้ทดสอบเส้นทางการกู้คืนแล้ว