Cum se configurează copii de rezervă automate ale bazei de date pentru serverul ownCloud

Descoperiți slăbiciunea unui plan de backup în cel mai nepotrivit moment posibil: o actualizare eșuează, un tabel al bazei de date este deteriorat sau un server dispare, iar singura „backup” este o copie a fișierelor utilizatorului. Acest lucru nu este suficient pentru ownCloud Server. Baza de date conține stările critice ale aplicației, cum ar fi utilizatorii, partajările, metadatele fișierelor și datele de configurare. Un plan de recuperare fiabil are nevoie atât de baza de date, cât și de fișierele și configurația care aparțin aceluiași moment în timp.

Acest ghid prezintă o modalitate practică de a automatiza copiile de rezervă ale bazei de date ownCloud pe Linux, începând cu un dump manual și terminând cu un job programat și verificat. Exemplele se concentrează pe MySQL/MariaDB deoarece ownCloud recomandă aceste motoare și este inclusă o variantă PostgreSQL. Comenzile sunt aliniate cu documentația actuală de administrare a ownCloud Server 11.0, menționând în același timp diferența de comenzi pentru instalările tradiționale non-Docker.

În primul rând, înțelegeți ce nu acoperă o copie de rezervă a bazei de date

Un dump al bazei de date este doar o parte a unei copii de rezervă ownCloud. Documentația de rezervă ownCloud Server 11.0 listează baza de date împreună cu directorul de configurare, directorul de date, directoarele de aplicații, atunci când este cazul, și fișierele temei personalizate. Directorul de date poate conține și chei de criptare, astfel încât o copie de rezervă doar a bazei de date nu poate reconstrui un server complet după pierderea totală a spațiului de stocare.

Folosește automatizarea de mai jos pentru protecția bazei de date, dar combin-o cu o strategie de backup la nivel de fișier sau cu un snapshot pentru restul instalării ownCloud. Când ai nevoie de un punct de recuperare complet consistent, coordonează dump-ul bazei de date și backup-ul fișierelor în aceeași fereastră de întreținere.

Pasul 1: Confirmați ce bază de date folosește ownCloud

Înainte de a scrie o comandă de backup, identificați tipul bazei de date, gazda, numele bazei de date și utilizatorul. Într-o instalare clasică ownCloud, aceste valori sunt disponibile în mod normal în config/config.php. De asemenea, puteți inspecta configurația sistemului cu instrumentul de linie de comandă ownCloud. De exemplu, din directorul ownCloud:

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

Într-o implementare Docker Compose, documentația actuală folosește comenzi precum:

docker compose exec owncloud occ config:list system

Căutați valori precum dbtype, dbhost, dbnameși dbuser. ownCloud Server 11.0 acceptă oficial MySQL/MariaDB și PostgreSQL, fiind recomandat MySQL sau MariaDB pentru implementări normale.

Pasul 2: Creați o locație de rezervă protejată

Creați un director dedicat care nu este accesibil prin web. Proprietatea dreptului de utilizator root este o opțiune implicită rezonabilă atunci când sarcina programată rulează din crontab-ul utilizatorului root:

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

Verificați spațiul liber cu df -h /var/backups/owncloud-db. O operațiune de backup care umple în mod silențios discul de sistem poate crea o a doua întrerupere în timp ce încearcă să ofere protecție împotriva primei.

Pasul 3: Nu includeți acreditările bazei de date în comanda cron

Nu puneți o parolă pentru baza de date direct în linia crontab. Pentru MySQL sau MariaDB, un fișier de opțiuni client care poate fi citit de root este simplu și funcționează bine cu joburi nesupravegheate. Creați /etc/owncloud/db-backup.cnf:

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

Apoi restricționați-l:

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

Folosește valorile reale din configurația ta ownCloud. Dacă baza ta de date este la distanță, setează gazda corespunzătoare. Manualul MySQL documentează fișierele de opțiuni pentru programele client, iar această abordare evită expunerea parolei direct într-o comandă programată.

Pasul 4: Executați o copie de rezervă manuală în modul de întreținere

Procedura oficială de backup a ownCloud prevede prevenirea accesului normal și plasarea instanței în modul de întreținere înainte de a face backup la baza de date. Pentru o implementare Docker Compose:

docker compose exec owncloud occ maintenance:mode --on

Pentru o instalare tradițională din directorul ownCloud:

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

Modul de întreținere blochează activitatea normală a utilizatorilor în timp ce se creează punctul de recuperare. Aceasta înseamnă că o lucrare automată ar trebui să ruleze într-o perioadă cu trafic redus și trebuie să dezactiveze întotdeauna modul de întreținere, chiar dacă dump-ul eșuează.

Pentru MySQL sau MariaDB, testați un dump manual:

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

Documentația ownCloud folosește . Referințamysqldump --single-transaction proprie mysqldump a MySQL explică faptul că creează o imagine consistentă pentru tabelele tranzacționale, cum ar fi InnoDB, fără a menține blocările tabelului pe durata dump-ului. Opțiunea transmite rânduri în flux, în loc să stocheze temporar un tabel mare în memorie.--single-transaction--quick

Când copia de rezervă manuală este completă, dezactivați modul de întreținere cu comanda corespunzătoare:

docker compose exec owncloud occ maintenance:mode --off

sau:

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

Pasul 5: Puneți logica de rezervă într-un script sigur la erori

Scriptul ar trebui să se oprească la erori, să înregistreze o marcă temporală, să activeze modul de întreținere, să creeze dump-ul, să verifice fișierul comprimat, să aplice retenția și să garanteze că modul de întreținere este dezactivat la ieșire. Următorul exemplu presupune o instalare clasică la /var/www/owncloudși o bază de date MySQL/MariaDB numită 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

Salvați-l ca /usr/local/sbin/owncloud-db-backup.sh, faceți-l executabil cu chmod 700, apoi rulați-l manual. Dacă ownCloud-ul dvs. este containerizat, înlocuiți cele două occlinii cu comenzile Docker Compose în modul de întreținere care corespund implementării dvs.

Pasul 6: Programați-l cu cron

După ce rularea manuală are succes, programați scriptul. Deschideți crontab-ul utilizatorului root:

sudo crontab -e

Pentru o cursă zilnică la ora 2:15 AM:

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

Alegeți un moment care corespunde modelului dvs. real de utilizare. Dacă baza de date este mare, măsurați mai întâi cât durează rularea manuală, deoarece modul de întreținere creează o întrerupere vizibilă a serviciului. De asemenea, asigurați-vă că cron are un mediu previzibil: utilizați căi absolute în script dacă comenzile necesare nu sunt în setările implicite ale cronului PATH.

Pasul 7: Verificați fiecare copie de rezervă în loc să aveți încredere în marcajul temporal

Un fișier cu data de astăzi nu este o dovadă a unei copii de rezervă recuperabile. Verificați cel puțin dacă fișierul nu este gol, dacă gzip nu raportează nicio corupție și dacă jurnalul de joburi nu conține erori de dump:

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

Pentru un test mai puternic, restaurați o dump recentă într-o bază de date de unică folosință pe un sistem care nu este de producție. Nu testați restaurarea suprascriind baza de date activă. Un exercițiu de restaurare real verifică mai mult decât integritatea fișierelor: confirmă acreditările, privilegiile bazei de date, compatibilitatea dump-urilor și procedura de recuperare pe care echipa dvs. ar utiliza-o efectiv.

Pasul 8: Confirmați că ownCloud a revenit la funcționarea normală

După finalizarea scriptului, modul de întreținere ar trebui să fie dezactivat, iar utilizatorii ar trebui să se poată conecta normal. Verificați interfața web și examinați jurnalul de backup. O automatizare robustă nu este doar una care creează o dump; este una care eșuează în siguranță și nu lasă serviciul blocat în modul de întreținere.

Ce se schimbă dacă folosești PostgreSQL?

Documentația de backup a ownCloud folosește pg_dumpun format de arhivă pentru PostgreSQL. Documentația oficială pg_dump a PostgreSQL precizează că pg_dumpcreează un export consistent chiar și în timp ce baza de date este utilizată. Capitolul mai amplu despre backup și restaurare PostgreSQL distinge, de asemenea, dump-urile logice de backup-urile sistemului de fișiere și de arhivarea continuă.

O comandă simplă, orientată spre ownCloud, este:

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

Pentru automatizare, preferați mecanismul de fișiere cu parolă acceptat de PostgreSQL, în loc să îl încorporați PGPASSWORDîn script. Păstrați aceleași principii de mod de întreținere, retenție, înregistrare în jurnal și testare a restaurării.

Câte copii de rezervă ar trebui să păstrezi?

Nu există o perioadă unică de retenție care să se potrivească fiecărui server ownCloud. Adaptați perioada de retenție la cât de repede se schimbă datele, cât spațiu de stocare este disponibil și cât timp în urmă ar putea fi nevoie pentru recuperare. Paisprezece dump-uri zilnice ale bazei de date sunt un exemplu rezonabil pentru un server mic, dar nu sunt o cerință universală.

Autoverificare finală

Copia de rezervă automată a bazei de date este gata numai atunci când toate aceste afirmații sunt adevărate:

• Știi dacă serverul folosește MySQL/MariaDB sau PostgreSQL și ai verificat numele corect al bazei de date și gazda.
• Directorul de rezervă este protejat și are suficient spațiu liber.
• Acreditările nu sunt expuse în comanda crontab.
• O copie de rezervă manuală se finalizează cu succes înainte de activarea programării.
• Scriptul iese întotdeauna din modul de întreținere, inclusiv după o eroare de dump.
• Jobul programat scrie un jurnal și creează o copie de rezervă completă la timp.
• Gropile de gunoi vechi sunt îndepărtate conform unei politici deliberate de retenție.
• O copie de rezervă recentă a fost restaurată cu succes într-o bază de date non-producție.
• Copia de rezervă a bazei de date este asociată cu copii de rezervă ale datelor, configurației și altor directoare necesare din ownCloud.

Dacă oricare dintre aceste verificări eșuează, remediați acel punct înainte de a vă baza pe automatizare. Un sistem de backup este util doar atunci când calea de recuperare a fost testată.