Cum să faci o copie de rezervă a Nextcloud cu Restic și Cron

Scenariu ilustrativ (ipotetic): Jordan administrează un mic server Nextcloud pe Ubuntu. Fișierele aplicației se află în /var/www/nextcloud, fișierele utilizatorului se află în /srv/nextcloud-data, MariaDB stochează baza de date Nextcloud, iar o gazdă Linux externă este disponibilă prin SSH. Jordan dorește o copie de rezervă nocturnă care poate fi inspectată și restaurată, nu doar o intrare cron care rulează fără erori.

Acest exemplu oferă lui Jordan un flux de lucru Restic și cron repetabil. Căile, conturile de serviciu, numele bazelor de date și programul sunt exemple; înlocuiți-le cu valori din instalarea dvs. Comenzile nu implică faptul că această configurare a fost executată sau testată pe un server real.

Ce trebuie să conțină o copie de rezervă Nextcloud utilizabilă

O copie a folderului în sine poate omite informațiile de care Nextcloud are nevoie pentru a reconecta fișiere, utilizatori, partajări și setări. Manualul de administrare Nextcloud 35 actual listează cinci elemente de păstrat: directorul de configurare, aplicațiile personalizate, dacă există, directorul de date, directorul temei și baza de date. Ghidul de restaurare precizează că baza de date, directorul de date și fișierele de configurare sunt esențiale. Citiți manualul corespunzător pentru versiunea Nextcloud instalată înainte de a adapta exemplul.

Jordan alege să facă o copie de rezervă a întregului director al aplicației, care include configurația, aplicațiile și temele, plus directorul de date separat și o copie a bazei de date. De asemenea, este necesară o copie separată a fiecărei locații de stocare externe dacă Nextcloud stochează conținutul utilizatorului în afara bazei de date /srv/nextcloud-data. Restic poate proteja doar căile pe care procesul de backup le poate citi.

Instrucțiunile oficiale de backup ale Nextcloud descriu modul de întreținere și backup-urile bazei de date. Instrucțiunile de restaurare arată de ce baza de date și arborele de fișiere trebuie să provină dintr-un punct de recuperare compatibil.

1. Pregătiți Restic și acreditările sale

Instalați Restic din sursa pachetului în care aveți încredere și confirmați că este disponibil pentru contul care va rula jobul. Exemplul presupune că jobul rulează ca root, astfel încât poate citi fișierele Nextcloud și dump-ul bazei de date. Folosește un depozit SFTP la distanță, astfel încât o eroare a serverului de aplicații al lui Jordan nu șterge și singura copie de rezervă.

restic version

install -d -m 700 /root/.config/restic
install -d -m 700 /root/.config/nextcloud

Creați o parolă puternică pentru depozitul Restic și salvați-o /root/.config/restic/nextcloud-passwordcu permisiuni de root. Păstrați o copie de recuperare securizată a acelei parole undeva separat de server și depozit. Restic criptează datele depozitului, dar pierderea parolei poate face ca aceste copii de rezervă criptate să fie inutilizabile. Nu introduceți parola direct în script sau în linia cron.

Configurați accesul SSH neinteractiv pentru contul de rezervă de pe gazda la distanță și verificați cheia gazdei sale printr-un canal de încredere. Setați locația depozitului de mai jos într-un director în care contul poate scrie:

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'
restic init

Inițializați un depozit o singură dată. Ghidul de pregătire a depozitului de la Restic documentează backend-urile de stocare acceptate și inițializarea. Tratați fișierul de parole și cheia SSH ca acreditări sensibile și restricționați accesul la acestea.

2. Păstrați baza de date și fișierele la un punct compatibil

Nextcloud recomandă modul de întreținere pentru copii de rezervă, deoarece blochează noile conectări și blochează sesiunile existente pentru a preveni inconsecvențele datelor. Comanda trebuie executată ca utilizator HTTP; într-o configurare tipică a pachetului Ubuntu, acel utilizator este www-data. Fereastra de întreținere a lui Jordan durează pe durata dump-ului bazei de date și a copiei de rezervă Restic, deci utilizatorii nu pot lucra în Nextcloud în acest timp.

Pentru MariaDB, manualul Nextcloud folosește mariadb-dump --single-transaction. Stocați acreditările bazei de date într-un fișier protejat cu valorile implicite ale clientului, de exemplu /root/.config/nextcloud/mariadb.cnf, în loc să încorporați o parolă în comandă:

[client]
user=nextcloud_backup
password=REPLACE_WITH_A_SECRET
host=localhost

Restricționați fișierul cu chmod 600 /root/.config/nextcloud/mariadb.cnf. Creați un cont de bază de date doar cu privilegiile necesare serverului și procedurii de dump. Dacă Nextcloud-ul dvs. utilizează PostgreSQL sau SQLite, înlocuiți metoda de backup documentată; nu rulați comanda MariaDB neschimbată.

3. Creați un script de rezervă protejat

Jordan salvează următoarele fișiere ca /usr/local/sbin/nextcloud-restic-backupși le face executabile. Folosește un blocaj pentru a evita suprapunerea rulărilor, activează modul de întreținere înainte de a crea dump-ul, face o copie de rezervă a dump-ului cu directoarele de aplicații și date și încearcă să dezactiveze modul de întreținere chiar dacă o comandă ulterioară eșuează.

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'

NC_DIR='/var/www/nextcloud'
DATA_DIR='/srv/nextcloud-data'
DB_NAME='nextcloud'
DB_CNF='/root/.config/nextcloud/mariadb.cnf'
DUMP_DIR='/var/backups/nextcloud'
LOCK_FILE='/run/lock/nextcloud-restic-backup.lock'
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
DUMP_FILE="$DUMP_DIR/nextcloud-$STAMP.sql"
maintenance_started=0

mkdir -p "$DUMP_DIR"
exec 9>"$LOCK_FILE"
flock -n 9 || { echo 'A Nextcloud backup is already running.' >&2; exit 1; }

finish() {
  result=$?
  trap - EXIT
  if [[ "$maintenance_started" == 1 ]]; then
    sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --off || result=1
  fi
  rm -f -- "$DUMP_FILE" || result=1
  exit "$result"
}
trap finish EXIT

sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --on
maintenance_started=1
mariadb-dump --defaults-extra-file="$DB_CNF" --single-transaction \
  --default-character-set=utf8mb4 --databases "$DB_NAME" > "$DUMP_FILE"
restic backup --tag nextcloud "$NC_DIR" "$DATA_DIR" "$DUMP_FILE"

După ce ați analizat căile, creați executabilul cu drepturi de proprietate și mod root 700. Scriptul presupune că instalarea utilizează www-data, MariaDB și căile listate; verificați-le config/config.phpmai întâi în raport cu configurația serverului web. De asemenea, presupune că niciun alt administrator nu a activat deja modul de întreținere. Dacă comanda, dump-ul sau încărcarea Restic eșuează, shell-ul se închide cu o eroare, iar capcana încearcă să restabilească serviciul; verificați jurnalele pentru a confirma că s-a întâmplat acest lucru. Dump-ul este stocat cu permisiuni restrictive și eliminat după rulare.

Acest model simplu menține site-ul indisponibil pentru întreaga scanare și încărcare Restic. Pentru un director de date mare, acest lucru poate fi prea lung. Folosiți un dump al bazei de date și un snapshot de stocare coordonate sau un alt design de backup consistent cu aplicația, dacă sistemul de fișiere sau platforma de stocare îl acceptă. Asigurați-vă că baza de date și snapshot-ul de fișier reprezintă un moment compatibil; copierea independentă a unei baze de date active și a unui director de date în schimbare poate produce o copie de rezervă dificil de restaurat.

4. Programați jobul cu cron

După ce o rulare manuală s-a finalizat cu succes, Jordan instalează scriptul și îl programează pentru o perioadă de liniște. Ca root, editați crontab-ul root cu sudo crontab -eși adăugați:

15 2 * * * /usr/local/sbin/nextcloud-restic-backup >> /var/log/nextcloud-restic.log 2>&1

Acest exemplu începe la 2:15 dimineața, în funcție de fusul orar cron al serverului; alegeți o oră la care fereastra de întreținere este acceptabilă. Cron are un mediu mai mic decât un shell interactiv, așa că scriptul setează PATHexplicit și utilizează căi absolute. Creați fișierul jurnal cu permisiuni restrictive și configurați rotația jurnalelor sau trimiteți ieșirea către serviciul normal de înregistrare în jurnal al sistemului. Programarea cron pornește doar jobul: nu confirmă că backup-ul s-a finalizat sau că o restaurare va funcționa.

5. Setați retenția și verificați rezultatul

După o copie de rezervă reușită, Jordan verifică dacă apare o instantanee:

restic snapshots --tag nextcloud
restic check

restic checkverifică structura depozitului. O operațiune periodică restic check --read-datacitește și datele stocate și poate utiliza o cantitate substanțială de timp pe rețea și pe disc, așadar programați-o în funcție de dimensiunea depozitului și de nevoile de recuperare. Ghidul Restic pentru păstrarea instantaneelor ​​explică faptul că uitarea instantaneelor ​​și eliminarea datelor nereferite sunt lucrări separate și că eliminarea blochează depozitul. Începeți cu o simulare și o politică care corespunde cerințelor dvs. de păstrare:

restic forget --tag nextcloud --keep-daily 7 --keep-weekly 5 \
  --keep-monthly 12 --dry-run

Examinați instantaneele pe care le propune să fie eliminate. Când sunteți mulțumit, eliminați --dry-runși adăugați --prune; executați reducerea datelor atunci când nu se vor confrunta cu backup-ul nocturn. Aceste numere de retenție sunt un exemplu, nu o politică universală. Luați în considerare retenția legală, spațiul de stocare disponibil și cât timp în urmă ar putea fi necesar pentru recuperare.

Testul semnificativ este un exercițiu de restaurare. Restaurați o instantanee recentă într-un director temporar pe un sistem separat, nu peste căile Nextcloud live ale lui Jordan:

restic restore latest --tag nextcloud --target /tmp/nextcloud-restore-check

Confirmați că arborele restaurat conține configurația, datele și dump-ul bazei de date așteptate și inspectați fișierele reprezentative. Pentru un exercițiu complet de recuperare, urmați manualul de restaurare Nextcloud într-un mediu izolat și verificați datele de autentificare, accesul la fișiere și partajările așteptate înainte de a vă baza pe procedură. Documentația de restaurare Restic descrie selectarea instantaneelor ​​și a țintelor de restaurare.

Cum să știi când trebuie să se schimbe această abordare

Cron job-ul lui Jordan este potrivit doar dacă fereastra de mentenanță se încadrează în durata de backup și fiecare cale de date necesară este locală și lizibilă. Schimbați designul când apare oricare dintre aceste semne:

• Site-ul rămâne în modul de întreținere mai mult timp decât pot tolera utilizatorii: planificați instantanee coordonate sau o altă metodă consistentă cu aplicația.
• Jurnalele arată căi lipsă, erori de permisiuni, o copie de date eșuată sau o ieșire Restic diferită de zero: remediați-le înainte de a trata instantaneul ca fiind complet.
• Datele se află într-un spațiu de stocare extern sau pe un alt server: includeți o copie de rezervă consistentă a spațiului de stocare respectiv în planul de recuperare.
• O restaurare de test nu conține fișiere, configurație, stare a bazei de date sau codul necesar pentru aplicație/temă: actualizați datele de rezervă și repetați procesul.
• Parola Restic sau acreditările SSH există doar pe serverul căruia i se face backup: stocați separat acreditările de recuperare și verificați dacă un administrator autorizat le poate accesa.

Pentru Jordan, succesul este observabil: jurnalul cron arată o rulare finalizată, restic snapshotslistează un snapshot recent etichetat, verificările depozitului nu raportează erori, iar un exercițiu de restaurare recuperează o instanță Nextcloud coerentă. O comandă programată este începutul unei rutine de backup; doar un set complet, restaurabil, de date despre baze de date, configurație, aplicație și utilizator oferă o cale practică de recuperare.

Referințe oficiale

• Manual de administrare Nextcloud 35: Copiere de rezervă
• Manual de administrare Nextcloud 35: Restaurarea unei copii de rezervă
• Documentația Restic 0.19.1