stündlicher Datentransfer vom NAS ins RZ

sikarr

Vice Admiral
Registriert
Mai 2010
Beiträge
6.587
Hallo,

Es ist etwas kompliziert. Ich arbeite bei einer Digitalisierung wo laut Unternehmensrichtlinie die Daten ins RZ gesichert werden müssen. Wir haben eine Gigabit Direktleitung ins RZ. Wir müssen täglich um die 50-100gb an Daten übertragen, derzeit wollen wir das in einem 4h Rhythmus oder weniger.

Derzeit läuft auf unserer Synology ein Rsync Skript das aller 4h aufgerufen wird. die Daten ins RZ überträgt und die übertragenen Daten älter als 1h auf unserer Seite löscht.
Leider stimmt mit dem Skript was nicht und es kommen Dateidopplungen ins RZ oder 0kb Dateien, auch stimmt die Benennung nicht mehr evtl. kann hier einmal schauen wo in dem Skript der Fehler liegen könnte, ich bin mit Linux nicht so tief drin und auch fehlt mir die Zeit um mich tiefer damit zu befassen. Der Mensch der das Skript geschrieben hat, hat das unternehmen verlassen und steht nicht mehr zur Verfügung.

Die Quelle ist ein Synology Enterprise NAS und das Ziel eine SMB Freigabe auf einem Windows Server 2012 R2

Bash:
#!/bin/sh
 
# Variablen für die Aufgabe
log=/volume1/RZ/SMB-Freigabe/log/$(date +"%Y-%m-%d_%H-%M").log
# Logging der Ausgaben in das File $Log
exec 1>${log} 2>&1
 
# Ausführung des Filesync
rsync --exclude=/@eaDir/ -aurcv /volume4/Freigabe/ /volume1/RZ/SMB-Freigabe/ && \
# Suche und lösche Files älter als 59 Minuten. Vorgehend werden diese Dateien übertragen
find /volume4/Freigabe/ ! -path "/volume4/Freigabe/@*" -mmin +59 -type f -delete && \
# Suche und lösche Ordner die leer sind
find /volume4/Freigabe/ ! -path "/volume4/Freigabe/@*" -type d -empty -delete
 
# Deleting Logfile older than 14 days
find /volume1/RZ/SMB-Freigabe/log/ -mindepth 1 -type f -mtime +14 -delete

dieser Code erzeugt sowas auf dem Server im RZ,
1625668245306.jpeg

rauskommen sollte aber
und das auch nur einmal, die Datei gab es auch nur einmal auf dem Quell System.

Eigentlich bräuchten wir einen direkten Export der Daten ins RZ aber das wurde abgelehnt.

Hat jemand eine Idee wie wir z.B. einen Stündlichen Sync machen könnten und sicher sein können das die Übertragenen Daten korrekt sind?
 
Das schaut stark nach den Endungen aus, die rsync bei temporären Dateien anhängt. Erst nach abgeschlossenem Transfert werden sie umbenannt.

Hast du dir mal die checksummen angesehen?

gib rsync mal ein --append-verify mit :)
Isst es eine option rsync noch --delete mitzugeben, oder sollen am Ziel Daten existieren, die an der QUelle schon gelöscht sind?


Zusatz:
Bist du sicher, dass ihr einfach rsync auf einen gemounteten Samba Share nutzen wollt, um Backups für eine Firma zu machen?
Im Zweifelsfall ist ein Schreibbar gemountetes Backup Volume wenig sinnvoll
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Sulik
Wenn du schon logs hast, was steht denn da so drinnen?

Solche Fälle wie bei dir können z.B. auftreten, wenn die Quelldatei gelöscht, verschoben oder sonstwie nicht mehr verfügbar ist, während RSync läuft.
 
  • Gefällt mir
Reaktionen: madmax2010
Frage mich auch über die Sinnigkeit von Rsync mit Checksummenparameter um die Files dann in ein NTFS Dateisystem zu dumpen. Mein gut wegen bitrot muss man sich bei 4h Aufbewahrungszeit wohl keine Gedanken machen, aber ZFS ist imho schon pflicht heute.
 
  • Gefällt mir
Reaktionen: madmax2010
Das sind so typische Dinge, die man an Freelancer zum troubleshooten gibt. Kommerzielle Firma hat ein Problem und will jetzt ne kostenlose Lösung von Dritten. Ach ne, beim Fax-Weltmeister Deutschland darf "Digitalisierung" ja nix kosten, da war ja was^^

sikarr schrieb:
rsync [...] -aurcv
Das r ist doppelt/unnötig, da die Option -a bereits rlptgoD inkludiert.
Das v ist sinnvoll weil es mehr Logging produziert. Du hast einen Fehler und du hast ein Logfile und du möchtest Hilfe. Also her mit dem Logfile.
Wie @deveth0 es schon sagte: Solche temporären Dateien bleiben bestehen, wenn ein rsync Transfer unterbrochen wurde.

@Sulik Tellerrand und so. Bei großen Datenmengen oder begrenzt verfügbarer Bandbreite macht es absolut Sinn mit Checksummen zu arbeiten. Ansonsten würde rsync die Datei auch übertragen wenn sich die Änderungszeit geändert hat (Datei geöffnet, ein Zeichen gelöscht, Fehler bemerkt, identisches Zeichen wieder eingefügt, gespeichert). Vielleicht ist der Zielserver ja virtuell und liegt auf einem Storage mit Fehlererkennung und -behebung...
 
Zuletzt bearbeitet:
Wichtig können die Daten ja nicht sein.

Keine Verifizierung, dass die Dateien richtig übertragen sind bevor gelöscht wird...
Keine lokale Aufbewahrung...
Kein Backup...
Keinerlei Möglichkeit, dass das Skript sich meldet, falls etwas nicht funktioniert... (Logs in die niemand rein schaut zählen nicht)
 
  • Gefällt mir
Reaktionen: sikarr und madmax2010
@Rickmer Sehe ich nicht ganz sooo schlimm an. Das löschen der Daten erfolgt ja nur wenn rsync korrekt und vollständig durch lief (&& am Ende der Zeile).

@sikarr Wenn ihr das Skript per Cronjob aufruft, könnte es zum Problem werden wenn die vorherige Iteration auch noch läuft. Skript startet mittags um 12 und braucht 2h, nächster Aufruf um 16 Uhr braucht aber 5h. Blöd denn um 20 Uhr wird es erneut aufgerufen. Dann hast du zwei rsync laufen. Wenn dann der erste seit 16 Uhr laufende rsync durch ist werden Daten gelöscht, die der 20h rsync gerade noch synchronisieren will, Quelldatei ist aber nicht mehr da und so bleibt die temporäre Datei im Ziel bestehen.
 
  • Gefällt mir
Reaktionen: Skysnake und sikarr
danke erstmal an euch, ja über die Sinnhaftigkeit wie es gemacht wurde muss ich auch Kopf schütteln aber das war ein Staatsakt das die es so gemacht haben.

Wir sind hinter 3 Firewalls aufgestellt, direkt Leitung ins RZ, also Physisch LWL. Aber FW Änderungen brauchen Monate bist sie umgesetzt sind, fragt nicht warum.

Es existiert derzeit nur eine Route vom NAS ins RZ, d.h.. das NAS muss die Übertragung anstoßen.


madmax2010 schrieb:
oder sollen am Ziel Daten existieren, die an der QUelle schon gelöscht sind?
Genau, wir schieben ins RZ und dann sollen die Übertragenen Files gelöscht werden.

madmax2010 schrieb:
Zusatz:
Bist du sicher, dass ihr einfach rsync auf einen gemounteten samba share wirkloch nutzen wollt um Backups für eine Firma zu machen?
Im zweifelsfall ist ein schreibbar gemountetes backuo wenig sinnvoll
Das System im RZ wird regelmäßig gebackuped und dann bis zu 52 Wochen aufgehoben. Auch ist das nicht einfach eine Ablage, von dort werden die Files z.B. zum signieren gesendet oder auf die Kundenportale verteilt.

Sulik schrieb:
aber ZFS ist imho schon pflicht heute.
das Quellsystem ist BTRFS und im RZ ist es eine Nutanix Lösung

Rickmer schrieb:
Wichtig können die Daten ja nicht sein.
Doch sogar sehr.

Rickmer schrieb:
Keine Verifizierung, dass die Dateien richtig übertragen sind bevor gelöscht wird...
Ich dachte genau das ist der Vorteil von rsync, sonst könnte ich ja einfach einen MOVE machen?

Rickmer schrieb:
Keine lokale Aufbewahrung...
Kein Backup...
Doch, die Files die Übertragen werden sind in ihrer Rohform noch bei uns vorhanden um sie im Zweifel neu erzeugen zu können. Aber bei vielen Sachen macht einem der Datenschutz und die TOMs einen Strich durch die Rechnung. Wir dürfen nicht einfach alles aufbewahren.

Rickmer schrieb:
Keinerlei Möglichkeit, dass das Skript sich meldet, falls etwas nicht funktioniert... (Logs in die niemand rein schaut zählen nicht)
bin ich bei dir, deswegen such ich auch nach auswegen, Ihr habt keine Ahnung wie es noch vor 3 Monaten war.

In den logs steht sowas:
sending incremental file list
./

sent 29 bytes received 15 bytes 88.00 bytes/sec
total size is 0 speedup is 0.00
das den Cronjob habe ich nach dem 1. Tag und der Geschichte gestoppt, derzeit transferieren wir manuell.
 
Zuletzt bearbeitet: (LOG File angehangen)
Ich muss zugeben, rsync kenne ich nicht wirklich. Dann ist wohl nicht ganz so schlimm wie befürchtet.

Ansonsten hätte ich noch die Anmerkung - ein Synology NAS ist kein System, auf dem 'sehr wichtige' Daten was zu suchen haben. Stichpunkt Serviceverträge - Synology hat keine. Wenn da was kaputt geht, kann das Wochen dauern...
 
snaxilian schrieb:
@sikarr Wenn ihr das Skript per Cronjob aufruft, könnte es zum Problem werden wenn die vorherige Iteration auch noch läuft. Skript startet mittags um 12 und braucht 2h, nächster Aufruf um 16 Uhr braucht aber 5h. Blöd denn um 20 Uhr wird es erneut aufgerufen. Dann hast du zwei rsync laufen. Wenn dann der erste seit 16 Uhr laufende rsync durch ist werden Daten gelöscht, die der 20h rsync gerade noch synchronisieren will, Quelldatei ist aber nicht mehr da und so bleibt die temporäre Datei im Ziel bestehen.
kann man sowas wie bei der Aufgabenplannung von Windows ausschliessen lassen? Aber das könnte die doppelten Dateien erklären.
 
sikarr schrieb:
Ich dachte genau das ist der Vorteil von rsync, sonst könnte ich ja einfach einen MOVE machen?
Jain.
Mit rsync -c wird beim Start von Quelle und Ziel eine Checksumme erstellt und bei Unterschied wird die Datei übertragen. Rsync stellt nur sicher, dass die Daten korrekt beim Zielsystem ankommen, vereinfacht gesagt im RAM. Wenn das Zielsystem beim schreiben auf das Dateisystem dann "Blödsinn" macht, kann rsync nicht prüfen.
sikarr schrieb:
kann man sowas wie bei der Aufgabenplannung von Windows ausschliessen lassen? Aber das könnte die doppelten Dateien erklären.
Ja kann man und es gibt mehrere Ansätze.
Du könntest am Anfang prüfen ob eine lock Datei vorhanden ist. Wenn ja, höre auf und beende dich. Falls nein, lege eine lock Datei an und am Ende des Skripts löscht du die lock Datei wieder.
Oder du überprüfst am Anfang des Skripts ob bereits ein rsync Prozess läuft und falls ja, breche ab. Ist aber eher die Holzhammermethode weil du da annimmst, dass es keinerlei andere rsync Skripte und Prozesse gibt...

Wäre das NAS keine Appliance sondern ein vollwertiges Linux und falls man ein brauchbares Monitoring hätte, könnte man auch prüfen lassen ob cronjobs erfolgreich waren oder nicht.
 
Rickmer schrieb:
ein Synology NAS ist kein System, auf dem 'sehr wichtige' Daten was zu suchen haben. Stichpunkt Serviceverträge - Synology hat keine. Wenn da was kaputt geht, kann das Wochen dauern...
Deswegen sollen die Daten ins RZ, wir heben sie nur solange auf dem NAS auf bis sie der Kunde abgenommen hat, dann werden sie gelöscht.

Und um den Austausch mach ich mir keine Sorgen, jemand im Vorstand wollte das so also müssen die damit auch leben, drauf hingewiesen haben wir sie.

Problem ist das wir stark an unseren Mutterkonzern gebunden sind und der Vorstand uns so als sein Privatprojekt ansieht. Als uns die IT hingestellt wurde war eigentlich alles anders geplant, und man redet oft gegen Wände, aber das ist eine andere Baustelle.
 
sikarr schrieb:
Und um den Austausch mach ich mir keine Sorgen, jemand im Vorstand wollte das so also müssen die damit auch leben, drauf hingewiesen haben wir sie.
Als jemand der in einem Systemhaus mit einer Viezahl verschiedener Kundenumgebungen arbeitet - das kenne ich nur zu gut...
 
snaxilian schrieb:
Wäre das NAS keine Appliance sondern ein vollwertiges Linux und falls man ein brauchbares Monitoring hätte, könnte man auch prüfen lassen ob cronjobs erfolgreich waren oder nicht.
Ich fasse zusammen, ein anderes System sollte sich um den Transfer kümmern, sehe ich genauso. entsprechende Tickets sind schon gestellt aber das kann Monate dauern, und eskalieren hilft nicht, das sind die schon gewohnt und ignorieren es weiter bis zur nächsten Vollversammlung oder Tüv Audit.

Ich danke allen soweit erstmal.
 
Naja muss nicht unbedingt etwas anderes werden. Wenn kein Knowhow vorhanden ist, bringt auch ein Linuxserver nix wo man mehr machen könnte aber niemand da ist um dieses mehr zu machen.

Im Zweifel muss man halt mit dem arbeiten was man hat. Wenn die Daten so wichtig sind würde ich mir überlegen ob man von dem selbst geschriebenen Skript weg geht was ja offenbar keiner warten/pflegen kann.
Synology selbst kann Cronjobs per WebGui einrichten und es lassen sich auch andere Trigger außer der Uhrzeit einstellen. Erster Task wäre dann der Sync und die darauf folgenden die um die Daten und leeren Ordner zu löschen. Vorteil dabei: Die Synology bietet direkt an, Mails zu versenden wenn etwas nicht klappt. Also das "arme-Leute-und-Systemhaus-Monitoring" wie ich es noch selbst aus der Ausbildung kannte^^
Das wäre zumindest ein Ansatz, den ich verfolgen würde. Alternativ die Daten per Hyper Backup weg schieben und das Hyper Backup als Trigger für den Aufräum-Task verwenden.

Wenn Zeit oder Wissen Mangelware ist, sind Selbstbaulösungen gefährlich. Nutzt wo immer es geht nicht angepasste oder individualisierte Standardsoftware, Standardwerkzeuge, keine Sonderbehandlungen und wenn doch klärt ab, dass diese ein Risiko darstellen und Betrieb davon nur Probleme bereitet.
Wobei... Sonderlösungen erzeugen auch bei größeren Firmen und Konzernen Probleme wenn diese abgelöst oder migriert werden müssen und man zwar den alten Kram irgendwie betreiben kann aber die ursprünglichen Admins und Entwickler nicht mehr da sind :freak:
Solche technischen Schulden aufzubauen dauert halt oft nur einen oder zwei Sprints (oder Monate in der nicht-agilen Welt), der Abbau aber oft mehrere Monate.
sikarr schrieb:
Tickets sind schon gestellt aber das kann Monate dauern, und eskalieren hilft nicht, das sind die schon gewohnt und ignorieren es weiter
Der Trick ist, so etwas nicht persönlich zu nehmen ;) Melden (schriftlich) macht frei und belastet den Vorgesetzten. Wenn "von oben" keine Antwort kommt oder nicht entsprechend umgesetzt werden soll dann ist das so, lässt den Teil der IT halt weiter verrotten und nimmt sich der nächsten Baustelle an bis man irgendwann einmal rum ist und wieder bei dem Problem landet oder man akzeptiert, dass die eingebrachte Hilfe und Engagement nicht erwünscht ist und zieht weiter. Anderswo soll es auch Computer geben ist das Schöne an diesem Job.
Bei IT-Dienstleistern/Systemhaus ist das nicht soo schlimm solange es genug vernünftige Kunden gibt aber wenn man inhouse ist und IT nur noch reaktiv betreibt und der Admin mehr digitale Feuerwehr spielt, hilft nur noch rennen.
 
snaxilian schrieb:
Der Trick ist, so etwas nicht persönlich zu nehmen ;) Melden (schriftlich) macht frei und belastet den Vorgesetzten.
Ich nehm das nicht persönlich, aber stell dir eine Fleischerei vor die sich denkt "wenn wir schon die Wurst machen dann können wir auch gleich die Brötchen dazu backen" und bauen eine Bäckerei auf und versuchen die als Fleischerei zu betreiben.

Da wir ein Tochterunternehmen sind müssen wir unseren Bedarf wie jeder Kunde der Mutter per Ticket anmelden. Nur bearbeiten die unsere Tickets unglaublich spät, weil wir ja ein Tochterunternehmen sind und kein zahlender Kunde.

Und zum Thema Vorgesetzten belasten, die GF hat ja beim Vorstand diesen Missstand schon mehrfach angemahnt. Dann kommt als Antwort nur "dann müsst ihr das eskalieren". Da dreht man sich im Kreis.
 
So etwas brauche ich mir nicht vorstellen, so etwas kenne ich aus persönlicher Erfahrung und aufgrund dieser Erfahrung habe ich Dinge "eskaliert" also per Ticket oder wie auch immer dies gewünscht war gemeldet inklusive Information was passieren kann wenn dies nicht umgesetzt wird. Wenn sich dazu entschieden wurde das Risiko zu tragen ist es nicht länger mein Problem und hab im Schadensfall darauf verwiesen.

Du wirst so ein Unternehmen nicht zur Besserung bewegen können also entwickelt man entweder Spaß daran reaktive Feuerwehr-IT zu sein oder sucht sich eben eine stabilere Umgebung, z.B. wo man durch entsprechende Regularien seine IT halbwegs stabil betreiben muss. Da ist auch bei weitem nicht alles Gold was glänzt aber wenn man Pfusch am digitalen Bau findet oder sieht, wird es entweder angegangen oder jemand weiter oben trägt das Risiko dafür. In dem Fall bekommt auch kein Admin einen auf den Deckel wenn es dann doch kracht.
Dafür kann man eben nicht mal eben hier und da was ausprobieren oder mal schnell machen, zumindest nicht in der Prod Umgebung sondern nur in dev/test. Hat definitiv beides seine Vor- und Nachteile.
 
Zurück
Oben