Mailserver für das LAN in einer VM auf einer DS+

[thc]

Hallo zusammen,
in https://www.synology-forum.de/threads/nextcloudpi-mit-vmm.132460 habe ich beschrieben, wie ich NextCloud in einer VM an den Start gebracht habe.
Weil das so gut geklappt hat, ist jetzt das Thema Mailserver dran.
Der läuft zur Zeit noch zusammen mit Samba und dem VDR auf einem Debian-11-PC.
Da die DS aber sowieso immer an ist, kann sie zukünftig auch gerne den Mailserver beherbergen.
Ja: Ich habe gelesen, dass Synology ein eigenes Paket dafür anbietet.
Ich habe aber gerne die volle Kontrolle über so einen Server.
Ich teile die einzelnen Schritte in eigene Beiträge auf, weil das Ganze doch etwas länger wird und imho so leichter zu refenrenzieren und bei Bedarf zu ändern ist.
Am Anfang steht immer ein Link zu einer Webseite, wenn ich diese für das Thema selbst nützlich gefunden habe.

Bitte erst antworten, wenn ein Moderator alle Teilbeiträge freigeschaltet hat - dann ist das Ganze erst komplett.

 

[thc]

Thema: VM installieren

Wirklich wichtig finde ich die RAM-Ausstattung, weshalb sich dafür eigentlich nur eine DS mit + am Ende eignet, weil man die aufrüsten kann.
Die Einrichtung ist ansonsten recht trivial.
1 Kern
erstmal 4 GB RAM
20 GB HDD - eigentlich viel zu viel, aber der Platz ist ja reichlich da
VirtIO
Debian-iso zuweisen
VM starten und Basis-Installation durchführen.
Dabei kann ein sparsamer Desktop ausgewählt werden, muss aber nicht.
Ich richte sowieso nahezu alles mit PuTTY und WinSCP ein.
Nach dem abschließenden Reboot qemu-guest-agent nachinstallieren.
Herunterfahren und einen ersten Snapshot machen.

 

[thc]

Thema: Erste Anpassungen

1. ssh-Zugriff für root mit PubKey ermöglichen
Modern ist sudo - ich bin so alt, dass ich mich daran nicht mehr gewöhnen möchte.
Dazu also mit z.B. PuTTY und WinSCP als Benutzer aus der Basis-Installation anmelden und die Konfiguration an eine Stelle umkopieren, wo man sie ändern darf:
cp -av /etc/ssh/sshd_config /tmp
Mit WinSCP anpassen, damit sich root mit PubKey (und erstmal auch mit Kennwort) anmelden darf.
Eine (hoffentlich schon existierende) authorized_keys ebenfalls nach /tmp kopieren.
In der Shell zu root wechseln und die Dateien übernehmen:
sudo -s /bin/bash
cd /root/.ssh
cp -av /tmp/authorized_keys .
chown root:root authorized_keys
chmod 600 authorized_keys
cd /etc/ssh
cp -av sshd_config sshd_config.del
cp -av /tmp/sshd_config .
chown root:root sshd_config
chmod 644 sshd_config
systemctl restart ssh.service
Danach das Anmelden mit PubKey testen.
Wenn das klappt, mit PasswordAuthentication no selbige abschalten.
Wenn nicht, mit Kennwort anmelden und Fehler suchen.

2. Danach ist es Zeit, die ~/.bashrc nach den eigenen Vorlieben anzupassen
Farben, bash-History und geliebte alias-Einstellungen anpassen, z.B.
alias ll='ls -al'
alias p1='ping -c 1'
alias histgrep='history|grep -i $1'
Testen

3. auf anderen Servern bereits vorhandene Skripte importieren und anpassen, wenn vorhanden
Bei mir ist das einiges in /usr/local/sbin, z.B. zum Anlegen von Benutzern für Mail und Samba.
VM herunterfahren und nächsten Snapshot anlegen.

 

[thc]

Thema: Mail-Server einrichten

Ich habe seit vielen Jahren die Kombination aus fetchmail, postfix und courier-imap am Start.
courier-imap legt allerdings seine eigenen Dateien direkt bei den Mails ab.
Da diese in einem NFS-Share auf dem NAS angesiedelt werden sollen, probiere ich es hier statt dessen mal mit Dovecot.
Das soll Probleme mit NFS vermeiden und die ganzen Mail-Dateien sind in einem späteren produktiven Betrieb bestimmt auch besser in /volume2 auf einem SSD-RAID-1 aufgehoben als in der VM.
Während der ganzen Aktion habe ich es als hilfreich empfunden, die Logs nicht an syslog zu übergeben, sondern nach /var/log/mail.log schreiben zu lassen.
Und diese Datei in einem eigenen PuTTY-Fenster mit einem tail -f zu beobachten.

1. NFS
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nfs-mount-on-debian-11
Also auf dem NAS ein Share dafür einrichten - bei mir VM-Mail mit no_squash, damit UID und GID erhalten bleiben.
Darin ein Ordner VM-Mail_home_vmail.sync, der dann mit NFS in der VM als /home/vmail eingebunden wird.
Ausblick: Dieser Ordner soll später mal mit Resilio Sync auf einen anderen Host synchronisiert werden, der seinerseits einen Papierkorb hat und automatisch Snapshots anlegt = Backup und Schutz vor Ransomware.
Das kann man in der /etc/fstab in der VM schon mal vorbereiten, bei mir:
#nas-ds224:/volume1/VM-Mail/VM-Mail_home_vmail.sync /home/vmail nfs rw,defaults,rsize=8192,wsize=8192,nfsvers=3 0 0
Das wird aber erst scharf geschaltet, wenn das Mail-Setup soweit funktioniert.
Zum Testen:
mount -o rw,vers=3 nas-ds224:/volume1/VM-Mail/VM-Mail_home_vmail.sync /home/vmail

2. fetchmail
Ich habe ja bereits eine funktionierende Konfiguration.
Deshalb war das mit einem apt install fetchmail und Kopieren der existierenden /etc/fetchmailrc schnell erledigt.
Vorerst habe ich in der /etc/default/fetchmail START_DAEMON=no eingetragen.
Das wird erst ganz am Ende scharf geschaltet, wenn alles funktioniert und die Mails auch umgezogen sind.
BTW: Die Mails werden mit fetchmail von verschiedenen Relayhost abgeholt und mit postfix über diese versendet.

3. Postfix
https://www.admin-magazin.de/Das-Heft/2012/02/Eigener-Mailserver-mit-Postfix-und-Dovecot
Die Abweichung zum existierenden Server ist die Umstellung auf virtuelle Benutzer.
Damit gehören alle Mails dem User vmail und die wirklichen Benuzer müssen keine Kennung samt Kennwort auf dem Linux-System haben.
Damit man auf beiden Systemen identische uid und gid hat, erst auf dem NAS vmail anlegen und ermitteln:
grep vmail /etc/passwd für die uid, bei mir 1030
grep vmail /etc/groups für die gid, bei mir 65537
Danach mit den ermittelten uid und gid Benutzer und Gruppe vmail in der VM anlegen.
VM herunterfahren und nächsten Snapshot machen.

 

[thc]

Thema: IMAP

https://doc.dovecot.org/configuration_manual/virtual_users/
https://doc.dovecot.org/configuration_manual/howto/simple_virtual_install/
Damit bekommt man dovecot schon mal grundsätzlich an den Start

1. Indizes
https://forum-raspberrypi.de/forum/...k-auslagern-weitere-optimierungen-bezgl-logs/
https://github.com/clathi06/var2tmpfs
Die Indices sind nicht wirklich gut direkt bei den Mails aufgehoben, deshalb habe ich in der /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/home/vmail/%n:INDEX=/var/vmail/%n/indexes
Die Idee dazu ist, /var/vmail irgendwo hin zu packen, wo es flott zu geht - am Besten also ins RAM.
Dazu gibt es für den RaspberryPi das Skript varlog, das genau so etwas veranstaltet, um die MicroSD zu schonen.
Aber zuerst mal mit NFS direkt aufs NAS:
mkdir /var/vmail.save
chown vmail:vmail /var/vmail.save
systemctl stop dovecot.service
cd /var/vmail.save
cp -av /var/vmail/* .
mount -o rw,vers=3 nas-ds224:/volume1/VM-Mail/VM-Mail_var_vmail /var/vmail (das Verzeichnis muss es natürlich geben)
cd /var/vmail
cp -av /var/vmail.save/* .
systemctl start dovecot.service
Damit sind die Indizes schon mal an einer Stelle, wo sie sich beliebig ummounten lassen.
Das Umziehen auf tmpfs erledigt dann das angepasste Skript aus meinem GitHub.
Wenn das funktioniert, können die mounts natürlich auch direkt in die /etc/fstab eingetragen und scharf geschaltet werden.

2. Benutzer
Ich habe dazu eine /etc/dovecot/passwd, in der die Benutzer mit ihren Kennworten eingetragen sind.
Am Anfang wie gelesen brav verschlüsselt mit doveadm pw -u <user> -p <passwd>
Dann habe ich mich aber gefragt, was die verschlüsselte Ablage eigentlich an Sicherheit bringt.
Die fetchmailrc wird schon immer nur durch die Zugriffsrechte gesichert und das scheint bisher ja auch zu genügen.
Wer root-Zugriff auf den Server hat, kommt sowieso an alles dran.
Und wer das LAN belauschen kann auch - dazu im nächsten Punkt mehr.
Im Ergebnis reicht mir persönlich deshalb erstmal ein chown dovecot:root und chmod 600 als Schutz aus.

3. Verschlüsselung
https://dokuwiki.tachtler.net/doku.php?id=tachtler:dovecot_ssl_tls
Nun ist es hier so, dass Thunderbird als Mail-Client genutzt wird.
Und die Mozilla Foundation hält wohl sehr viel von verschlüsselter Kommunikation, aber sehr wenig von eigenen Zertifikaten.
Beim Firefox kann man diese wenigstens noch nach einer Warnung abnicken - wäre sonst wohl auch schlecht beim Zugriff auf die ganzen Fritz!Boxen dieser Welt mit eigenem Zertifikat.
Beim Tunderbird geht das aber nicht - zumindest habe ich nichts dazu gefunden, wie man diese Abfrage wieder einschalten könnte.
Thunderbird verweigert schlicht die Kommunikation mit dovecot bei aktiviertem SSL/TLS/STARTTLS und einem selbst generierten Zertifikat.
Dazu wiederum gibt es jede Menge Treffer bei einer Suche, aber als Lösungen nur: auf Verschlüsselung verzichten oder ein Zertifikat kaufen oder letsencrypt verwenden.
Letzteres stelle ich mir allerdings bei einem Server schwierig vor, dessen FQDN auf .internal endet, weil er eben gar nicht im Internet auftauchen soll.
Also erstmal keine Verschlüsselung und imap auf Port 143 wie bisher...

4. Mails migrieren
https://imapsync.lamiral.info/
https://github.com/imapsync/imapsync/blob/master/README
Das habe ich schon mehrfach mit imapsync gemacht, so auch hier.

 

[thc]

Thema: Nacharbeiten

Der Vorteil eines Systems ohne virtuelle Benutzer ist ja, dass die /etc/passwd ausreicht.
Mit virtuellen Benutzern waren bei mir am Anfang noch mindestens zwei Dateien erforderlich:
Für Postfix die virtual_alias_maps, um die von fetchmail angelieferten internen Benutzernamen (is "user" here) in welche mit @domain.internal umzusetzen.
Ohne mag Postfix nicht - zumindest habe ich keinen Weg gefunden, ohne die Domäne auszukommen oder diese wenigstens mit regex einfach an alle reinen Benutzernamen anzuhängen.
Und die /etc/dovecot/passwd, um diese Benutzer sowohl für Postfix als auch für die IMAP-Clients zu authorisieren.
Ich habe deshalb die Benutzernamen für fetchmail und Thunderbird um die Domäne angereichert - damit fällt die virtual_alias_maps für Postfix weg.

Wenn alles sauber läuft, kann das Logging wieder auf syslog umgestellt und danach die /var/log/mail.log geleert werden:
cat "" > /var/log/mail.log

Die zweite Baustelle ist dann irgendwann mal die verschlüsselte Kommunikation
Dazu werde ich mal versuchen, eine eigene CA aufzusetzen, diese dem Thunderbird als vertrauenswürdig bekannt zu machen und damit dann das Zertifikat zu signieren:
https://medium.com/@martin.hodges/introduction-to-creating-a-ca-on-debian-11-094bde1c676a

Gruß
Claus

 

[thc]

Noch ein Thema: Backup

So ein Server sollte ja auch gesichert werden - am Besten nach der 3-2-1-Regel.
Dabei finde ich die Daten erheblicher wichtiger als die Software - diese lässt sich ja mit überschaubarem Aufwand neu an den Start bringen.

Also zuerst mal die Daten.
Die habe ich bisher täglich nachts mit rsync in Tages-, Monats- und Jahres-Verzeichnisse in /backup kopiert und von dort mit Resilio auf zwei NAS an unterschiedlichen Orten weg synchronisiert.
Hier mache ich mir das Leben einfacher.
Alle Mails liegen ja in einem Share der DS.
rslsync bekommt Schreibrechte an dem Share, um .sync anlegen zu können und das ganze Share wird mit Resilio weg synchronisiert.
Das eigentliche Backup mit Versionierung übernehmen dann die entfernten NAS mit ihren Snapshots.
So spare ich mir eigene Skripte und komme mit den Möglichkeiten der jeweiligen GUI's aus.
Ein eigenes Mini-Skript wird auf der DS dennoch benötigt:
Die Voreinstellung für die sog. Notify Watchers ist mit 8192 viel zu niedrig für Resilio.
Deshalb gibt es bei mir eine Aufgabe beim Systemstart, die mit einem "sysctl fs.inotify.max_user_watches=131072" die Anzahl der Wächter auf 1/4 der maximal möglichen setzt.
Das hat bisher gereicht.

Dann die Software.
Das sollte eigentlich bei einer VM ja ganz einfach sein - eigentlich.
Erste Alternative: Exportieren
Dazu muss man die VM ganz herunter fahren und kann sie dann in ein beliebiges Verzeichnis exportieren.
Dieses Verzeichnis lässt sich dann weg synchronisieren.
Das dauert etwas und danach muss man die VM auch wieder starten.
Das Ganze regelmäßig händisch zu machen finde ich nicht so toll und ein Skript zu basteln, was das automatisch erledigt auch nicht.
Zumal man sich dann auch noch um die Versionierung selbst kümmern muss.
Zweite Alternative: Snapshots
Die lassen sich nach Zeitplan automatisch anlegen und auch wieder löschen - prima.
Allerdings liegen sie in einem Systemverzeichnis und das ist für Resilio tabu - nicht prima.
Dritte Alternative: Active Backup for Business (AB4B)
Das lässt sich wie Snapshots automatisieren - prima
Die Sicherungen liegen in einem Share - auch prima
Also habe ich AB4B auf der DS installiert und den Client für Debian herunter geladen und auf die VM kopiert.
Und dann versucht zu installieren.
Erste Erkenntnis: /var/tmp als tmpfs ist mit seinen 100 MB zu klein dafür
Also habe ich mit /etc/init.d/var2tmpfs.sh stop tmp das tmpfs angehalten und den Install wiederholt.
Zweite Erkenntnis: AB4B mag nicht mit dem Kernel von Debian 12
Zum Glück habe ich ja hier in diesem Thread (u.a. für mich selbst) dokumentiert, wie ich den Server in einer VM aufsetzen kann.
Also habe ich das ganze Setup für Debian 11 wiederholt und damit funktioniert dann auch das Backup samt Sync mit Resilio.
Das läuft dann zwar wöchentlich, wo mir monatlich vollkommen reichen würde - damit kann ich aber gut leben.
Und ob fetchmail, postfix, dovecot und nfs-common jetzt mit Debian 11 oder 12 unterwegs sind, scheint mir wirklich nicht allzu wichtig zu sein.

Gruß
Claus

 

[thc]

Thema: Backup die zweite
https://checkmk.com/de/linux-wissen/loop-device-partitionieren
Eigentlich gehört das Thema ja eher zum Bereich AB4B, aber alles andere ist ja auch schon hier zusammen gefasst.
Und eigentlich wollte ich bei der DS ja ohne eigene Skripte auskommen - eigentlich.
Aber dann habe ich mir mal angesehen, was bei der Sicherung und Synchronisation mit AB4B so passiert.

Auf der DS wird für jede Sicherung ein eigenes Verzeichnis angelegt:
root@nas-ds224:~# ls -al /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/
total 0
drwxr-xr-x 1 ActiveBackup ActiveBackup 336 May 12 01:00 .
drwxr-xr-x 1 ActiveBackup ActiveBackup 232 May 12 01:00 ..
drwxr-xr-x 1 ActiveBackup ActiveBackup 80 May 2 19:40 ActiveBackup_2024-05-02_193917
drwxr-xr-x 1 ActiveBackup ActiveBackup 80 May 5 01:00 ActiveBackup_2024-05-05_010002
drwxr-xr-x 1 ActiveBackup ActiveBackup 80 May 12 01:00 ActiveBackup_2024-05-12_010001

Und in jedem Verzeichnis befinden sich die gleichen Dateien:
root@nas-ds224:~# ls -al /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-02_193917/
total 3374228
drwxr-xr-x 1 ActiveBackup ActiveBackup 80 May 2 19:40 .
drwxr-xr-x 1 ActiveBackup ActiveBackup 336 May 12 01:00 ..
-rw-r--r-- 1 ActiveBackup ActiveBackup 135168 May 2 19:40 backup_db.sqlite
-rw-r--r-- 1 ActiveBackup ActiveBackup 8904 May 2 19:39 device_spec
-rw-r--r-- 1 ActiveBackup ActiveBackup 10737418240 May 2 19:39 sda.img
In den beiden anderen Verzeichnissen sieht es ähnlich aus.
Hmm, bei total steht allerdings was von nur gut 3 Mio Blöcken (zu je 1 KB).

Also wird weniger Platz verbraucht als das ls suggeriert:
root@nas-ds224:~# du -hs /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/*
3.3G /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-02_193917
2.9G /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-05_010002
2.4G /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-12_010001
Da scheint wohl eine Deduplikation am Werk zu sein und im Ergebnis sparsam mit dem Platz umzugehen - prima

Weniger prima sieht es auf dem Synchronisationsziel aus, hier unser Debian-VDR:
vdr-az:~# ls -al /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-02_193917/
total 10485916
drwxrwxr-x 2 rslsync rslsync 4096 13. Mai 15:59 .
drwxrwxr-x 5 rslsync rslsync 4096 13. Mai 15:17 ..
-rw-rw-r-- 1 rslsync rslsync 135168 2. Mai 19:40 backup_db.sqlite
-rw-rw-r-- 1 rslsync rslsync 8904 2. Mai 19:39 device_spec
-rw-rw-r-- 1 rslsync rslsync 10737418240 2. Mai 19:39 sda.img
vdr-az:~# du -hs /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/*
11G /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-02_193917
11G /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-05_010002
11G /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-12_010001
Das sieht dann doch eher so aus, als würden die Dateien dort mit ihrer nominalen Größe gespeichert werden.
Und das wiederum ist ziemlich böse, wenn die DS nicht die 1 beim 3-2-1 ist, sondern ihrerseits ihre Backups zu einer anderen 1 schaffen muss.
Dort wird dann nämlich ziemlich viel Platz für ziemlich wenig Daten verbraucht.

Deshalb habe ich mir als Nächstes mal so ein Image angesehen:
vdr-az:~# cd /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-12_010001
vdr-az:/mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-12_010001# sfdisk -l sda.img
Disk sda.img: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8450ec9d
Device Boot Start End Sectors Size Id Type
sda.img1 * 2048 18970623 18968576 9G 83 Linux
sda.img2 18972670 20969471 1996802 975M 5 Extended
sda.img5 18972672 20969471 1996800 975M 82 Linux swap / Solaris
Das sieht doch verdächtig nach dem Dateisystem der VM aus.
Wenn man das dann nach der Beschreibung im Link ganz oben als Loop-Device mountet, stellt man fest, dass es tatsächlich das Dateisystem der VM ist.
Allerdings ohne die dort per mount eingebundenen Verzeichnisse.
Für die Mails in /home/vmail ist das gut, weil die ja sowieso direkt auf der DS liegen und gar nicht in das Backup sollen.
Für die nach tmpfs ausgelagerten Verzeichnisse unterhalb von /var ist das nicht so gut, weil die ja eigentlich dazu gehören.

Also muss so ein Pre-freeze-Skript her, das dafür sorgt, dass der Inhalt der tmpfs-Verzeichnisse gesichert wird:
Server-vm-mail-Pre-freeze.sh
Das besteht im Wesentlichen aus 2 Zeilen:
#!/bin/bash
/etc/init.d/var2tmpfs.sh save
Das geht in modern bestimmt auch mit sysctl - habe ich aber nicht ausprobiert.

Damit ist das Problem mit dem Speicherplatz aber noch nicht gelöst.
Also habe ich probehalber mal so ein Verzeichnis in ein tgz-Archiv gepackt und festgestellt, dass dadurch die 11 GB zu 670 MB schrumpfen.
Das ist doch schon deutlich angenehmer durch das Internetz zu verteilen.
Die nächsten Schritte waren dann:
Löschen des existierenden Sync und der auf den Zielsystemen damit angelegten Dateien
Ein neues Verzeichnis /volume1/ActiveBackupforBusiness/ActiveBackupData.sync anlegen und für den Sync vorbereiten
Das angehängte Skript entwickeln und so lange testen, bis es bei mir läuft
Das Skript in die Aufgabenplanung nach dem Backup aufnehmen und Resilio scharf schalten
BTW: Das Skript liegt bei mir in ActiveBackupData.sync und wird so gleich automatisch mit gesichert.
Und irgendwo in den KB von Synology steht, dass man bei Skripten absolute Pfadnamen verwenden soll, deshalb enthält es eine selbst für mich ordentliche Menge von runden und geschweiften Klammern.

Gruß
Claus

P.S.: sh-Dateien lassen sich hier nicht anhängen, deshalb die Umbenennung in txt

 

[synfor]

Funktioniert das denn nicht mehr?

https://kb.synology.com/de-de/DSM/t...siness_with_DSM_backup_packages#x_anchor_id10

 

[thc]

Also, da steht:

Sie können integrierte Dienste Ihres Synology NAS nutzen, um für den Fall eines IT-Notfalls Kopien der Daten von Active Backup for Business zu erstellen.

• Wenn Sie mehrere Synology NAS haben, können Sie Snapshot Replication nutzen, um Daten zu replizieren.
• Wenn Sie nur ein NAS besitzen, können Sie Daten mit Hyper Backup in die Cloud oder auf andere Speichermedien sichern.

Ein zweites Synology NAS habe ich nicht, also fällt Snapshot Replication aus.
Bleibt Hyper Backup:

Sichern Sie Ihr Synology-System zu lokalen Volumes, externen Geräten, anderen Synology-Systemen, rsync-Servern oder öffentlichen Clouds wie Google Drive, S3-Speicher und C2 Storage.

lokales Volume = selbes Gerät = nicht woanders
externes Gerät = USB-Platte = nicht woanders
anderes Synology System = habe ich nicht
rsync-Server = das mache ich schon mal im LAN, aber nicht über das Internet
öffentliche Cloud = ich möchte schon gerne die Kontrolle über meine Daten behalten
C2 Storage = Abo-Angebot von Synology (wenn ich das richtig verstanden habe) = nö

Ausserdem steht da nirgendwo dabei, ob nicht z.B. bei einem rsync auch wieder der Bruttoplatz benötigt wird.
Da bleibe ich doch lieber bei meinem Ansatz: tgz-Archive erzeugen und mit Resilio verteilen.

Gruß
Claus