Ir diretamente para o conteúdo

Definições de cookies

Escolha que tipos de cookies permite. Pode alterar a sua escolha a qualquer momento em Definições de cookies, no fundo de cada página. Política de privacidade

Necessários

Sempre ativos

Necessários para iniciar sessão, manter o seu carrinho e memorizar as suas escolhas. Estão sempre ativos.

Que cookies?
  • weboke_sessie, weboke_klant, weboke_remember: a sua sessão e manter a sessão iniciada
  • weboke_basket: o seu carrinho
  • wkBtwIncl: mostrar preços com ou sem IVA
  • wok_cookies: a sua escolha de cookies, 12 meses

Mede que anúncio leva a uma visita ou encomenda, para não pagarmos por anúncios que não dão resultado.

Que cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), até 90 dias
  • OpenAI Ads, anúncios no ChatGPT
  • wok_aff: através de que parceiro chegou até nós (programa de afiliados), 60 dias

4,6

País e idioma

Cada país tem o seu próprio site, com os preços e o IVA desse país.

Ver

Incluir corretamente bases de dados e volumes Docker na cópia de segurança

Uma base de dados em funcionamento está sempre a escrever nos seus ficheiros. Se copiar esses ficheiros a meio dessa escrita, a sua cópia de segurança pode ficar danificada. Por isso, cria-se primeiro um dump: uma cópia limpa da base de dados num único ficheiro.

Onde estão os seus dados?

O quêOnde
Os seus ficheiros compose, Caddyfile, .env e pastas como vw-data/srv/diensten
Volumes Docker, como uptime-kuma e n8n-data/var/lib/docker/volumes/diensten_<naam>/_data
Dumps de bases de dados/var/backups/db
Definições do servidor/etc

O Docker coloca o nome da sua pasta antes do nome do volume: em /srv/diensten, uptime-kuma passa, portanto, a ser diensten_uptime-kuma. Consulte os nomes reais com sudo docker volume ls.

O script de preparação

Coloque isto em /usr/local/sbin/voor-backup.sh (chmod 700). É iniciado pelo script de cópia de segurança de Cópias de segurança com restic para outro local.

#!/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

Se não utiliza WordPress, omita essa parte. Se tiver uma base de dados fora do Docker, o procedimento é igual com mariadb-dump --single-transaction ou pg_dump.

Apps com uma base de dados SQLite

O Vaultwarden, o Uptime Kuma e o n8n guardam, por predefinição, os seus dados num ficheiro SQLite no respetivo volume ou pasta. A forma mais simples e segura é pará-los por momentos durante a cópia de segurança. O script de cópia de segurança de Cópias de segurança com restic para outro local faz isso com docker compose stop e, depois, docker compose start. Normalmente, isto demora apenas um instante; durante a noite, ninguém dá por isso. Se não quiser qualquer interrupção, siga as instruções de cópia de segurança da própria app, como as da wiki do Vaultwarden.

A pasta da própria base de dados (aqui diensten_wp-db) é ignorada: para isso existe o dump.

Restaurar uma app

  1. Pare a app: sudo docker compose stop vaultwarden.
  2. Recupere a pasta: sudo restic restore latest --target /tmp/terug --include /srv/diensten/vw-data (com as variáveis de Cópias de segurança com restic para outro local).
  3. Substitua a pasta pela versão restaurada e volte a iniciar a app.
  4. Uma base de dados é restaurada importando o dump, por exemplo docker compose exec -T wp-db sh -c 'mariadb -u"$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"' < wordpress.sql.

Um momento…

Configurar os seus domínios

Para cada domínio, defina os servidores de nomes, a ligação ao seu alojamento e quem fica como titular.

A carregar os seus domínios…