DSM 7.0 Umstieg auf DSM 7 ?

[ViperRt10]

OK, danke für die Info, da brauche aber noch ein paar schupser

was muss denn dort rein:

 

[EDvonSchleck]

du brauchst nur deine Domain/dyndns/Quickconnect Adresse und E-mail angeben

 

[ViperRt10]

also der Quickconnect Name von Synology und meine Email.
das mag er anscheinend nicht:

 

[tproko]

Wie gehst du intern aufs NAS? Per IP oder dyndns/quickconnect?

Quickconnect

Die qc Domain wird nicht gehen. Die gehört synology und nicht dir.

Wenn du das von intern willst benötigst du eine Domain und einen DNS Server auf Router oder NAS. Per ip geht das sowieso nicht weg.
LE benötigt Port 80 oder 443 nach außen offen.
Ohne LE ginge auch, einfach ein Zertifikat für deine Domain anlegen via NAS (=self signed) und das zu deinem Browser Zertifikaten hochladen im Chrome.

zeigt mir Chrom - unsichere Verbindung - und https ist durchgestrichen

wie kann ich das beheben, mit Zertifikaten udgl. hatte ich noch nichts zu tun....

Du kannst es einfach ignorieren. Verbindung in deinem Intranet läuft trotzdem über https, er bemängelt nur, dass dein Zertifikat nicht zusammenpasst mit der Url/ip.

 

[ViperRt10]

hab im DSM7 den SSD Cache Analysator laufen lassen
wir hatten beim Kauf davon schon gesprochen und es wurde mir abgeraten dort zu investieren
hat sich das nun verändert, oder ist das weiterhin überflüssig
was brächte es?

 

[EDvonSchleck]

ich würde es lassen

 

[plang.pl]

ich auch, verändert hat sich da nix

 

[linuxdep]

Hi, warum wollt ihr Docker Images sichern??? Ihr braucht doch nur die Daten, die ja als externes FS in die Container gemountet werden, zu sichern, incl. der config... ich habe dazu ein docker compose file, was auch nur gesichert wird, die Images sind doch schnell vom hub geladen.

Bin auch noch bei 6.xx, nutze aber Moments, auf iPhone und Android... habe mich noch nicht damit beschäftigt, wie das dann ja neu ist, damit werden ja die Bilder von den Telefonen gesichert.

 

[tproko]

@linuxdep ich zB will nicht mein Image sichern, sondern habe eine Postgres am Laufen. Da musst man einen Dump ziehen (bzw. Snapshots machen, was ich aber nicht kann mit ext4) um ein konsistentes Backup zu haben. Einfach die Daten wegsichern (welche nach außen gemounted sind), ist mir da bei einer DB zu kritisch (und ist nicht garantiert, dass das konsistent ist).

Redmine hat einen Teil der Daten in der Postgres, für den Rest reicht das Verzeichnis Mount zum wegsichern.

Kommt immer drauf an, was man sichern will.

 

[EDvonSchleck]

@linuxdep ich zB will nicht mein Image sichern, sondern habe eine Postgres am Laufen. Da musst man einen Dump ziehen (bzw. Snapshots machen, was ich aber nicht kann mit ext4) um ein konsistentes Backup zu haben. Einfach die Daten wegsichern (welche nach außen gemounted sind), ist mir da bei einer DB zu kritisch (und ist nicht garantiert, dass das konsistent ist).

Hast du einen Tip wie man das über eine Aufgabe mit Befehl machen kann?

 

[tproko]

Ja kann ich am Abend gerne raussuchen. Via Aufgabe und docker exec.

 

[EDvonSchleck]

super, werde es denn testen

 

[tproko]

@EDvonSchleck habe in der Aufgabe zB. folgendes Skript hinterlegt: /volumeX/Skripte/backupPostgres.sh

Bin kein Bash-Profi, hab mir halt was zusammengebaut. Hab es mal aufs wesentliche reduziert, bei mir wird vor dem Dump noch die alte Version wegkopiert. Zunächst schaut er, ob der container läuft, dann docker exec + pgdump + gzip

#!/bin/bash

CONTAINER_NAME='postgres1'

CID=$(docker ps -q -f status=running -f name=^/${CONTAINER_NAME}$)
if [ ! "${CID}" ]; then
  echo "Container $CONTAINER_NAME is not running, not creating backup"
  exit 0
fi

cd /volume1/docker/postgres/data/backup/   # hier ist das mount nach außen, dh. /var/lib/.../backup legt den Dump dann auch am NAS Volume ab, wo er dann weiter wegkopiert oder was auch immer notwendig ist, passieren kann.

echo starting backup
docker exec postgres1 bash -c "pg_dumpall -U postgres | gzip > /var/lib/postgresql/data/backup/current-pg_dumpall.dump"

 

[EDvonSchleck]

danke dafür, ich werde es testen und natürlich berichten. Was meinst du mir vorher die alte Version weggesichert?
Wie verhält sich das mit mehreren User/Datenbanken in Postgres? Ist das ein komplettes Backup von allen?

 

[Ulfhednir]

@linuxdep ich zB will nicht mein Image sichern, sondern habe eine Postgres am Laufen.

Mir fehlen derzeit noch die Praxiserfahrungen mit Postgres-Datenbanken, aber im Kern kochen alle nur mit Wasser.
Ich ziehe da mal einen Vergleich mit MSSQL-Server und kann da mal folgendes berichten: Mir ist noch kein Fall vor die Füße gefallen, wo eine Sicherung aus einer .mdb Probleme bereitete, wenn diese vernünftig wegesichert wurde. Ergo: Container stoppen und die pg_database (?) aus dem persistenten Speicher sichern, sollte definitiv funktionieren. Das entspricht auch dem universellen Vorgehen gemäß des Docker-Prinzips. Es wäre auch etwas albern, wenn ich bei einem Container-Update ein Database-Dump erstellen müsste.

Wenn tproko kein Risiko eingehen möchte, kann ich das allerdings auch noch halbwegs nachvollziehen. Das ist im Kern so, wenn ich ein einfaches UPDATE-Statement über eine Datenbank jagen würde und obligatorisch, vorsichtshalber doch eine Datenbanksicherung erstelle.

 

[tproko]

Container stoppen

Unsere PROD Postgres in der Arbeit laufen durch. 24/7 - da fährt man nicht einfach runter und macht mal eben ein Backup. Das passiert im Betrieb.

Warum sollte ich zuhause den Container stoppen für ein Backup. Klar ginge das mit dem Stop und Dateien sichern. Aber das kannst nicht einfach wiederherstellen oder auf QS einspielen. Einen richtigen Dump schon.

Das ist im Kern so, wenn ich ein einfaches UPDATE-Statement über eine Datenbank jagen würde und obligatorisch, vorsichtshalber doch eine Datenbanksicherung erstelle.

Jede vernünftige DB bietet via pgdump, mysqldump etc. ein konsistentes Backup an (indem es eine Transaktion startet und somit die Datenkonsistenz zum Zeitpunkt vom Start garantiert).
Das ist der mMn der einzige richtige Weg, um postgres zu sichern (egal ob nativ, docker oder kubernetes). Sollte man in Produktion sicher regelmäßig machen.
Oder wie du schreibst vor wichtigen Migrationen oder sql Update Statements.

Es wäre auch etwas albern, wenn ich bei einem Container-Update ein Database-Dump erstellen müsste.

Nicht beim Update vom docker image. Ich mache privat ein tägliches Backup, um ggf. Datenlöschung oder sonst was via Backup wiederherstellen zu können. Wahrscheinlich eben auch, weil wir das in der Arbeit auch so handhaben.

@EDvonSchleck ja pgdumpall hat grundsätzlich alles mit drin.

 

[EDvonSchleck]

@EDvonSchleck habe in der Aufgabe zB. folgendes Skript hinterlegt: /volumeX/Skripte/backupPostgres.sh

Bin kein Bash-Profi, hab mir halt was zusammengebaut. Hab es mal aufs wesentliche reduziert, bei mir wird vor dem Dump noch die alte Version wegkopiert. Zunächst schaut er, ob der container läuft, dann docker exec + pgdump + gzip

#!/bin/bash

CONTAINER_NAME='postgres1'

CID=$(docker ps -q -f status=running -f name=^/${CONTAINER_NAME}$)
if [ ! "${CID}" ]; then
  echo "Container $CONTAINER_NAME is not running, not creating backup"
  exit 0
fi

cd /volume1/docker/postgres/data/backup/   # hier ist das mount nach außen, dh. /var/lib/.../backup legt den Dump dann auch am NAS Volume ab, wo er dann weiter wegkopiert oder was auch immer notwendig ist, passieren kann.

echo starting backup
docker exec postgres1 bash -c "pg_dumpall -U postgres | gzip > /var/lib/postgresql/data/backup/current-pg_dumpall.dump"

das Script kann man nicht direkt in eine Aufgabe kopieren?
Man muss es unbedingt als Script speichern und denn als Aufgabe ausführen?

Gibt es da eine Möglichkeit?

 

[Fusion]

Probiere es doch einfach mal aus im Aufgabenplaner?

Ich haue zwar auch alles was mehr als ein Zweizeiler ist in ein Script, aber eher aus Reproduktionsgründen/Backup.

 

[tproko]

das Script kann man nicht direkt in eine Aufgabe kopieren?

Doch. Geht beides.

 

[EDvonSchleck]

Ich hatte es probiert gin nicht aber auch kein log, ich schau mir das noch einmal genau an