How to Set Up Automated Database Backups for ownCloud Server

You discover the weakness in a backup plan at the worst possible time: an upgrade fails, a database table is damaged, or a server disappears, and the only “backup” is a copy of the user files. That is not enough for ownCloud Server. The database holds critical application state such as users, shares, file metadata, and configuration data. A reliable recovery plan needs the database as well as the files and configuration that belong to the same point in time.

This guide shows a practical way to automate ownCloud database backups on Linux, starting with a manual dump and ending with a scheduled, verified job. The examples focus on MySQL/MariaDB because ownCloud recommends those engines, and a PostgreSQL variant is included. The commands are aligned with the current ownCloud Server 11.0 administration documentation, while also noting the command difference for traditional non-Docker installations.

First, understand what a database backup does not cover

A database dump is only one part of an ownCloud backup. The ownCloud Server 11.0 backup documentation lists the database together with the configuration directory, data directory, app directories when applicable, and custom theme files. The data directory can also contain encryption keys, so a database-only backup cannot reconstruct a complete server after total storage loss.

Use the automation below for database protection, but pair it with a file-level backup or snapshot strategy for the rest of the ownCloud installation. When you need a fully consistent recovery point, coordinate the database dump and the file backup in the same maintenance window.

Step 1: Confirm which database ownCloud uses

Before writing a backup command, identify the database type, host, database name, and user. On a classic ownCloud installation, these values are normally available in config/config.php. You can also inspect system configuration with the ownCloud command-line tool. For example, from the ownCloud directory:

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

On a Docker Compose deployment, the current documentation uses commands such as:

docker compose exec owncloud occ config:list system

Look for values such as dbtype, dbhost, dbname, and dbuser. ownCloud Server 11.0 officially supports MySQL/MariaDB and PostgreSQL, with MySQL or MariaDB recommended for normal deployments.

Step 2: Create a protected backup location

Create a dedicated directory that is not web-accessible. Root ownership is a sensible default when the scheduled task runs from root's crontab:

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

Check free space with df -h /var/backups/owncloud-db. A backup job that silently fills the system disk can create a second outage while trying to protect against the first one.

Krok 3: Nie podawaj danych uwierzytelniających bazy danych w poleceniu cron

Nie umieszczaj hasła do bazy danych bezpośrednio w wierszu crontab. W przypadku MySQL lub MariaDB plik opcji klienta, który można odczytać z poziomu roota, jest prosty i dobrze sprawdza się w przypadku zadań nienadzorowanych. Utwórz /etc/owncloud/db-backup.cnf:

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

Następnie ogranicz to:

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

Użyj rzeczywistych wartości z konfiguracji ownCloud. Jeśli baza danych jest zdalna, ustaw odpowiedni host. Podręcznik MySQL dokumentuje pliki opcji dla programów klienckich, a takie podejście pozwala uniknąć bezpośredniego ujawniania hasła w zaplanowanym poleceniu.

Krok 4: Uruchom jedną ręczną kopię zapasową w trybie konserwacji

Oficjalna procedura tworzenia kopii zapasowych ownCloud zaleca zablokowanie normalnego dostępu i przełączenie instancji w tryb konserwacji przed utworzeniem kopii zapasowej bazy danych. W przypadku wdrożenia Docker Compose:

docker compose exec owncloud occ maintenance:mode --on

W przypadku tradycyjnej instalacji z katalogu ownCloud:

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

Tryb konserwacji blokuje normalną aktywność użytkownika podczas tworzenia punktu odzyskiwania. Oznacza to, że zadanie automatyczne powinno zostać uruchomione w okresie niskiego ruchu i zawsze musi wyłączać tryb konserwacji, nawet jeśli zrzut się nie powiedzie.

W przypadku MySQL lub MariaDB przetestuj zrzut ręczny:

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

Dokumentacja ownCloud korzysta z funkcji . Własna dokumentacjamysqldump --single-transaction MySQL mysqldump wyjaśnia, że ​​tworzy ona spójną migawkę dla tabel transakcyjnych, takich jak InnoDB, bez blokowania tabel na czas zrzutu. Opcja ta przesyła strumieniowo wiersze zamiast buforować dużą tabelę w pamięci.--single-transaction--quick

Po zakończeniu ręcznego tworzenia kopii zapasowej wyłącz tryb konserwacji za pomocą odpowiedniego polecenia:

docker compose exec owncloud occ maintenance:mode --off

Lub:

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

Krok 5: Umieść logikę kopii zapasowej w skrypcie odpornym na awarie

Skrypt powinien zatrzymać się po wystąpieniu błędu, zarejestrować znacznik czasu, włączyć tryb konserwacji, utworzyć zrzut, zweryfikować skompresowany plik, zastosować retencję i zagwarantować wyłączenie trybu konserwacji przy wyjściu. Poniższy przykład zakłada klasyczną instalację w systemie /var/www/owncloudi bazę danych MySQL/MariaDB o nazwie 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

Zapisz go jako /usr/local/sbin/owncloud-db-backup.sh, nadaj mu uprawnienia wykonywalne za pomocą chmod 700, a następnie uruchom ręcznie. Jeśli Twój ownCloud jest konteneryzowany, zastąp te dwa occwiersze poleceniami trybu konserwacji Docker Compose, które odpowiadają Twojemu wdrożeniu.

Krok 6: Zaplanuj za pomocą cron

Po pomyślnym uruchomieniu ręcznym zaplanuj uruchomienie skryptu. Otwórz crontab roota:

sudo crontab -e

Codzienny bieg o 2:15 rano:

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

Wybierz czas odpowiadający Twojemu rzeczywistemu schematowi użytkowania. Jeśli baza danych jest duża, najpierw zmierz, ile czasu zajmuje ręczne uruchomienie, ponieważ tryb konserwacji powoduje widoczne przerwanie działania usługi. Upewnij się również, że cron działa w przewidywalnym środowisku: użyj ścieżek bezwzględnych w skrypcie, jeśli wymagane polecenia nie znajdują się w domyślnym środowisku crona PATH.

Krok 7: Zweryfikuj każdą kopię zapasową zamiast ufać znacznikowi czasu

Plik z dzisiejszą datą nie stanowi dowodu na odzyskiwalność kopii zapasowej. Przynajmniej sprawdź, czy plik nie jest pusty, czy program gzip nie zgłasza żadnych uszkodzeń i czy w dzienniku zadań nie ma błędów zrzutu:

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

Aby przeprowadzić bardziej rygorystyczny test, przywróć ostatni zrzut do jednorazowej bazy danych w systemie nieprodukcyjnym. Nie testuj przywracania poprzez nadpisanie aktywnej bazy danych. Prawdziwy test przywracania sprawdza więcej niż tylko integralność plików: potwierdza uprawnienia, uprawnienia do bazy danych, zgodność zrzutu oraz procedurę odzyskiwania, której faktycznie użyłby Twój zespół.

Krok 8: Sprawdź, czy ownCloud powrócił do normalnego działania

Po zakończeniu działania skryptu tryb konserwacji powinien zostać wyłączony, a użytkownicy powinni móc się normalnie zalogować. Sprawdź interfejs sieciowy i przejrzyj dziennik kopii zapasowych. Solidna automatyzacja to nie tylko taka, która tworzy zrzut danych, ale także taka, która w przypadku awarii nie pozostawia usługi w trybie konserwacji.

Co się zmieni, jeśli zaczniesz używać PostgreSQL?

Dokumentacja kopii zapasowych ownCloud korzysta pg_dumpz formatu archiwum dla PostgreSQL. Oficjalna dokumentacja PostgreSQL pg_dump stwierdza, że pg_dump​​tworzy to spójny eksport nawet podczas korzystania z bazy danych. Obszerniejszy rozdział poświęcony kopiom zapasowym i przywracaniu danych w PostgreSQL rozróżnia również zrzuty logiczne od kopii zapasowych systemu plików i archiwizacji ciągłej.

Proste polecenie zorientowane na ownCloud wygląda następująco:

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

W celu automatyzacji, zamiast osadzać PGPASSWORDw skrypcie, preferuj obsługiwany przez PostgreSQL mechanizm pliku haseł. Zachowaj te same zasady trybu konserwacji, przechowywania, rejestrowania i testowania przywracania.

Ile kopii zapasowych należy przechowywać?

Nie ma jednego okresu retencji, który pasowałby do każdego serwera ownCloud. Dostosuj retencję do szybkości zmian danych, dostępnej ilości pamięci masowej i tego, jak daleko wstecz możesz potrzebować odzyskać dane. Czternaście zrzutów bazy danych dziennie to rozsądny przykład dla małego serwera, ale nie jest to wymóg uniwersalny.

Ostateczna samokontrola

Automatyczna kopia zapasowa bazy danych będzie gotowa dopiero wtedy, gdy spełnione zostaną wszystkie poniższe warunki:

• Wiesz, czy serwer używa MySQL/MariaDB lub PostgreSQL i sprawdziłeś poprawność nazwy bazy danych i hosta.
• Katalog kopii zapasowej jest chroniony i ma wystarczającą ilość wolnego miejsca.
• Poświadczenia nie są ujawniane w poleceniu crontab.
• Ręczne tworzenie kopii zapasowej kończy się pomyślnie przed włączeniem harmonogramu.
• Skrypt zawsze wychodzi z trybu konserwacji, także w przypadku nieudanego zrzutu.
• Zaplanowane zadanie zapisuje dziennik i tworzy niepustą kopię zapasową w odpowiednim czasie.
• Stare składowiska są usuwane zgodnie z przemyślaną polityką retencji.
• Ostatnia kopia zapasowa została pomyślnie przywrócona do bazy danych nieprodukcyjnej.
• Kopia zapasowa bazy danych jest powiązana z kopiami zapasowymi danych ownCloud, konfiguracji i innych wymaganych katalogów.

Jeśli którakolwiek z tych kontroli zakończy się niepowodzeniem, napraw ten punkt, zanim zaczniesz polegać na automatyzacji. System kopii zapasowych jest przydatny tylko po przetestowaniu ścieżki odzyskiwania.