ZFS Backups, rsync, Pci passthrough, HyperV oder Proxmox, welche Hardware in einer Cloud?


#1

Hallo, ich vermisse hier Beiträge, in der es um Hetrogene Netzwerke mit Seafile oder um Sicherungen geht.
Gerade was ZFS angeht in einer Virtualisierung, konnte ich nur sehr wenig lesen.

Leider bietet die Doku nur rsync an, was ja passt, aber es mittlerweile bessere Optionen gibt.

Darf ich mal in die runde Fragen, wie dass von euch gemacht wird? Snapshots “vm oder zfs snapshost auf einem Hypervisor” ? oder einem ZFS Laufwerk?

vielen dank

liebe grüsse


#2

Die Pro Leute die VMs nutzen nutzen oft NFS und Redundante Mirror-Setups. mittlerweile aber auch sehr oft Storage-backends wie S3 & Ceph. Ich habs auf meinem gemieteten Dedicated laufen, natürlich ZFS, Hardwareanforderungen hat Seafile nicht, 1 Kern & 1GB RAM, das wars.


#3

Du darfst dir CE Anleitung gerne erweitern.


#4

Ich persönlich benutze Seafile in einem LXC Container unter Proxmox. Storagebackend ist ein ZFS-Mirror aus 2x4TB HDDs.
Nachts läuft die Sicherung über pve-zsync auf meinen Proxmox-Server daheim, welches im Hintergrund ZFS-Snapshots benutzt.
Das schöne an dieser Lösung ist, es wird nur das Delta zum letzten Snapshot übertragen und der gesamte Container wird gesichert. Somit könnte ich im Ernstfall die gesamte Infrastruktur “1-zu-1” wieder hochladen. Eine History über 30 Snapshots ist ebenfalls vorhanden.


#5

Hallo SirUffsALot4h,
ich habe leider keine Funktion im Forum gefunden, um Dir eine persönliche Nachricht zu schicken.
Ich bin recht neu mit Seafiles unterwegs und suche aktuell nach einer guten skalierbaren Infrastruktur. Die von Dir beschriebene erscheint mir sehr interessant.
Ich habe ein paar Fragen dazu.

Wenn ich das richtig verstehe, ist der Proxmos quasi ein Virtualisierungshost für deine VM, die den Seafile-Server hostet. Der ZFS-Storage ist der Datencontainer, da dieser besonders robust und skalierbar ist.
Es macht natürlich Sinn, diese in größeren Clouds hardware-technisch zu trennen, damit sie entsprechend wachsen können. Aber machst Du das auch in Deiner Lösung? Ich plane derzeit ein Dedicated mit 4x10TB. Die könnte ich mir als ZFS gut vorstellen. Aber wo ist da der Host? Dort mit drauf? Wäre das als Starterlösung möglich?
Als Backup würde ich gern ein S3 buchen, der die Snapshots weg speichern soll. Ist das logisch richtig?

Vielen Dank
Jörg


#6

Hallo,

ich arbeite schon seit ca. 4 Jahren mit Proxmox. Am Wochenende hatte ich mal einen Proxmox “2 Platten mirror” mit ZFS eingerichtet.
Keine VM, der Seafile wurde direkt auf Proxmox eingerichtet.

Dazu legte ich später für die Daten und die Datenbank ein eigenes Dataset an. Beim Dataset für die Datenbank setzte ich “zfs set compression=off”.

rpool/seafile
rpool/database

Mit /usr/sbin/zfSnap -s -S -z -a 5d -R “5 Tage” aufheben, füre ich die Snapshost durch.
Mit zfs send/recv mache ich über das Netzwerk die Sicherungen “inkrementell”.

OK, dass klappte sehr gut.
#--------------------------------------------------------------------------------------------------

Beim zweiten Versuch Installierte ich auf dem Proxmox eine VM “Seafile”, danach fügte ich dem Seafile Server ein Dataset hinzu “ZFS Laufwerk”.
Dieses hatte ich in der VM als zweite Partition hinzugefügt. “Datenbank und Daten”.

Nun kann ich unter Proxmox einmal in der Woche den kompletten Server sichern, und die zweite Partition jeden Tag mit ZFS Snapshost sichern.
Da ich der VM ein Externes USB Laufwerk oder was auch immer zuweisen kann, spiele ich dort die Sicherungen drauf.

#-------------------------------------------------------------------------------------------------

Beim dritten Versuch legte ich eine komplette VM für den Seafile Server an, auf einem Dataset mit ZFS. “kein ZVOL”.
Der Server wird täglich auf einen zweiten Proxmoxserver “Inkrementell” gesichert “KEIN CLUSTER”. Fällt der eine Server aus, so kann ich direkt den zweiten Server hochfahren.
Dass schöne ist dabei, ich komme mit zfs clone sofort auf die VM und kann diese Notfalls auch kopieren und auf einem dritten Proxmox einspielen.


Viele Wege führen nach Rom, da ich nur kleinere Netzwerke habe, muss ich hier die goldende Mitte finden, aber mit den Ansätzen kann ich sehr gut leben.
Da ich nur Kunden habe, bis maximal 15 Useren, komme ich da mit einer gewöhnlichen Workstation mit einem Raid1 “ZFS” sehr gut hin. Eine USB für das Proxmox und zwei für die Daten.

Muss natürlich alles ersteinmal zwei Wochen durchlaufen lassen und alles automatisieren.

Achja, hier mal ein Script, wie ich den Seafile Server sichere

#----------------------------------------------------------------------------------------------------
#!/bin/bash

BACKUPDIR="/root/seafile/seafilebackup"
datetime=date +%Y-%m-%d_%H-%M-%S
datetimedirectory=date +%Y-%m-%d_%H-%M-%S
SEAFILEHOME="/home/seafile"
MAILADRESSE=“mailadress”
HOST=$(hostname --fqdn)
APACHEDIR="/etc/apache2"

BACKUPTIME="/root/seafile/seafilebackup/zeit_sicherung"

Sicherungsverzeichnis erstellen wenn nicht vorhanden

if [ ! -d $BACKUPDIR/$datetimedirectory ]
then
mkdir $BACKUPDIR/$datetimedirectory
fi

/usr/local/sbin/seafile-stop.sh

sudo -u seafile /home/seafile/haiwen/seafile-server/seaf-gc.sh

Kopieren des Ordner seafile

cp -al $SEAFILEHOME $BACKUPDIR/$datetimedirectory

#Kopieren des Ornder apache2

#Webservereinstellungen
cp -al $APACHEDIR $BACKUPDIR/$datetimedirectory

wechseln in /root/seafilebackup/erstellten Ordner Datum - Uhrzeit

cd $BACKUPDIR/$datetimedirectory

date +’%c|Backup started’ >> $BACKUPTIME/backup.log

#echo Sicherung beginnt um $datetime > $BACKUPTIME/$datetime-sicherung1.txt

Sicherung der Datenanken

mysqldump --defaults-extra-file=/etc/mysqldump.cnf ccnet-db > ccnet-db.sql
mysqldump --defaults-extra-file=/etc/mysqldump.cnf seafile-db > seafile-db.sql
mysqldump --defaults-extra-file=/etc/mysqldump.cnf seahub-db > seahub-db.sql

Seafile wieder starten

sleep 10
/usr/local/sbin/seafile-start.sh

wechsel in /root/seafilebackup

cd $BACKUPDIR

Packen des Verzeichnisses

tar cvfz $datetimedirectory.tar.gz $datetimedirectory

Löschen der Sicherung ohne tar.gz

rm -r $BACKUPDIR/$datetimedirectory

sleep 5

#echo Sicherung endet um $datetime > $BACKUPTIME/$datetime-sicherung2.txt

date +"%c|Backup completed: $?" >> $BACKUPTIME/backup.log

Abfrage ob TAR ausgeführt wurde.

if (( $? == 0 ))
then
#echo “$datetime Sicherung von /var/www erfolgreich durchgefuehrt” >> $BACKUPDIR/log.txt | mails -s
echo "$datetime Sicherung von $HOST war erfolgreich " | mail -s “$HOST war erfolgreich” mailadresse
else
#echo “$datetime Sicherung von /var/www FEHLGESCHLAGEN” >> $BACKUPDIR/log.txt
echo "$datetime Sicherung von $HOST FEHLGESCHLAGEN " | mail -s “$HOST FEHLGESCHLAGEN” mailadresse

fi

Löschen aller Sicherungen die älter als 2 tage sind

find $BACKUPDIR -mtime +2 -exec rm {} ;

#-----------------------------------------------------------------------

So sieht dann das LOG aus

Sa 01 Dez 2018 23:00:06 CET|Backup started
Sa 01 Dez 2018 23:04:25 CET|Backup completed: 0
So 02 Dez 2018 23:00:06 CET|Backup started
So 02 Dez 2018 23:04:25 CET|Backup completed: 0
Mo 03 Dez 2018 23:00:06 CET|Backup started
Mo 03 Dez 2018 23:04:12 CET|Backup completed: 0

Danke für Eure Infos.

Lieben gruss.


#7

Genau, Proxmox ist meine Virtualisierungslösung, wobei ich hier größtenteils auf LXC-Container setze (Geringerer Overhead etc.)

Auf ZFS liegt sowohl das Container-RootFS, als auch eine zweite Datenplatte. Ich würde hier gerne ein Bild anhängen, aber leider lässt das Forum mich nicht :frowning:

Meine Lösung besteht derzeit aus einem Dedicated Server mit folgender Ausstattung:

Supermicro X9SCL
Intel Xeon E3-1270 v2
32 GB ECC DDR3 RAM
2* 4TB WD RED ZFS Mirror
2* 256GB SanDisk SD8SB8U2 ZFS Mirror
1 GBit Anbindung
Proxmox 5

Also wirklich nichts besonderes. für 4x10TB bietet sich ein ZFS “RAID10” (2x Mirror VDEV) an, das fuhr ich zuhause auch und habe mittlerweile auf 6x10TB (3x Mirror VDEV) hochgerüstet.

Ob man die Snapshots in S3 speichern kann weiß ich nicht. Grade mit dem Delta stelle ich mir das schwierig vor, aber eventuell kann da ein anderer mehr zu sagen.


#8

Da ich mir noch nicht ganz sicher bin, ob das richtig rüber gekommen ist: ZFS ist quasi ein Dateisystem.

Dem Punkt, dass es recht robust ist würde ich zustimmen. Mein Server mit 4*3 TB RaidZ2 (Raid 6) läuft seit vier Jahren problemlos. Das schöne bei ZFS ist, dass dieses Prüfsummen für alle Daten erstellt und anhand dieser Daten auf Fehler prüfen kann (mit dem Befehl zpool scrub werden alle Daten geprüft und eventuelle Fehler soweit möglich behoben).

Ich habe ein RaidZ2 gewählt, da hier 2 beliebige Platten ausfallen dürfen. Ein Raid 10 wäre von der Performance her wahrscheinlich besser, dort darf aber je Mirror nur eine Platte ausfallen. In Summe sind das auch 2 aber eben nicht 2 beliebige.

Ob ein ZFS Mirror nach S3 funktioniert, kann ich gerade auch nicht sagen. Nach einem kurzen Blick würde ich sagen, dass dazu ein “Cold-HDD-Volume” am besten geeignet wäre. Dazu eine kleine EC2 Instanz um die Daten auf dem Cold-HDD-Volume abzulegen. Ein Cold-HDD-Volume kann bis zu 16 TiB haben, daher wäre es am einfachsten 2*10 TiB zu buchen und ein Mirror mit ZFS zu konfigurieren (auf der EC2 Instanz). Wie gut das funktioniert wäre zu Testen, die Zuverlässigkeit der Cold-Hdd-Volumes scheint jedenfalls ganz ordentlich zu sein (Amazon gibt diese mit 1000 Mal so zuverlässig wie eine handelsübliche Festplatte an).


#9

Allerdings wäre es günstiger stattdessen einen zweiten Server mit 2 oder 4*10 TB zu buchen.

In Frankfurt z.B. kosten Cold-HDD-Volumes 0,03 USD pro GB und damit kosten 20TB 600€ im Monat. Bei Hetzner kostet ein Server mit 4*10TB 76.16 €.


#10

Storage-Server gibt’s bei netcup sehr günstig.


#11

Dafür hast du bei einem Raid 10 den Vorteil dass du es beliebig erweitern kannst und keine langen Rebuildzeiten hast. VDEV Erweiterung ist zwar geplant, aber bei ZFS on Linux noch nicht in stable angelangt.
Ansonste sei einem auch dieser Link ans Herz gelegt: http://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/


#12

Ich weiß schon ziemlich genau was ich da getan habe. Das setup läuft seit 4 Jahren und ich bin heute - wie damals - zufrieden. Für meine Anforderungen bin ich weiterhin der Meinung, dass das eine gute Lösung ist. Rebuild hatte ich bereits. Dauert ca. 1 Tag (ungefähr so lange wie ein scrub, den ich jeden Monat mache). Ich hab in der Zeit sogar schon mindestens eine verrücke Sache gemacht (Platten nacheinander aus dem vdev entfernt, 3 mal überschrieben, LUKS aufgesetzt und das LUKS device wieder zum vdev hinzugefügt - sprich alle Daten verschlüsselt).

Backups gibt’s auch, aber die Wiederherstellung wäre schon aufwändig. Für mich stand und steht im Vordergrund, dass es einfach läuft. Die Anforderungen an die Leistung sind in meinem Anwendungsfall gering.


#13

Naja, mit Hetzner können sie meiner Meinung nach nicht mithalten …


#14

Ich habe den Eindruck du möchtest die Community Anleitung erweitern :wink:


#15

Hetzner ist günstiger, man muss halt wissen was man tut wenn man Hetzner wählt.


#16

guten Abend,

ich verstehe gerade die Antworten nicht, ob Hetzner und Co.

“In Frankfurt z.B. kosten Cold-HDD-Volumes 0,03 USD pro GB und damit kosten 20TB 600€ im Monat. Bei Hetzner kostet ein Server mit 4*10TB 76.16 €.”

Eigentlich ging meine Frage in eine andere Richtung.

Schade finde ich es, dass keine konstruktive Meinung zu diesem Thema kommt…

ZFS und mehr!

Nicht einmal eine ansatzweise weisse Lösung mit DYNNS und VDSL und ZFS beantwortet wird.

lieben gruss


#17

Das war eine Antwort auf die Frage von Jörg.

Es wurde auch nirgendwo etwas zu dyndns gefragt.

Zu ZFS hat jemand geschrieben wie er es macht.


#18

Hallo,

Ich betreibe Seafile CE unter Docker in einer Ubuntu Server VM auf meinem MacPro.

Angebunden sind per Thunderbolt2 zwei SSD als ZFS Mirrorpool auf dem der Docker Host als VM unter VMWare Fusion läuft.

Der Data-Pool ebenso per TB2 angebunden besteht aus einem Stripped-Mirror-Pool 3x2x4TB HHDs.

Der Backup-Pool besteht aus zwei 8TB USB3 Platten im Stripset.

Der MacPro hat 128GB RAM, so dass die ZFS 54GB ARC spendiere.

Die Pools haben noch ZIL und L2ARC auf der internen Flash.

Auf dem Docker Host laufen verschiedene Services u.a. eben Seafile hinter Traefik als Proxy. In Kombination mit Let-Encrypt wg. SSL Certs.
Der DD-Client repliziert meine IP zyklisch an meinen DynDNS Provider. So dass ausgewählte Dienste / Container von außen erreichbar sind.
Zum Schutz befindet sich hinter dem Router ein HW Firewall.
Der Docker Host befindet sich in einem anderen Netzwerk so dass über die Firewall geroutet wird.

Der Docker Host läuft als VM auf dem SSD ZFS Pool. Auf dem MacPro läuft ein Seafile Client und der synced alle Libs auf den Data-Pool.
Über ein Host internes Netz als Memory-Performance.

Jede Nacht wird automatisiert die VM und Docker runtergefahren und ein ZFS Snapshot erstellt. Dann wieder direkt hochgefahren. Die Service Downtime ist mit unter 2min vertretbar.
Dann wird per ZFS send/receive der Snapshot des SSD Pools, also der VM auf den Data-Pool gesynced. Und danach der Data-Pool auf den Backup-Pool.

Auf dem Backup-Pool bleiben die Snapshots liegen und nach einer Woche wird der neuste im REDIS als Wochen Snapshot markiert. Das geht vier Wochen, dann wird der neuste als Monats Snapshot markiert. Und das geht 12 Monate und der neuste wird als Jahres Snapshot markiert.

Ursprünglich wollte ich Docker direkt auf macOS betreiben, doch das funktioniert mehr schlecht als recht. Und rate davon ganz klar ab.


#19

Hallo, sorry für die späte Antwort.

laut den ganzen Antworten " herzlichen dank an alle", gibt es keine klare Antwort, das jeder seine eigene Infrastruktur hat.

Ist ja auch Verständlich.

Danke nochmal an alle hier im Forum.

lieben gruss