Server reparieren - oder NAS ?

Oktavus

Enthusiast
Thread Starter
Mitglied seit
16.11.2010
Beiträge
362
Hi,

obwohl ich mit Linux sonst wenig am Hut habe, betreibe ich seit vielen Jahren einen Linux-Server und setze ihn alle paar Jahre neu auf - erst unter Debian 3, dann unter Centos, dann wieder Debian 9. Er lässt sich nicht mehr updaten (broken irgendwas), gehört also neu aufgesetzt. Und jetzt ist mir eine HDD dabei über den Jordan zu gehen *) - der ideale Zeitpunkt um die Frage zu stellen: Server 'runderneuern' oder NAS?

Hardware derzeit:
  • Büro: (teure WD-Server-) 2 TB HDD für SoHo + (billige) 2 TB HDD für die Spiegelung
  • Media: 6 TB HDD für Video, Audio, Fotos + 6 TB HDD für die Spiegelung (erstere ist am abnippeln; der Platz wird bald knapp)
  • eine alte AV-taugliche 500 GB HDD für administrative Dinge
Was soll drauf laufen(?):
  • Samba-Shares (>SMB1) für Bürodaten,
  • Samba-Shares (>SMB1) für die Linux-SAT-Receiver (zum Aufnehmen/Wiedergeben + Video-Audiosammlung)
  • DLNA-Server fürn TV
  • ZoneMinder für die Überwachungskameras
  • Connection zur USV (d.h. wenn Strom weg, soll kontrolliert herunter gefahren werden)
*) Leseprobleme beim Samba-Stream zum Mediaplayer haben mich stutzig gemacht - dann Smart-Check gesehen, der fehl schlug. In Webmin steht beim Smart-Check zur 1. Media-HDD, dass ich umgehend die Daten sichern soll, ein Ausfall in den nächsten 24 Stunden ist wahrscheinlich (wenn auf die gespiegelte Platte keinen Käse geschrieben wurde, sollte noch alles im grünen Bereich sein). Habe beide Media-Platten mal unmouted (eigentlich hätt' ich automatisch eine Email kriegen sollen, wenn ein smart-Test fehl schlägt - hat wohl nicht geklappt).

Soll ich mir jetzt Gedanken über ein NAS machen? Könnte ich mir da auch ZoneMinder drauf installieren? Welche NAS sollte ich mir anschauen? Oder doch einfach 2 HDDs für 'Media' kaufen und den vorhandenen Server (nach Neuinstallation) weiter betreiben (da würd' ich mich so halbwegs auskennen)?

Thx für Input
Oktavus
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hallo mal wieder,

also Debian musst du nicht neu aufsetzen. Was genau ist das Problem?
Zu der HDD: Poste mal bitte die Ausgabe von
Code:
~ # smartctl --all /dev/<Deine disk>

gruß
hostile
 
Zum Update: es ist mir vor 2 Jahren schon nicht gelungen, den Server upzudaten. In einem Thread bin ich dann wegen Nutzung von Webmin gerügt worden, die Diskussion verlief dann im Sand. Derzeit würde er 1439 Packages updaten wollen - schafft's aber nicht, Meldung:
Code:
The following packages have unmet dependencies:
libdbd-mysql-perl : Depends: libmariadb3 (>= 3.0.0) but it is not going to be installed
libmailutils5 : Depends: libmariadb3 (>= 3.0.0) but it is not going to be installed
libsnmp30 : Depends: libmariadb3 (>= 3.0.0) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Zur HDD:

Code:
> smartctl --all /dev/sde1
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-8-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD60EFRX-68MYMN1
Serial Number:    WD-WX41D948YP6D
LU WWN Device Id: 5 0014ee 2b5f5dd35
Firmware Version: 82.00A82
User Capacity:    6,001,175,126,016 bytes [6.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5700 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Tue Oct 20 23:23:47 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
See vendor-specific Attribute list for failed Attributes.

General SMART Values:
Offline data collection status:  (0x00)    Offline data collection activity
                    was never started.
                    Auto Offline Data Collection: Disabled.
Self-test execution status:      (  73)    The previous self-test completed having
                    a test element that failed and the test
                    element that failed is not known.
Total time to complete Offline
data collection:         ( 6344) seconds.
Offline data collection
capabilities:              (0x7b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003)    Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01)    Error logging supported.
                    General Purpose Logging supported.
Short self-test routine
recommended polling time:      (   2) minutes.
Extended self-test routine
recommended polling time:      ( 717) minutes.
Conveyance self-test routine
recommended polling time:      (   5) minutes.
SCT capabilities:            (0x303d)    SCT Status supported.
                    SCT Error Recovery Control supported.
                    SCT Feature Control supported.
                    SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   001   001   051    Pre-fail  Always   FAILING_NOW 55424
  3 Spin_Up_Time            0x0027   222   193   021    Pre-fail  Always       -       7858
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       39
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   034   034   000    Old_age   Always       -       48426
10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       34
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       6
193 Load_Cycle_Count        0x0032   183   183   000    Old_age   Always       -       52211
194 Temperature_Celsius     0x0022   116   108   000    Old_age   Always       -       36
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   199   199   000    Old_age   Always       -       1655
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: unknown failure    90%     48424         -
# 2  Short offline       Completed: unknown failure    90%     48424         -

SMART Selective self-test log data structure revision number 1
SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Ich meld' mich morgen wieder - muss morgen früh raus.

Dank schon mal.
LG
 
Achso, ja, wenn die Pakete alle so alt sind, dann kann das zu Problemen kommen. Kann man alles lösen, aber ist viel Handarbeit denke ich (hier spricht ein Gentoo-Nutzer ^^).
Zur HDD: Ja, die geht gerade kaputt ^^
Ist das ein RAID1? Hast du nen Backup von dem ganzen Kruscht?

gruß
hostile
 
Da liegt der Hase im Pfeffer!
197 Current_Pending_Sector 0x0032 199 199 000 Old_age Always - 1655

Lesematerial:

@hostile die HDD ist keineswegs zwingend am Sterben - sollte sich die Anzahl der schwebenden Sektoren nach Überprüfung der Sektoren dann bei den "Reallocated_Sector_Ct" wiederfinden, dann hast du natürlich recht.

Insgesamt frage ich mich allerdings was für eine Spiegelung der TE dort einsetzt.
Eine vernünftige Raid Lösung kann es jedenfalls nicht sein, denn diese würde normalerweise die nicht lesbaren Sektoren einer HDD automatisch neu schreiben, wobei diese dann überprüft werden und ggf. durch Reservesektoren ersetzt werden.
Bei einigen Raid Lösungen muß die Überprüfung des Raids manuell angestossen oder eine regelmässige Prüfung erst eingerichtet werden >> nennt sich bspw. patrol read oder auch scrubbing z.B. bei ZFS.

Insgesamt scheint mir das System eher schlecht gepflegt zu sein, was man auch an den Broken Packages sieht!
 
Insgesamt scheint mir das System eher schlecht gepflegt zu sein, was man auch an den Broken Packages sieht!

Ich schrieb ja, dass ich kein Linux-Spezailist bin: habe nach bestem Wissen und Gewissen meinen Server (immer wieder) aufgesetzt, er läuft auch klaglos seit schätzungsweise 15 Jahren, dieses ist das 1. Problem - haut bitte nicht auf mir rum. Ich bin ja gerne gewillt, es mit Eurer Hilfe beim nächsten mal besser zu machen.

Insgesamt frage ich mich allerdings was für eine Spiegelung der TE dort einsetzt.

Es läuft täglich per cron ein 'rsync -a -v --delete /mnt/WD60EFRX1/ /mnt/WD60EFRX2/'

Btwy - werden die Daten auf der gepiegelten HDD ok sein - oder eher nicht?

----

Habe gestern Abend noch die mounts der zwei 6 TB media-HDDs WD60EFRX deaktiviert (damit nix mehr herum geschrieben wird), nach dem Frühstück werde ich auch die Stromstecker abziehen. Beim reboot gestern Abend ist er hängen geblieben, hat beim Booten ein Problem mit AHCI gemeldet und auf F1 gewartet - genaue Meldung liefere ich nach (der Server steht physisch nicht hier sondern 1 Haus weiter im Büro - daher administriere ich ihn per Webmin).

Heißt jetzt mal(?):
  • Stromstecker der 2 HDDs abziehen & ausbauen,
  • zwei neue 8-12 TB für 24/7 geeignete HDDs kaufen.
  • Die genaue AHCI-Meldung nochmals produzieren + hier zur Klärung hier posten.
  • Debian 10 downloaden, Installationsmedium bauen (und dann warten, bis Göga mal den Server - mindestens - einen Tag nicht braucht, um ihn neu aufzusetzen).
  • Und nach Neuinstallation die Daten der gespiegelten HDD auf die neuen HDDs - nun im Raid (?) *) - kopieren.
*) ich geh' - nach der Bemerkung oben - davon aus, dass die Spiegelung mit 'rsync' jetzt nicht das Gelbe vom Ei ist. Werde mich einlesen, wie man mit 2 baugleichen Platten unter Debian ein Raid baut (Tipps/Links willkommen)

Sollte das der Weg sein? Welche HDDs - Seagate Ironwolf 10 TB oder WD Gold 10 TB (bis jetzt war ich eher WD-Fanboy...) oder ..... ?

Thx


P.S.: bei den Bürodaten spiele ich dasselbe Spiel mit dem 'Spiegeln' - als qualitativ hochwertige Datenplatte kommt eine 2 TB Western Digital Caviar Black RE4-GP zum Einsatz, gespiegelt wird auf eine Samsung EcoGreen F4 HD204UI 2TB. Auch überdenken?
 
Zuletzt bearbeitet:
Wenn du neu aufsetzt, dann mit CentOS 8. Damit hast du bis 2029 (EOL) Ruhe und kannst auf Cockpit setzen, welches die von RedHat unterstützte, "offizielle" WebGUI ist. Das kann nicht komplett alles, was webmin kann, aber deckt ordentlich was ab, wie z.B. Storage Konfiguration, Netzwerk, Virtuelle Maschinen, Docker (Podman) etc. Dann aktivierst du noch Auto Sicherheits-Updates (ebenfalls über Cockpit WebGUI konfigurierbar) und das Ding läuft quasi von alleine.

State of the art ist eigentlich, dass man einen schlanken Host / Hypervisor nimmt (Proxmox, ESXi, Linux deiner Wahl + KVM, was auch immer) und dann die Dienste in virtuelle Maschinen / Container verfrachtet. Hat den Vorteil, dass der Host stabil läuft und im Problemfall in Rekordzeit wieder aufgesetzt werden kann und dass die Dienste isoliert & unabhängig voneinander laufen und bei Bedarf ohne großen Aufwand auf einen anderen Host / PC verschoben werden können. Bsp.: deine Videoüberwachung kann weiterlaufen, während du die DLNA VM neu aufsetzt, weil es dort ein Problem gab.

Auch nutzen viele Leute mittlerweile ZFS, welches (neben vielen anderen Features) Checksummen integriert und somit gegen Silent Bitrot schützt. In deinem persönlichen Fall würde ich dir jedoch davon abraten, da diese Sachen regelmäßig gewartet werden müssen, eine steile Lernkurve haben und mit einem deutlichen Mehraufwand verbunden sind. Set and forget ist da eher nicht der Fall. Daher würde ich vorschlagen, wie bisher alles auf dem Host zu installieren und ggf. die 6TB gegen eine 10TB oder 12TB zu tauschen, wenn du mehr Speicher benötigst.

Bzgl. Synology: Samba, DLNA, CoW Dateisystem sind alle enthalten und funktionieren völlig problemlos. USV bin ich mir unsicher, müsste aber auch drin sein. Bei der Überwachungskamera müsstest du gucken, ob deine jetzigen Kameras ONVIF können. Falls ja, kannst du die Software "Surveillance Station" von Synology verwenden, welche (ich glaube) für 2 Kameras kostenlos verwendet werden kann. Wenn du mehr Kameras benötigst, musst du eine Lizenz erwerben. Surveillance Station ist ZoneMinder überlegen.

Die Synology nimmt dir viel Arbeit ab und macht einige Sachen, wie RAID und BTRFS, kinderleicht in der Konfiguration. Gerade dann sehr wertvoll, wenn du Wartung & Konfiguration auf ein Minimum begrenzen möchtest. Ich finde sowohl Reparatur, als auch Synology in Ordnung, würde dir aber erstmal vorschlagen die Reparatur auszuprobieren - da weißt du ungefähr, was dich im Ziel erwartet, wenn alles fertig ist. Und wenn du dann doch auf Synology wechseln willst, kannst du die HDDs einfach mitnehmen. Welches Synology Modell aber jetzt gut / schlecht ist, müsste dir wer anders weiterhelfen. Kenne mich mit deren Hardware nicht aus.

//Edit:

ich geh' - nach der Bemerkung oben - davon aus, dass die Spiegelung mit 'rsync' jetzt nicht das Gelbe vom Ei ist. Werde mich einlesen, wie man mit 2 baugleichen Platten unter Debian ein Raid baut (Tipps/Links willkommen)
Nein, das ist völlig in Ordnung. Kein RAID bedeutet einfach nur, dass im Katastrophenfall (wie jetzt bei dir) du mit einer Downtime rechnen musst - also dass dein System für einige Zeit nicht benutzbar ist. Wenn das für dich vertretbar ist, kannst du das so weiterführen. Wenn Downtime nicht in Ordnung ist, dann brauchst du RAID. Hätte dein jetziges System RAID1 gehabt, wäre dieser Vorfall "normaler Alltag" und hätte sich nach einem Festplattentausch von selbst erledigt. In der gesamten Zeit (Festplattentausch, Rebuild) wäre dein System benutzbar.

Wichtig ist in beiden Fällen, dass deine Backups funktionieren. Hier würde ich dir empfehlen in Zukunft auf andere Lösungen umzuschwenken. borg-backup ist der heilige Gral mit Versionierung, Deduplizierung, Verschlüsselung und Checksummen, aber auch etwas komplex. Mit Checksummen stellt sich dir dann die Frage nicht mehr "sind meine rsync Backups eigentlich in Ordnung?". Gibt aber auch einfachere Tools, die auf rsync basieren wie z.B. rsnapshot, welches dir deine Backup-Dateien versioniert. Schau dich da auf jeden Fall um. Auch wichtig an dieser Stelle: ein Backup ist kein Backup.

Btwy - werden die Daten auf der gepiegelten HDD ok sein - oder eher nicht?
rsync hat dafür eine Checksummen Option. Ist aber sehr gut möglich, dass dir die kaputte Festplatte dabei flöten geht, da die Daten auf der Festplatte *komplett* gelesen werden. Das erzeugt zusätzlichen Stress. Wenn du keine weiteren Backups hast (also 1 Original und 1 Spiegel), dann würde ich da nichts mehr anrühren und wie folgt vorgehen:
Du kaufst die neuen Festplatten, spiegelst die Originale 1:1. Das kannst du entweder mit dd machen auf Block / Partition Ebene (https://wiki.archlinux.org/index.php/Dd#Disk_cloning_and_restore), oder mit rsync -avxHAWXS auf Dateisystem Ebene. Wenn dabei Probleme auftreten, stellst du von den Backups wieder her.
 
Zuletzt bearbeitet:
Vielen Dank für Deinen ausführlichen Input. Das, was Du im 2. Absatz schriebst, hab' ich eher weniger verstanden - bin aber froh, dass Du meinst, dass ich besser den Server reparieren und nicht unbedingt auf NAS umsteigen sollte (und dass Raid nicht unbedingt sein muss). Meine (wichtigen) Bürodaten werden a.) am Server auch (mit rsync) gespiegelt und b.) zusätzlich mit einem Backup-Programm von einem Win$-PC im Privathaus gesichert, monatliches fullbackup, täglich (zumindest wenn ich den PC aufdreh') Smartbackup. Die (weniger wichtigen) Videos & Audiodateien werden auf den zwei 6 TB HDDs nur gespiegelt). Und es ist kein Problem, wenn die Videoüberwachung ein paar Tage nicht funktioniert oder die Videos nicht verfügbar sind.

Das System des Debian-Servers läuft auf einer eigenen, kleinen SSD. Und eine ebensolche hab' ich auch noch in er Lade liegen - d.h. durch einfaches Umstöpseln der System-SSD kann ich Centos aufsetzen ohne an der bestehenden Installation was kaputt zu machen.

Heißt:
  • Zwei HDDs 8-12 TB/Stück besorgen (welche? *) )
  • Die übrig gebliebene 6 TB HDD (die 'noch gute') nehm' ich in Zukunft, um meine Videos übers Netz auf einem Win$-PC zu backuppen.
  • Centos downloaden
  • Reserve-SSD fürs neue System herrichten
Danke vorläufig.


*) Ich hätt' mir jetzt bei Geizhals eine gesucht - 7/24-fähig, 5 J Garantie, CMR, 8-12 TB .... Seagate Ironwolf 10 TB oder WD Gold 10 TB ... ?
 
Gerade bei deinem Anwendungsprofil stellt ein NAS durchaus die optimale Lösung dar, zu der ich dir auch stark raten würde. Gerade, wenn man nicht die Zeit hat, sich mit der Linux-Thematik zu beschäftigen und sich nicht erst lange einlesen möchte, welches Setup man nun genau fahren soll ist ein NAS die deutlich bessere Lösung. Hol dir ein vernünftiges 4-bay NAS (Qnap, Synology), 4 identische Platten rein, RAID5 drüber, die benötigten Dienste konfigurieren -> fertig! Kein Rumgebastel, kein langwieriges Einlesen, nicht unzählige Möglichkeiten, das Setup zu verkonfigurieren, etc.

Wenn wichtige Daten vorhanden sind, würde ich dir ZUSÄTZLICH noch ganz dringend zu einem vernünftigen Offline-Backup raten. Also z.B. 1x im Monat die wichtigen Daten beispielsweise auf ne BD-RE, M-Disc oder auf Band sichern (je nach Anforderung).
 
Das dachte ich mir, dass es da unterschiedliche Ansichten gibt ;-)

Ich hab' jetzt mal die 2 media-HDDs ausgebaut, der AHCI-Fehler von gestern Abend kommt jetzt nicht mehr beim Boot. Dafür ist mir eine andere Meldung aufgefallen:
Code:
/dev/sda1/: clean, xxxxxx/xxxxx files .... blocks
[ 4.839830] r8169 xxxx:xxx:xxxx: firmware faileed to load rtl_nic_rt18168d-1.fw (-2)
Ich schätze, dass bei einem Neuaufsetzen unter Centos das ohedies weg ist. Ich kümmere mich jetzt um 2 neue HDDs.

Thx
 
Bzgl. HDDs: Ich setze auch auf WD oder Hitachi. Zur Zeit habe ich zwei WD Gold 6TB. Ich würde auch wieder eine Gold kaufen.
Siehe https://geizhals.de/?sr=1386736,-1 ;-)

gruß
hostile
Beitrag automatisch zusammengeführt:

PS: Mein NAS habe ich übrigens via NFS an meinen (Linux-)Router (VM) angeschlossen und stelle die Shares per Samba bereit. Selbst wenn mal mein Gentoo kaputt gehen sollte, komme ich trotzdem noch auf meine Dateien.

gruß
hostile
 
und dass Raid nicht unbedingt sein muss
Es kann natürlich auch sein, dass nicht deine 6TB, sondern deine 2TB mit den Bürodaten ausfällt. Dort gilt das mit der Downtime genauso.

Mit den WD 10TB Gold machst du nichts verkehrt. 5 Jahre Garantie, 7200rpm, werden im Synology unterstützt (falls du dich doch umentscheidest) und günstiger als die Ironwolf Pro.
 
Es dürften doch 2 Seagate Ironwolf Pro werden (link) - die Dinger sind deutlich leiser als die WD red oder gold (der Server steht neben einem Büroarbeitsplatz). Außerdem liest man von WD was von Vibrationen und SMR drin, wo CMR drauf stand...

Eine Downtime bei den Bürodaten ist auch problemlos verkraftbar.
 
Es läuft täglich per cron ein 'rsync -a -v --delete /mnt/WD60EFRX1/ /mnt/WD60EFRX2/'
Sowas hatte ich schon fast vermutet!

Das ist keine Spiegelung in dem Sinne, sondern eine einfachste "Online"-Datensicherung wobei hier einige "Grundsätze" einer effektiven Datensicherung verletzt werden.
- Sicherungsdatenträger in einem anderen Gehäuse
- Sicherungsdatenträger wird nur während der Datensicherung angeschlossen
- Sicherungsdatenträger befindet sich räumlich getrennt - mind. in einem anderen Brandabschnitt

Btwy - werden die Daten auf der gepiegelten HDD ok sein - oder eher nicht?
Das kann man nicht garantieren, da keine Prüfsummen verwendet wurden und auch keine Verifizierung der gesicherten Daten. Ich würde hier durchaus damit rechnen, daß die ein oder andere Datei beschädigt sein kann. Auch ist nicht Sicher, daß auch wirklich alle Dateien gesichert sind, da niemand weiß, seit wann die schwebenden Sektoren aufgelaufen sind.

Das mindeste was man machen sollte ist ein regelmäßiger Dateisystemcheck - dürfte bei Linux fsck sein. Ob fsck auch schwebende Sektoren erkennen und reparieren kann wie z.B. Chkdsk - R unter Windows weiß ich nicht, ggf. gibt es dafür dann andere "Werkzeuge" unter Linux, die die ganze HDD untersuchen. Darum brauche ich mir bei ZFS keine Gedanken machen
Beitrag automatisch zusammengeführt:

Kein RAID bedeutet einfach nur, dass im Katastrophenfall (wie jetzt bei dir) du mit einer Downtime rechnen musst - also dass dein System für einige Zeit nicht benutzbar ist.
Da es sich hier um eine "Onlinedatensicherung" auf Dateibasis handelt ist die Downtime vernachlässigbar, da nur die Mountpoints und/oder Freigaben umgebogen werden müssen - es fehlen halt die Daten seit der letzten Sicherung, da es keine Permanente Synchronisierung wie bei einem Raid ist. (rsync kann das auch nicht, dafür gäbe es bspw. lsyncd)
 
Zuletzt bearbeitet:
... wobei hier einige "Grundsätze" einer effektiven Datensicherung verletzt werden.
Jein. Die allerwichtigsten Daten gibt's (mindestens) auf 3 verschiedenen Datenträgern an 2 verschiedenen Orten - die Buchhaltung läuft z.B. lokal am Büro-PC meiner Göga, nach getaner Buchhaltung sichert sie durch Button-Druck die BH-Daten auf den Server. Und wenn ich tags drauf ein Haus weiter meinen PC einschalte, wird vom Server automatisch übers Netz zumindest ein inkrementelles Backup gezogen (1x/mon vollständig).

Nur bei den TV-Filmen hab' ich es beim Wegkopieren auf eine 2. HDD mit rsync belassen. Noch - denn beim Umbau bleibt ja eine 6 TB HDD übrig, da kann ich in Zukunft gelegentlich gesammelte TV-Filme übers Netz herüber sichern.

---

Ich weiß genau, welcher TV-Film auf der notleidenden Media-HDD als letztes aufgenommen wurde - diesen schau' ich mir als erstes an, ob er sich fehlerfrei abspielen lässt. Bis die neuen 10 TB HDDs da sind, fummle ich aber an der notleidenden HDD nicht rum (auch wenn ich noch so neugierig bin) - die muss rein gesteckt & sofort auf die neue kopiert werden (was ich mit Knoppix in einem anderen PC tun werde). 3-4 Tage Lieferzeit für die Seagates.

Thx
 
Wenn ein Film weg ist, who cares. Kann man wiederbeschaffen oder ein Netflix/XX Abo nehmen....

Größeres Problem sind "Silent Data Errors" also stille Dateifehler. Wenn eine Datei dadurch fehlerhaft wird, so betrifft das auch alle Backups dieser Datei. Das bekommt man nur mit wenn man Prüfsummen der Dateien anlegt oder das Dateisystem das automatisch macht (btrfs, ReFS nach Extra-Aktivierung oder das Vorbild ZFS) und bei Fehlern sogar automatisch repariert (self healing filesystem). Ansonst "Tschüß wichtige Datei". Einmal kaputt, immer kaputt auf allen Backups.

Nachstes Problem ist Ransomware. Die werden z.B. durch Öffnen einer Mail und Anklicken des Anhangs aktiviert. Die laden dann eine Schadsoftware die z.B. die Platten verschlüsselt um Lösegeld zu fordern.

Würde ich eine derartige Schadsoftware programmieren um möglichst viel Geld zu machen, würde ich zuerst alte Dateien verschlüsseln und regelmäßig auf verbundene Laufwerke (Backup) prüfen. Finde ich sowas würde ich zuerst deren Dateien (älteste zuerst) verschlüsseln. Wenn der Benutzer das Problem entdeckt ist der Schaden maximal (kein Backup). Dafür eine Bitcoin Adresse zum Überweisen.

Leider hatten andere die Idee bereits und ich bin nicht kriminell genug.,,
Readonly Snaps auf einem Fileserver die ein Windows Admin nicht löschen kann wie bei ZFS, helfen da enorm.
 
Zuletzt bearbeitet:
@Oktavus ich hab nochmal was besseres gefunden für deine vermutlich sterbende Platte: https://wiki.archlinux.org/index.php/disk_cloning. ddrescue ist speziell für sterbende Festplatten gemacht, um so wenig Schaden wie möglich anzurichten bzw. soviele Daten wie möglich zu rettern.

da nur die Mountpoints und/oder Freigaben umgebogen werden müssen
Eigentlich kann man das so machen, in diesem Fall würde ich aber davon absehen. OP hat "rsync -av" verwendet, was ACLs, Hard Links und extended Attributes nicht inkludiert; es ist also keine 100%ige 1:1 Spiegelung. Besser ist "rsync -avxHAWXS" für die Zukunft: https://explainshell.com/explain?cmd=rsync+-avxHAWXS.

es fehlen halt die Daten seit der letzten Sicherung, da es keine Permanente Synchronisierung wie bei einem Raid ist.
Normalerweise würde man das so machen, dass man vor einem Recovery-Versuch noch ein letztes mal rsync ausführt, bevor man einen Rebuild anstößt. Der gleicht dann die Dateinamen / Timestamps ab und kopiert nur, was sich verändert hat. Das ist auch bei mittelgroßen Dateisystemen i.d.R. ein effizienter Prozess - wenn auch nicht vergleichbar mit ZFS / BTRFS send receive. Würde ich in diesem Fall jetzt aber nicht vorschlagen, da unklar ist, ob das Backup intakt ist (lieber nicht auf die Probe stellen) und 2) die HDD sehr wahrscheinlich kurz vor dem Abrauchen ist.

@gea: ich weiß nicht, ob OP geholfen ist, wenn man ihm da ein ZFS hinstellt, womit er sich nochmal von Grund auf neu beschäftigen muss (plus *BSD bzw. Solarish). Ich erinnere immer gerne an die GitLab-Katastrophe: 5 verschiedene Backup-Lösungen und keines funktioniert im Katastrophenfall, weil sich niemand damit aktiv beschäftigt hat / niemand sich damit auskannte.

Desweiteren nutzt OP den Speicher eher als Online-Backup und weniger als "NAS". Für die wichtigen Daten wendet OP das 3-2-1 Prinzip an: 3 Kopien (Büro-PC auf der Arbeit, Server, PC Zuhause), 2 Medien (lokaler PC, Server) und 1 Off-Site (Zuhause). Denke aber auch, dass es optimal wäre, wenn einer der Backups Checksummen / Versionierung könnte.
 
@gea: ich weiß nicht, ob OP geholfen ist, wenn man ihm da ein ZFS hinstellt, womit er sich nochmal von Grund auf neu beschäftigen muss (plus *BSD bzw. Solarish). Ich erinnere immer gerne an die GitLab-Katastrophe: 5 verschiedene Backup-Lösungen und keines funktioniert im Katastrophenfall, weil sich niemand damit aktiv beschäftigt hat / niemand sich damit auskannte.

Desweiteren nutzt OP den Speicher eher als Online-Backup und weniger als "NAS". Für die wichtigen Daten wendet OP das 3-2-1 Prinzip an: 3 Kopien (Büro-PC auf der Arbeit, Server, PC Zuhause), 2 Medien (lokaler PC, Server) und 1 Off-Site (Zuhause). Denke aber auch, dass es optimal wäre, wenn einer der Backups Checksummen / Versionierung könnte.

ZFS ist unter Linux einfach als weitere Dateisystemoption statt ext4 einsetzbar. Man muss sich lediglich darum kümmern wie man per zfs oder zpool Befehl ein Raid einrichtet (zpool create), Platten ersetzt (zpool replace), Dateisysteme anlegt und snaps anlegt (zfs create). Ist sehr gut dokumentiert und ein gradliniger Vorgang. Viel weniger Kenntnisse notwendig als auch ähnliches ohne ZFS zu machen. Lediglich die Integration in das OS oder die Problemlosigkeit bei Updates ist unter Free-BSD oder Solarish wo ZFS herkommt ausgereifter. Wer Linux kennt, sollte aber auch keine Probleme mit diesen beiden Unix Varianten haben zumal es da die besseren ZFS Web-Appliances gibt die man komplett per Browser bedient.

Ich selber bin komplett zu ZFS gegangen (vor 12 Jahren) nachdem mein Mailserver mit ntfs und Raid-5 plötzlich ein chkdsk wollte und danach nur Rührei auf der Platte war. Backup war vorhanden aber halt wie altes Brot - immer von gestern. Seitdem hatte ich nie mehr einen Datenverlust wegen defekten Raid/Pool und wurde immer rechtzeitig über Probleme informiert. In den 12 Jahren konnte ich jedesmal eventuelle Wiederherstellungen aus den Snaps realisieren. Auf den Disasterfall plötzlich defekter Pool/Rechner weg + Backup aus exterenem Systemen bin ich vorbereitet, habe ich aber in der ganzen Zeit nicht gebraucht.

ps
Wenn eines der Backlupsysteme Prüfsummen/Snaps hat dann sorgt man nur dafür, dass eine eventuell defekte/verschlüsselte Datei vom Primärspeicher beim Backup mit Prüsummen versehen und als korrekt angesehen wird. Das bringt nur was wenn es auf dem Primärspeicher passiert. Dort sollte auch die Versionierung mit readonly Snaps erfolgen. Backups die man unter ZFS mit Snaps ohnehin nur im absoluten Disasterfall benötigen sollte, können dann sogar eher auf externem Speicher ohne Prüfsummen (auch Cloud) liegen.
 
ZFS ist unter Linux einfach als weitere Dateisystemoption statt ext4 einsetzbar.
Im Gegensatz zu ext4, XFS oder BTRFS ist ZFS nicht im Upstream Kernel und daher muss es über DKMS / kABI / Custom Kernel in das System eingepflegt werden. Ubuntu bringt ZFS sei 18.04 von Haus aus mit und macht es tatsächlich "einfach". Da ist aber abschließend die Frage nicht geklärt, ob das überhaupt so in Ordnung ist. Niemand kann voraussagen, ob es das in 3 Jahren noch geben wird oder ob Oracle heute Abend schon eine Klage einreicht. Dann haben wir natürlich noch die GPL Diskussionen, die alle paar Jahre aufflammen, wie zuletzt bei Kernel 5.0, wo dann ZoL einige Kernel-Funktionen verwehrt wurden. Das war eigentlich garkeine Absicht, sondern liegt darin begründert, dass ZFS eben nicht Teil des Upstream Kernels ist und somit keine Rücksicht darauf genommen wird, ob neue Kernel-Änderungen das ZFS Modul kaputt machen oder nicht.

Ja, es funktioniert. Sogar so gut, dass die Hauptentwicklung heutzutage in ZoL geschieht und sogar FreeBSD das ganze für *BSD (zurück-)portiert. Es ist aber halt keine Lösung, wo ich sagen würde, dass OP problemlos die Auto-Updates drin lassen kann und sich bis 2029 keine Gedanken mehr um das System machen muss, außer kaputte Hardware auszutauschen. Denke für ein Set-and-Forget ZFS würde ich eher Richtung nacktes FreeBSD tendieren.

Ich habe weiter oben geschrieben, das aktueller Standard Virtualisierung und CoW-Dateisysteme, wie BTRFS / ZFS sind. Da gibt es keine Zweifel - nutze ich ja auch selbst. Ich denke aber trotzdem, dass OP eine einfache, Selbstläufer Lösung braucht: erstmal probieren, ob der aktuelle Server wieder wie gewohnt läuft. Falls nicht, halte ich eine Eigenlösung mit ZFS / BTRFS / FreeBSD für den OP als Fehlberatung und würde ihn stattdessen Richtung Synology schicken. Da ist er besser aufgehoben.
 
Zuletzt bearbeitet:
Ich hab' in der Zwischenzeit heraus gefunden, warum ich keine automatische Email gekriegt hab', als der smartmon-test anschlug - ich Depp hab' zwar alles konfiguriert, den Emailversand vom Server hin gekriegt, getestet - und anscheinend zum Schluss vergessen selbiges für alle HDDs zu aktivieren -> es war nur /sda überwacht...

Weiter warten auf die HDDs. Ansonsten bin ich dabei 4 Rechner umzubauen & unter Win10 neu aufzusetzen - ich hab' schon 4eckige Augen.
 
Während ich auf die neuen HDDs warte, könnten wir 2 Punkte klären:

1.) Vorgangsweise beim Datenretten:
Du kaufst die neuen Festplatten, spiegelst die Originale 1:1. Das kannst du entweder mit dd machen auf Block / Partition Ebene (https://wiki.archlinux.org/index.php/Dd#Disk_cloning_and_restore), oder mit rsync -avxHAWXS auf Dateisystem Ebene.
Wenn die 2 neuen einlangen, wie wäre da die genaue Vorgangsweise(?)
  • die Daten der notleidenden original-Daten-HDD auf die neue original-Daten-HDD
  • und die Daten der alten 'Mirror' auf die neue 'Mirror' (mit rsync -avxHAWXS)
... oder wie ist das gemeint? Btwy - habe beide HDDs in einem Win$-PC kurzfristig in Betrieb genommen, um sicher zu gehen, welche der 2 die Notleidende ist -> auch der 2. geht's nicht mehr sonderlich.

--------------

2.) Server-Security:

Ich hab'
  • vom Provider ein Modem zur Verfügung gestellt bekommen, das so konfigueriert ist, dass von außen niemand herein kommen sollte (wollte ich VPN machen, muss umgestellt werden).
  • Zusätzlich hab' ich eine ipfire auf einem Alix-Board laufen (Standardeinstellungen, weil ich von FW nix versteh').
  • Und dass alle Win$-PCs im SoHo (up do date sein sollten und) einen Internetschutz haben, ist klar (bis jetzt Kaspersky; für Win10 lese ich grad die Diskussionen, ob Defender ausreicht...?)
... ich frag' mich jetzt, wie wichtig ist es, den Linux-Server aktuell zu halten??? Wenn er das tut, was er soll (Samba-Shares bereitstellen), ist's doch ok - oder? Einfallstor für Viren etc. wären doch ohnedies die Win$-PCs - und offene Samba-Shares gibt's ja auch, wenn der Server aktuell wäre...? Ich frag' mich, ob ich den überhaupt neu aufsetzen soll bzw. war mir Debian immer sympathischer als Centos, auch wegen der deutschsprachigen Doku + Community (ich tät's aber auch unter Centos schaffen).


3 PCs sind auf Win10 umgestellt, weiter warten auf die neuen HDDs.

Thx
Oktavus
 

Anhänge

  • WD_Festplattenproblem1.jpg
    WD_Festplattenproblem1.jpg
    100,8 KB · Aufrufe: 99
  • WD_Festplattenproblem_2.jpg
    WD_Festplattenproblem_2.jpg
    97,6 KB · Aufrufe: 101
Für die Original-Daten-HDD auf neue Original-Daten-HDD nimmst du ddrescue, was ich hier gepostet hatte: https://www.hardwareluxx.de/community/threads/server-reparieren-oder-nas.1279544/post-27778582

Die 2. Festplatte mit neu zugewiesenen Sektoren ist schlecht einschätzbar. Da wissen wir leider nicht, ob das jetzt ganz neu hinzugekommen ist (schlecht), oder ob die seit Jahren bestehen (eher beruhigend). Ich würde daher auch damit so vorgehen, wie bei der Original-HDD: mit ddrescue.

Die Festplatten am besten nicht parallel kopieren, sondern nach einander. Der Grund: wenn es Probleme beim Kopieren der ersten Platte gibt, kannst du dich dann bei der zweiten Platte entscheiden, ob du das bei einem professionellen Dienstleister abgibst, oder Roulette spielst. Ob es schlauer ist, mit der Original-Daten-HDD oder mit der Mirror-HDD anzufangen, ist eine Frage, auf die ich leider keine Antwort weiß. Da kann hoffentlich jemand anderes weiterhelfen.

*Sollte* das Klonen problemlos funktionieren, führst du zwischen den neuen Festplatten (Original-Daten-HDD und Mirror-HDD) einen "rsync -a -v --dry-run --checksum" durch. Der vergleicht dir alle Daten anhand der Checksumme und ändert nichts an den Daten (--dry-run). So kannst du wissen, ob die Daten auf beiden Datenträgern auch wirklich identisch sind, und nicht etwa irgendwann mal korrupt geworden sind - etwa durch Silent Bit Rot. Sollte es (alte) Daten geben, die sich unterscheiden, dann kriegst du die Dateinamen und musst manuell gucken, welches die "gute" Kopie ist.

wie wichtig ist es, den Linux-Server aktuell zu halten?
Wenn du einen problemlosen Betrieb willst - sicherheitskritische Bedenken mal außen vor - muss der regelmäßig geupdated werden. Es ist völlig egal, ob du ipfire / opnsense verwendest. Was zählt, ist die Konfiguration. Ausgehend davon, dass du dich nicht mit den Firewall-Settings näher beschäftigt hast und wir auch nicht wissen, wann deine Firewall / dein Router das letzte mal geupdated wurden, würde ich jetzt nicht vom Idealfall ausgehen.

Bzgl. Distro: nimm das, womit du besser klar kommst. Im Ernstfall musst du damit klar kommen. CentOS war ein Vorschlag von mir, da es dafür gemacht ist, ohne viel Wartung zu laufen. Red Hat Enterprise Linux - worauf CentOS basiert - wird von einem Milliarden-schweren Unternehmen entwickelt, welches die meisten Fortune 500 Unternehmen damit versorgt (die dafür gutes Geld hinlegen). Das wird laufend geprüft und zertifiziert - da stehen Stabilität, Sicherheit, Wartbarkeit und Planbarkeit ganz vorne. RHEL / CentOS ist das einzige Betriebssystem (!) - egal ob *BSD, MacOS, Windows, jegliche andere Linux-Distros - dem ich zutraue, über Jahre hinweg mit Auto-Sicherheits-Updates problemlos zu laufen. SELinux ab Werk tut sein übriges für Zero Day Exploits. EOL ist CentOS 8 erst 2029 - also keine Kopfschmerzen für die nächsten ~9 Jahre. Nachteil ist, dass die Standard-Repo nur wenige Pakete hat, die dafür aber extrem stabil laufen. In den Basis-Repos nicht vorhandene Pakete kannst dir aber aus den EPEL-Repos holen, wie z.B. den ZoneMinder.

Das beste OS / Dateisystem / Hardware nützt nichts, wenn du damit nicht klar kommst. Wenn du dich mit Debian sicherer fühlst, nimm das. Ich selbst fahre Arch Linux. Warum? Weil ich mich damit am besten auskenne. Meine NAS-Installation lief damit ca. ~7 Jahre völlig problemlos (selbe Installation!); nach einem System-Wechsel habe ich den der Vollständigkeit halber neu installiert - eigentlich hätte der das nicht gebraucht. Der läuft jetzt mit BTRFS; nach wie vor völlig problemlos.
 
Zuletzt bearbeitet:
Wenn man einen problemlosen Betrieb möchte, richtet man das Ding einmal ein und gut ist.
Gerade eben durch diese Updaterei holt man sich "Probleme" ins Haus. Never change running system. Es sei denn man hat selbst den Anspruch, up-to-date sein zu wollen und alle Sicherheitslücken soweit wie möglich gefixt zu sehen. Das ist eben Arbeit.

Das muss aber jeder selbst abwägen. Sind die Daten interessant für andere (OP hatte geschrieben, es sind auch Firmendaten drauf) - auch Zerstörung dieser Daten etc.
Da könnte man jetzt noch Stunden drüber philosophieren...

gruß
hostile
Beitrag automatisch zusammengeführt:

PS: Wobei ich sagen muss, bisher hatte keine Binärdistribution im Einsatz - erst jetzt so langsam beschäftige ich mich mit Ubuntu. Das funktioniert meistens echt richtig gut. Was ich mit Problemen meine ist, dass man einfach ein Update macht und das Programm dann neue Features hat oder alte Features kaputt gegangen sind etc. Also wie in Windows :d (wo plötzlich die Drucker nicht mehr gehen oder SMB1 einfach abgeschaltet wird ^^
 
Zuletzt bearbeitet:
Wenn man einen problemlosen Betrieb möchte, richtet man das Ding einmal ein und gut ist.
Genau das ist ja der Punkt - ich seh' irgendwie nicht ein, warum ich die ständige Updaterei machen sollte, wenn der Server nur Samba spielt (zumindest hat mir noch niemand plausibel erklärt, warum ich das machen sollte). Ich tendiere auch eher Richtung 'never touch a running system' - darum hab' ich auch kein Kopfweh gekriegt, als ich vor 2 Jahren schon festgestellt habe, dass das Update fehl schlägt. Wenn sich einer von uns einen grausigen Virus einfangen sollte, kommt der IMHO über einen Win$-PC - und über Samba ist er eh dann auf den Serverdaten.

So gesehen würde ich ihn unter Debian gerne neu aufsetzen (vielleicht lass' ich mich auch zu Centos überreden - ich hatte ihn ja schon mal unter Centos ein paar Jahre laufen) - aber vor allem deswegen, weil mich stört, dass ich ihn wegen verbogener Abhängigkeiten nicht mehr updaten kann.

Wegen der Buchhaltungsdaten: die liegen a.) am Arbeitsplatzrechner der Göga, werden b.) nach getaner Arbeit mit einem Backupprogramm auf den Server gelegt (zugegeben, mit theoretischem Zugriff von allen Seiten). Und c.) werden die Bürodaten vom Server (inklusive dem Buchaltungs-Backup) von einem weiteren Arbeitsplatzrechner ein Haus weiter gebackupt (monatlich Vollsicherung, alle paar Tage inkrementelles Backup). Somit liegen die BH-Daten auf 3 Rechnern an 2 verschiedenen Orten und in mehreren Generationen.

Fotos liegen auch auf einem (privaten) Arbeitsplatzrechner - am Server nur die Kopien. Audiodateien sind auf diversen SD-Karten in mehreren portablen Audiogeräten verteilt - könnten von dort auch wieder hergestellt werden, wenn die Datenkopiererei mit ddrescue nicht ordentlich hin haut. Lediglich die gesammelten TV-Filme sind nur am Server gespiegelt - da ist nicht viel kaputt, sollte einer nicht mehr abspielbar sein.

Was ich mir in den letzten Tagen zur Verbesserung der Situation überlegt habe:
  • Göga wird - zusätzlich - eine USB-SSD kriegen, wo sie ihre Buchhaltungsdaten ein 2. mal sichert. Diese SSD ist dann nicht im online-Zugriff und wird in der Lade liegen.
  • Nachdem die 2 HDDs nach ca. 6 Jahren 7/24-Betrieb bereits so notleidend geworden sind, stell' ich mir die Frage, ob es sein muss, dass diese HDDs wirklich durchlaufen müssen. Ich denke es reicht, wenn die hochfahren, wenn man sie braucht (dann halten die Dinger hoffentlich länger).
  • Die Zugriffsbeschränkungen der einzelnen User am Server könnte ich auch noch restriktiver/sinnvoller einstellen (kein Vollzugriff, wenn eigentlich nur lesend benötigt, bessere Auftrennung der Samba-Shares etc.).
LG


NACHTRAG:
  • Wenn ich es mir recht überlege, müssten die restlichen 2 Datenplatten - eine Western Digital RE4-GP und eine SAMSUNG HD204UI - mittlerweile auch so um die 10 Jahre alt sein. Vielleicht sollte ich die - trotz noch guter smart-Werte - auch gleich tauschen....
 
Zuletzt bearbeitet:
Ich hab noch zwei alte Hitachis 1TB mit ca. 70000 Std. auf der Uhr und ohne Fehler (in der Schublade). Zwei WD Black 1 TB hab ich auch noch, aber die hatte ich erst später gekauft. Die müssten auch so 50000 auf der Uhr haben, auch fehlerfrei (in der Schublade).
Ich bin der Meinung, die Schäden treten (auch) durch die mechanische Belastung durch Hoch- und Herunterfahren auf. Mein WD-NAS wollte sich nicht überreden lassen, die Platten laufen zu lassen. Deswegen hab ich ein Cronjob, der alle 5 Min. eine Datei auf den Platten "touch"t ^^

gruß
hostile
 
... also weitert sich meine geplante Umstellung der PCs auf Win10 durch den gleichzeitig bemerkten HDD-Ausfall am Server mittlerweile zu einer ziemlichen 'Runderneuerung' unserer SoHo-EDV aus - egal, die Tüftelei macht Spaß (und sie ist jetzt viele Jahre klaglos gelaufen - irgenwann muss man mal wieder ran 😉).

Deswegen:
(zugegeben, mit theoretischem Zugriff von allen Seiten)
hab' ich mir jetzt auch Gedanken gemacht - ich könnte noch eine Backup-Ebene einbauen, die nicht im Zugriff der Win$-Workstations ist.

Idee1 - manuell: ich nehm' eine kleine SSD (bleibt beim Umbau eh hier übrig) + eine weitere 12 TB HDD, baue sie in meine private Win$-Workstation ein, formatiere beide mit ext4 - und mach' auf die SSD Debian oder Knoppix o.ä. drauf (Bootauswahl mit F10 aus dem BIOS). Unter Linux dann ein Script oder ein backup-Programm, das mir den kompletten Server auf die 12 TB ext4 HDD backupt. Sollte ich mir unter Windows einen Verkryptungs-Virus einfangen, sind die ext4-HDDs nicht im Zugriff :coolblue: . Nachteil: die 12 TB ext4 HDD läuft unter Windows mit (verschmerzbar), backuppen muss ich manuell. Vorteil: ich kann auch das Emailverzeichnis der Workstation sichern.

Idee2 - automatisch: ich nehm' einen RasPi4 (liegt eh hier rum) oder einen ähnlichen Kleincomputer (falls man einen findet, der per WoL aufgeweckt werden kann und/oder der die 12 TB HDD per SATA dran bringt) - so könnte selbiger per cron wöchentlich (oder täglich?) die angschlossene HDD aus dem Ruhemodus hochfahren, sich auf den Server verbinden, backuppen und die HDD wieder in den Ruhemodus fahren. Nachteil: der RasPi4 müsste 7/24 laufen, weil er nicht (von Debian-Server) per WoL aufgeweckt werden kann, es steht wieder technisches Zeugs herum und ich muss mir für die Sicherung der Emails was anderes einfallen lassen.

Was hält Ihr von diesen Ideen? Welche bevorzugen? Zusätzlich oder anstatt der Mirror-Platten im Debian-Server?

Thx
 
Zuletzt bearbeitet:
Zu Idee 1: die Ransomware hat zwar nicht Zugriff auf die Dateien im ext4-Speicher (nicht unmöglich), aber der kann dir natürlich den Speicher auch einfach so kaputt machen (zufällige Bits kippen, mit Nullen überschreiben, Festplatten-Firmware überschreiben usw.). Keine gute Idee.

Meine Meinung: entweder macht man es simpel und nimmt dann die Randfälle in Kauf, oder man macht es richtig. Bevor du es so kompliziert machst und der Wartungsaufwand sowieso steigt, würde ich vorschlagen, dass du auf irgendeiner Ebene Versionierung einsetzt. Hier gibt es ganz verschiedene Möglichkeiten, je nach Anforderung und mit verschiedenen Vor- und Nachteilen.

Die aus technischer Sicht beste Option wäre ZFS / BTRFS mit Mirror + automatischen Snapshots (Versionierung) lokal auf dem Server, sowie Duplicati / borg-backup für die Remote Backups (bei dir Zuhause). Das deckt nahezu alle denkbaren Szenarien ab, man muss sich damit aber aktiv beschäftigen, damit es richtig läuft. Für jemanden, der nicht einmal das Basis OS updaten will, eher die falsche Option.

Eine Lösung, die möglichst als Selbstläufer funktioniert ohne viel Wartungsaufwand wäre mittels borg-backup. Das nimmst du statt rsync für die lokale Mirror-HDD - die aktuelle Lösung ist sowieso fragwürdig (sind die Daten fehlerfrei? Welche Daten fehlen?). borg-backup wäre die bessere Lösung mit Checksummen und Versionierung, die beliebig konfigurierbar ist. Du kannst festlegen, dass borg-backup gelöschte und geänderte Dateien z.B. 1 Jahr behalten soll. Das hilft gegen Ransomware, als auch versehentliches Löschen durch Anwender. Da die Clients nur Zugriff auf dein Samba haben und nicht etwa auf die Spiegelfestplatte deines Servers, können die dein borg-backup nicht löschen.

Das schlimmste was mit borg-backup passieren kann, ist dass dein Storage überläuft, weil es wegen Ransomware soviele veränderte Dateien gibt, dass dein Storage nicht mehr ausreichend Speicher hat. Dann streikt der Server und du wirst so auf den Vorfall aufmerksam. Je nach Dateisystem kein Problem (z.B. ext4) oder totale Katastrophe (z.B. BTRFS).

Der Arbeitsrechner ein Haus weiter ist gleichzeitig dein Offline- (da nicht immer eingeschaltet) und Offsite-Backup. Das ist ausreichend. Etwas weniger komfortabel aber besser, wäre statt dem Arbeitsrechner eine externe Festplatte (da nicht permanent am Stromnetz), die du immer nur während des Backups am Rechner stecken hast. 8TB gibt's aktuell für 115€ bei MM. Kann man sich überlegen, muss man aber auch nicht.
 
Zuletzt bearbeitet:
Danke für Deinen Beitrag bzw. fürs Aufmerksammachen auf Borg-Backup. Ich werde ...
  • ... in einem 1. Schritt mal am Arbeitsrechner zuhause auf einer ohnedies hier herumliegenden 120 GB SSD Ubuntu aufsetzen, eine weitere 10 GB HDD bestellen + in den vorhandenen Wechselschacht schieben, ext4 formatieren + BackInTime installieren und den Server erst mal damit backupen (OS-Auswahl funzt eh per BIOS bzw. F11)
  • ... in einem 2. Schritt - dafür brauch' ich dann doch mehr Zeit (2. Lockdown oder Weihnachtsferien) - mich doch (wieder) in Centos versuchen + per Borg-Backup auf die als Mirror gedachte 2. HDD direkt im Server sichern.
Ich hatte ja schon mal den Server ein paar Jahre unter Centos laufen - bei der Einrichtung war's halt etwas schwieriger, v.a. weil die Doku und Community mehr englischsprachig ist. Beim letzten Aufsetzen von Debian hab' ich mir alles ganz genau (inklusive Screenshots) dokumentiert - nutzt halt unter Centos weniger. Ich denke aber, dass ich das hinkriegen werde (notfalls halt wieder mal wo fragen).

Thx
 
Zuletzt bearbeitet:
Sodala - hier ein kurzer Bericht:

Wenn du neu aufsetzt, dann mit CentOS 8. Damit hast du bis 2029 (EOL) Ruhe und kannst auf Cockpit setzen, ...

Server-neu unter CentOS läuft :-). Installation weitgehend problemlos - allerdings bin ich über ein paar Steine gestolpert:
  • Erst wollte CentOS nicht von der HDD booten - war ein BIOS-Problem (dass man die HDD-Bootreihenfolge manuell zuweisen muss und sich das Gerät nicht die 1. bootbare HDD schnappt, ist eigentlich Schnee von vorgestern...).
  • Dass Centos nun eine Firewall drin hat und die automatisch aktiviert ist - hat mich auch einige Zeit und Nerven gekostet (woher sollte ich wissen...).
  • Zoneminder war auch deutlich komplizierter zu installieren - früher bzw. unter Debian gab's ein Paket dafür.
Die Daten auf der notleidenden HDD konnte ich weitgehend runter kopieren - bis auf 22 Filme. Diese konnte ich (bis auf einen) von der gespiegelten HDD rekonstruieren.

Die neuen zwei 10 TB Iron Wolf sind (statt der zwei notleidenden 6 TB WD) eingebaut. Eine dritte wird in Zukunft übers Netz ein Backup auch der Videofilme in die Privatgemächer machen.

Der Großteil ist somit geschafft - ein paar Kleinigkeiten sind noch zu konfigurieren:
  • die Kameras im zm,
  • das Plattenspiegeln,
  • Überwachung der smart-Werte aller :sneaky: HDDs + Emailbenachrichtigung, wenn was schief liegt...
... also alles nicht mehr so wild. Und dann muss noch der Büro-PC der Göga umgebaut und neu unter Win10 aufgesetzt werden.

Danke für Eure Mithilfe
Oktavus
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh