Przejdź do treści

Ustawienia plików cookie

Prosimy wybrać, na które rodzaje plików cookie Państwo zezwalają. Wybór można zmienić w dowolnym momencie w Ustawieniach plików cookie na dole każdej strony. Polityka prywatności

Niezbędne

Zawsze włączone

Potrzebne do logowania, zachowania koszyka i zapamiętania wyborów. Są zawsze włączone.

Jakie pliki cookie?
  • weboke_sessie, weboke_klant, weboke_remember: sesja i pozostanie zalogowanym
  • weboke_basket: koszyk
  • wkBtwIncl: wyświetlanie cen z VAT lub bez VAT
  • wok_cookies: wybór dotyczący plików cookie, 12 miesięcy

Mierzą, która reklama prowadzi do odwiedzin lub zamówienia, abyśmy nie płacili za reklamy, które nic nie dają.

Jakie pliki cookie?
  • Google Ads przez Google Tag Manager (_gcl_au, _gcl_aw), do 90 dni
  • OpenAI Ads, reklamy w ChatGPT
  • wok_aff: przez którego partnera trafili Państwo do nas (program partnerski), 60 dni

4,6

Kraj i język

Każdy kraj ma własną stronę z cenami i stawką VAT tego kraju.

Wyświetl

Prawidłowe uwzględnianie baz danych i woluminów Docker w kopii zapasowej

Działająca baza danych nieustannie zapisuje dane w swoich plikach. Jeśli skopiują Państwo te pliki w trakcie zapisu, kopia zapasowa może być uszkodzona. Dlatego najpierw należy wykonać zrzut (dump): uporządkowaną kopię bazy danych w jednym pliku.

Gdzie znajdują się Państwa dane?

CoGdzie
Pliki compose, Caddyfile, .env oraz katalogi takie jak vw-data/srv/diensten
Woluminy Docker, takie jak uptime-kuma i n8n-data/var/lib/docker/volumes/diensten_<naam>/_data
Zrzuty baz danych/var/backups/db
Ustawienia serwera/etc

Docker dodaje nazwę katalogu przed nazwą woluminu: w /srv/diensten wolumin uptime-kuma otrzymuje więc nazwę diensten_uptime-kuma. Rzeczywiste nazwy można sprawdzić poleceniem sudo docker volume ls.

Skrypt przygotowujący

Prosimy umieścić poniższą treść w /usr/local/sbin/voor-backup.sh (chmod 700). Skrypt jest uruchamiany przez skrypt kopii zapasowej z artykułu Kopie zapasowe z restic w innym miejscu.

#!/bin/sh
set -e
mkdir -p /var/backups/db
chmod 700 /var/backups/db
cd /srv/diensten

# WordPress-database (MariaDB) als dump
docker compose exec -T wp-db sh -c \
  'mariadb-dump --single-transaction -u"$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"' \
  > /var/backups/db/wordpress.sql

Jeśli nie korzystają Państwo z WordPress, tę część można pominąć. Jeśli baza danych działa poza Dockerem, postępuje się tak samo, używając mariadb-dump --single-transaction lub pg_dump.

Aplikacje z bazą danych SQLite

Vaultwarden, Uptime Kuma i n8n domyślnie przechowują dane w pliku SQLite w swoim woluminie lub katalogu. Najprostsze i najbezpieczniejsze rozwiązanie to krótkie zatrzymanie ich na czas wykonywania kopii zapasowej. Robi to skrypt kopii zapasowej z artykułu Kopie zapasowe z restic w innym miejscu za pomocą docker compose stop, a następnie docker compose start. Trwa to zwykle tylko chwilę; w nocy nikt tego nie zauważy. Jeśli nie chcą Państwo żadnej przerwy, prosimy postępować zgodnie z instrukcjami tworzenia kopii zapasowej samej aplikacji, na przykład tymi z wiki Vaultwarden.

Sam katalog bazy danych (tutaj diensten_wp-db) można pominąć: do tego służy zrzut.

Przywracanie aplikacji

  1. Zatrzymać aplikację: sudo docker compose stop vaultwarden.
  2. Odzyskać katalog: sudo restic restore latest --target /tmp/terug --include /srv/diensten/vw-data (ze zmiennymi z artykułu Kopie zapasowe z restic w innym miejscu).
  3. Zastąpić katalog przywróconą wersją i ponownie uruchomić aplikację.
  4. Bazę danych przywraca się, wczytując zrzut, na przykład docker compose exec -T wp-db sh -c 'mariadb -u"$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"' < wordpress.sql.

Chwileczkę…

Konfiguracja domen

Dla każdej domeny można ustawić serwery nazw, powiązanie z hostingiem oraz to, kto zostanie właścicielem.

Wczytywanie domen…