ich nutze zfs als Dateisystem. FĂŒr Nextcloud und die dazugehörige Postgres Datenbank gibt es ein eigene Dataset, fĂŒr die alle 15 Minuten ein Snapshot gezogen und auf einen Backup Server repliziert wird.
Wenn man im ZFS eine Datei verĂ€ndert oder löscht, wird ja bekanntlich eine neue Datei erzeugt (ist etwas vereinfacht dargestellt âŠ).
Das fĂŒhrt nun dazu, das gelöschte Dateien im Dateisystem so lange erhalten bleiben, bis alles Snapshots, die darauf zeigen ebenfalls gelöscht werden.
Also selbst wenn Nextcloud die Datei löscht, bleibt sie im Dateisystem nahezu bis zum sankt nimmerleins Tag erhalten.
Es wĂ€re also hilfreich, wenn man den Ordner fĂŒr gelöschte Dateien irgendwo auĂerhalb des Standard Pfades anlegen könnte.
Ich habe aber keine Konfigurationsmöglichkeit fĂŒr den Pfad gefunden.
Geht das irgendwie?
Ansonsten bleibt nur ĂŒbrig die komplette App zu deinstallieren âŠ
VG
Ich denke du meist den Standard-Papierkorb bei Nextcloud, der je Benutzer unter /pfad/zur/nextcloud/data/benutzername/files_trashbin liegt.
Ich denke du hast einen Denkfehler. Der Papierkorb von Nextcloud sind eigentlich streng genommen keine gelöschten Dateien. Sie gehören immer noch der Nextcloud an und können vom Benutzer wiederhergestellt werden. Diese Datenmenge musst du einfach als normalen Speicherbereich mit einplanen und auch gemÀà deiner Backup-Strategie sichern. Durch wie beschrieben inkrementelle Sicherungen hast du jede Datei praktisch nur einmal gesichert.
Du kannst einige Einstellungen am Papierkorb vornehmen. Schau z. B. hier.
Im ĂŒbrigen wĂŒrdest du mit deine Idee dein Problem nicht lösen, da du weiterhin die Dateien fĂŒr die korrekte Funktionsweise des Papierkorbs benötigst. In deiner Denkweise könntest du den Papierkorb einfach deaktivieren. Damit wĂ€ren die Dateien nicht auf einer anderen Platte, sondern direkt weg.
Das Problem ist hier, das Nextcloud praktisch gar nicht mit modernen Dateisystemen, wie ZFS oder BTRFS zusammenarbeitetâŠ
Dort werden Ănderungen an Dateien nĂ€mlich nicht in Form einer neuen Datei angelegt, sondern nur die tatsĂ€chlich verĂ€nderten Blöcke in der Datei neu gespeichert.
Demenstsprechend werden bei einem Diff Backup auch nicht geÀnderte Dateien, sondern nur geÀnderte Datenblöcke und Notwendigen Informationen dazu gespeichert.
Die verschiedenen Versionen von Dateien werden in Form der Meta-Informationen ĂŒber Snapshots gespeichert.
Das Dateisystem bringt also eine eigene systeminterne Versionierung mit, auf die Nextcloud aber nicht zugreift.
FĂŒr den Anwender bleibt das Alles im Hintergrund verborgen, da die Snapshots im Dateisystem z.B. bei ZFS innerhalb eines nicht sichtbaren Ordners .zfs liegen.
Wenn im Dateisystem nicht gerade die CPU und speicherhungrige Deduplizierung eingeschaltet ist, hebelt Nextcloud das alles vollstÀndig aus, da hier immer neue Dateien (Versionen) gespeichert werden.
Wenn man jetzt den Papierkorb in Nextcloud leert, sind die Daten zwar in Nextcloud nicht mehr sichtbar, aber im Dateisystem bleiben sie vorhanden.
Man kann sie dort auch nicht löschen, wenn man z.B. einen alten Snapshot behalten möchte in dem sie mal enthalten waren.
Erst wenn man alle Snaphshots löscht, dann werden die Daten physisch gelöscht.
Das gleiche Problem tritt ĂŒbrigens auch bei der Versionierung auf, da auch diese nicht mit ZFS Features umgehen kann.
Es ist auch nicht möglich im nextcloud Datenverzeichnis den Ordner files_trashbin ĂŒber einen Link auf eine andere Platte zu verlagen. Dann gibts Mopper
Alles in Allem gibt es nur eine Lösung.
Sowohl die interne Versionierung, als auch den Papierkorb vollstÀndig abschalten.
Eine Umstellung auf ein einfaches Dateisystem wie z.B. ext2 kommt auch nicht in Frage, da die hier anfallenden Datenmengen bei einem Diff um ein Vielfaches gröĂer sind als bei ZFS und die Daten mit einem remoten Server ĂŒber eine normale DSL Leitung nicht mehr syncron gehalten werden können.
Beispiel: in einer 500MB groĂen Datei wird nur ein Buchstabe geĂ€ndert.
ext2 â es werden ca. 500MB ĂŒbertragen
ZFS â es wird ein Block (ĂŒblicherweise 4k oder 8k) + Steuerinformation ĂŒbertragen â max. 16kb
Im Dateisystem von Nextcloud /pfad/zur/nextcloud/data/benutzername/files_trashbin werden sie gelöscht. Im nĂ€chsten Backup sollten sie fehlen. Und natĂŒrlich sind die Inhalte immer noch in deinen alten Backup-Generationen, denn das ist ja das Ziel deines Backups. Das ist bei meinen inkrementellen Backups bei ext genauso. Die Datenmenge ist aber gering, da sich prozentual ĂŒber die Generationen eigentlich sehr wenig Dateien ĂŒberhaupt Ă€ndern.
Wie geschrieben musst du meiner Meinung nach den Papierkorb als eine ganz normale Verzeichnisstruktur von Nextcloud ansehen. Wenn du lieber im Fehlerfall die Daten aus deinen ZFS-Backups raussuchen willst, dann kannst du natĂŒrlich den Papierkorb auch deaktivieren. Problematisch ist das jedoch bei Dateien, die am gleichen Tag angelegt und versehentlich gelöscht wurden und somit noch kein Backup existiert.
Genau das ist nicht der Fall, wenn im Dateisystem eine Snapshot Funktion verwendet wird !
Bei ext ist das richtig, Aber ext ist ein Relikt aus dem letzten jahrtausend und hat praktisch gar nichts mit modernen Dateisystemen wie BTRFS oder ZFS zu tun.
So bietet ext z.B. keine DatenintegritĂ€t fĂŒr den Fall, das ein bit auf der Platte kippt. Auch dann nicht, wenn man es im Software oder Hardware RAID betreibt.
Deswegen setzen viele Firmen ja auf ZFS.
Ich habe jetzt âdeleted filesâ und âversionsâ deaktiviert. Und die ZFS Snapshot Frequenz auf 5 Minuten erhöht.
Alle 60 Minuten wird ein â60-Minuten Snapshotâ erstellt und alle â5 Minuten Snapshotsâ die Ă€lter als 120 Minuten sind entsorgt.
Einmal in der Woche wird ein âWochen-Snapshotâ erstellt und alle â60 Minuten Snapshotsâ die Ă€lter als 2 Wochen sind entsorgt.
Das funktioniert ganz einfach ĂŒber Dateisystem interne Services ( 3 config Zeilen ) und kostet praktisch keinen Plattenplatz.
Und ich kann online auf ALLE alten Versionen zugreifen, ohne irgendein Backup durchsuchen zu mĂŒssen.
SelbstverstĂ€ndlich liegen auch meine Backupâs in diversen ZFS Pools.
Somit sind die gleichen Funktionen gegeben, wenn ich ein Backup Plattenset einsetze.
Der Haken: In Nextcloud sieht man davon nichts, weil die Apps eigene Mechanismen implementieren und damit die im Dateisystem bereitstehenden Features aushebeln.
Das ist besonders dumm, weil man z.B. auch als Vermieter die DSGVO einhalten muss. Und das bedeutet eben auch, das z.B. Unterlagen von Mietbewerbern zuverlĂ€ssig gelöscht werden mĂŒssen. Auch in Backupâs!
Insofern arbeiten die Apps nicht DSGVO konform, wenn bestimmte Dateisysteme/Features eingesetzt werden!
In diesen FĂ€llen muss man nĂ€mlich die Backups auf eine eigene Platte zurĂŒckspielen und alles hĂ€ndisch bereinigen. Dumm ist nur, das man nicht weiĂ, was die Apps im Hintergrund so getrieben habenâŠ
Und von dieser bereinigten Version kann man dann ein neues Backup erstellen, welches das alte Backup ersetzt â Katastrophe.
wenn man lieber direkt im Dateisystem rumfummelt und damit integrierte Funktionen aktiv aushebelt:
kann man das schon machenâŠ
ich sehe nicht inwiefern deine Snapshot Strategie das Problem adressiert! alte Files und Versionen bleiben in Snapshots weiter enthalten⊠Dagegen könntest du mit NC Bordmitteln mehrere Wege finden das Problem zu adressieren: z.B. Gruppenordner oder dedizierte Benutzeraccounts mit entsprechend konfigurierten Quotas/Retention PoliciesâŠ
Ich bin kein Anwalt, aber ich bin sehr sicher dass niemand durch die DSGVO gezwungen wird bestimmte Daten aus Backups (manuell) zu löschen (ist ja auch widersinnig - ein Backup ist nur dann ein solches wenn es ein Systemzustand zum bestimmten Zeitpunkt vollstĂ€ndig restauriert)⊠Man sollte (und braucht) die Backups nicht âewigâ behalten - ein Backup dient hauptsĂ€chlich dazu ein System im Fehlerfall wiederherzustellen - das ist bei Archivierung anders - hier man muss bestimmte Daten lĂ€nger als andere vorhalten - die Daten sollen ausserdem (hĂ€ufig) unwerĂ€nderbar sein - Archivierung ist aber nicht der Einsatzzweck von Nextcloud - hier sollen âaktiveâ Daten abgelegt werden.
Ăbrigens ist der Prozess âDaten Löschenâ eine Datenverarbeitung im Sinne der DSGVO - wenn du deine Mietunterlagen gezielt aus dem Backup/Snapshot raussuchst kann das schlechter sein als die Backups irgendwann komplett zu löschen.
Es tut mir leid. Aber ich habe es immer noch nicht verstanden. NatĂŒrlich wird ein Snapshot den Nextcloud-Papierkorb und auch alle Nextcloud-Versionen von Dateien enthalten. Aber diese sind aus Sicht von Nextcloud ja auch noch nicht weg. Aber irgendwann werden Versionen und auch der Papierkorb in Nextcloud gelöscht. Dann sind sie nicht mehr im aktuellen Dateisystem. Dann mĂŒssten sie doch auch mit der Zeit aus den Snapshots verschwinden, da du ja irgendwann den Ă€ltesten Snapshot auch mal löscht, der die letzte Version enthalten hatte, oder?
@fow0ryl
Kannst du das noch mal erklĂ€ren. Wann sind die Daten wirklich weg? Wie alt ist das Ă€lteste Backup (Erstelldatum)? Und natĂŒrlich enthĂ€lt dieses Ă€lteste Backup die gesamte Nextcloud-Struktur inkl. Papierkorb und Versionen, da diese zum damaligen Zeitpunkt zum System gehörten, wiederherstellbar waren und nicht gelöscht waren. Es waren aktive, ungelöschte Daten des Anwenders meiner Meinung nach aus Sicht von DSGVO.
Das passt soweit.
SchlieĂlich sind alle von Nextcloud erstellten Dateien, bzw. Versionen eine Dokumentes eigenstĂ€ndige Dateien.
Das stimmt fĂŒr Dateisysteme wie ext* oder auch vfat.
Der auf der Platte physisch belegte Platz wird zwar nicht neu initialisiert aber alle Zeiger auf diese Datei werden entfernt und der frei gewordene Platz wird wieder verwendet.
FĂŒr Dateisysteme wie ZFS stimmt das nur bedingt.
Unter der Annahme das irgendwann ein initialer Snapshot â1â gezogen wurde. Und nachdem eine Datei von Nextcloud in den Papierkorb gelegt wurde, wurden neue Snapshots â2â und â3â gezogen. Danach wird die Datei in Nextcloud gelöscht.
AnschlieĂend wird ein Snapshot â4â gezogen.
Da ZFS ein COW Dateisystem ist, bei dem jede gelöschte Datei im Dateisystem erhalten bleibt, solange irgendwo die Datei referenziert wird, bleibt die Datei so lange erhalten, bis irgendwann die Snapshots â2â und â3â gelöscht werden.
Doch genau das macht man bei ZFS so gut wie nie. SchlieĂlich dienen die Snapshots ja nicht nur dazu auf einen beliebigen Stand zurĂŒckzurollen oder ein System auf Basis diese Snapshots wieder neu aufzusetzen.
Wenn ich den letzten Snapshot als Backup einspiele, sind automatisch alle davor erstellten Snapshots wieder da !
Die Snapshots stellen ja gleichzeitig eine Archivierung/Versionierung von beliebig vielen ZwischenstÀnden dar.
SchlieĂlich beansprucht ein Snapshot kaum Platz auf der Platte, da ja nur die Blöcke enthalten sind, die sich gegenĂŒber einer vorherigen Dateiversion geĂ€ndert haben.
Ich habe hier auf meinem Server mehrere hundert Snapshots liegen. Die Àltesten sind knapp 9 Jahre alt.
Die Snapshots enthalten ja nicht nur Daten der Nextcloud Instanz. Beim Löschen eines Snapshots ist daher besondere Vorsicht geboten.
Wenn man nachdem z.B der Snapshot â2â erstellt wurde, die Daten auf eine Backup Platte syncronisiert dann ist die gelöschte Datei natĂŒrlich auch dort enthalten. Erst nachdem Snapshot â2â und â3â gelöscht wurden und alle Backup Platten neu syncronisiert wurden, ist die Datei tatsĂ€chlich weg.
Das Ziehen der Snapshots passiert ĂŒbrigens nicht in dem Container, in dem Nextcloud lĂ€uft. Es passiert in der darunter liegenden Virtualisierungsschicht.
(Bei mir frĂŒher XEN/XCP-NG, heute Proxmox)
Leider kenne ich mich mit ZFS nicht aus. Aber mĂŒsste die Problematik nicht auch bei Windows 10 und dem dort aufgefĂŒhrten Papierkorb existieren? Oder anders gefragt: Wie gehen andere Anwendungen mit dem Problem um?
Insgesamt sehe ich jedoch sowohl das ZFS- als auch das Nextcloud-Verhalten als korrekt an. Die Dateien im Nextcloud-Papierkorb sollen bei RĂŒckspielung irgendeiner Sicherung ja auch noch existieren, da man ja den Stand der Sicherung in jedem Punkt wiederherstellen möchte. Und zum Zeitpunkt der Sicherung waren die Daten im Papierkorb und damit im Zugriff von Nextcloud. Gleiches gilt fĂŒr die Nextcloud-Versionen.
Die Frage ist eher, ob du den Papierkorb benötigst. Vielleicht kannst du es von Nextcloud erzwingen, dass vor dem Backup alle Papierkörbe gelöscht werden. Deinen Anwender sagst du dann Backup in der Nacht und die Papierkörbe werden kurz vorher gelöscht.
Man kann wohl alle Papierkörbe löschen. Vielleicht eine Option vor dem Backup.
Wenn du tĂ€glich sicherst bedeutet das aber, dass Dateien mit Datum vom aktuellen Tag, die in den Papierkorb gewandert sind, unwiederbringlich verloren sind. Bei Ă€lteren Dateien hast du ja deine ZFS-Sicherungen der einzelnen Tage, deren Restore jedoch mehr Aufwand benötigt als die Verwendung des Nextcloud-Papierkorbes. Der Nextcloud-Papierkorb ist eher fĂŒr den Tag selbst dann geeignet. Morgens gelöscht und nachmittags wiederhergestellt.
Ganz deaktivieren wĂŒrde ich den Papierkorb nicht. DafĂŒr ist die Funktion einfach zu gut.
Das Problem ist mehr oder weniger dass @fow0ryl erwartet die Applikation sollte sich mit Implementierungsdtails der Infrastruktur beschĂ€ftigen und darauf reagieren⊠In etwa so dass ich ein Haus baue und dann mein Haus sich darauf einstellt wenn spĂ€ter ein Autobahntunnel unter dem Haus gebaut wirdâŠ
Der Punkt ist (jede) Applikation hat keine Information, dass das Dateisystem Snapshots (Versionen/Journal/Parity usw) erstellt. Die Applikation Nextcloud verwaltet ein abstraktes Dateisystem (ĂŒber Systemschnittstellen) in dem Dateien erstellt, modifiziert und gelöscht werden können⊠sie kĂŒmmert sich nicht darum dass die Datei nach dem Löschen im Dateisystem(snapshot) noch exsiteren kann⊠sicher könnte die Applikation unterschiedliche Dateisysteme berĂŒcksichtigen⊠aber das fĂŒhrt die Abstraktion durch die Applikation ad absurdum - sofort könnte man argumentieren âdie Applikation soll mein RAID erkennen, und darauf reagieren wenn im RAID Platten kaputt gehen/erweitert werdenâ, weitere Technologoienen wollen ihre Specs berĂŒcksichtigt haben: Docker, Snap, Flatpack, Hyper-V, ESX uswâŠ
Das ist die Aufgabe des Admins, verfĂŒgbare Technologien so zu kombinieren, dass sie optimal fĂŒr den den Einsatzzweck eingestzt werdenâŠ
Wir haben eine relativ klare Dokumentation von Versionen und Trashbin in Nextcloud mit Kriterien wann die Daten aus SIcht der Applikation gelöscht werden (oder sollte die Nextcloud auch dafĂŒr sorgen dass deine Backups auf Bandlaufwerken gelöscht werden?) Wenn der Admin ein Dateisystem oder Backup Verfahren auswĂ€hlt das weitere oder zusĂ€tzliche Datenkopien vorhĂ€lt, ist es die Aufgabe des Admin diese Mechanismen nach geltendem Recht (DSGVO/GDPR) zu gestaltenâŠ
aber nicht die âdanachâ! die Snapshots der COW Dateisysteme sind eine âKetteâ: man kann nicht beliebig zwischen Snapshots âwandernâ - mann kann auf einem Zeitstrahl zu einem Zeitpunkt zurĂŒckkehren - und von diesem Zeitpunkt beginnen das Dateisystem neu zu gestalten - das geht aber nur einmal - ich kann keinen âBaumâ ausgehen vom Zeitpunkt X bauen⊠d.h. man âspielt den Snapshotâ nicht ein sondern man revidiert (roll back) Ă€nderungen seit diesem Snapshot X - d.h. mehr oder weniger reist man zurĂŒck in die ZeitâŠund beginnt von diesem Zeitpunkt eine neu Version/Dimension - diese Version ist aber nicht âalternativâ sondern absolut - man kann ab dann nur noch die âneuenâ Snapshots nutzen - die âaltenâ Snapshots nach dem Restore Zeitpunkt erstellt wurden sind nicht mehr verfĂŒgbarâŠ
Beide Anwendungen Trashbin der Nextcloud und Snapshots von ZFS haben erfĂŒllen ihren Zweck und sich sinnvoll. Aber man sollte als Admin die Vor-/Nachteile analysieren und sinnvoll einsetzen.
Er meint warscheinlich den Windows Shadow Copy Support in ZFS via SMB. Wenn du das aktivierst mountet Windows bei SMB mounts automatisch den snapshots ordner in /<dataset>/<pool name>/.zfs und du kannst, im Tab âVorgĂ€ngerversionen wiederherstellenâ eine frĂŒhere Version der Datei wiederherstellen. Die Dateien werden dann aus den Snapshots kopiert. Es findet kein Rollback statt. Meines Wissens nach ist aber Windows in Verbindung mit SMB das einzige OS oder das einzige Programm, welches diese Funktion irgendwie im UI abbildet. Unter Linux oder BSD kannst du aber einzelne Dateien manuell im Ordner .../.zfs/snapshots suchen und zurĂŒckkopieren.
Das ist richtig. Man kann aber Snapshots clonen. Dann bleibt die âalteâ Kette erhalten.
Den Vergleich verstehe ich nicht. Wer ist das Haus? Nextcloud? und wer die Autobahn? Dateisystem?
Dann war in meinem Falle die Autobahn zuerst daâŠ
Anders herum wĂŒrde es besser passen. Nextcloud (der Autobahntunnel) untergrĂ€bt das Haus. Und niemand im Haus bemerkt, das es einstĂŒrzen könnte.
Na ja, es ist ja gerade der Sinn einer Abstraktionsschicht das man sich nicht mit den Interna des darunter liegenden Systems beschÀftigen muss.
Das heiĂt aber nicht, das man nur den kleinsten gemeinsamen Nenner verwenden darf. Vielmehr können die Mechanismen unterschiedlich implementiert sein und trotzdem ein gemeinsamer Stand nach auĂen dargestellt werden.
Wenn Nextcloud keine Info ĂŒber Snapshots hat, dann taugt die verwendete Schnittstelle nichts. SchlieĂlich kann man das ganz einfach abfragenâŠ
Klar, wenn man ein Rollback macht, landet man auf einem Stand, der genau diesen Zeitpunkt widerspiegelt.
Aber. Man kann jederzeit - also ohne Rollback - in die Snapshtos schauen und sich einen alten Stand aus einem Snapshot herauskopieren und damit wieder herstellen. SchlieĂlich sind Snapshots nur Ordner in einem speziellen verstecken Verzeichnis.
Bei ZFS ist das der Ordner .zfs der pro Dataset existiert und den man auf Wunsch auch sichtbar machen kann. Damit hat dann jeder Anwender die Möglichkeit beliebig in der Historie zu graben.
Nextcloud interagiert aber nicht direkt mit dem Filessystem.
Naja wenn das so einfach wĂ€re, hĂ€tte das bestimmt schon jemand gemacht. Ich denke aber dass es warscheinlicher ist, dass man die schon bestehenden Funktionenen auf Applikationseende weiter verfeinert, bevor man direkte UnterstĂŒtzung fĂŒr diverse Filessysteme integreiert. Nextcloud ist nicht so designt, dass man direkt auf Filessystemebene mit den Dateien ineragiert, ganz unabhĂ€ngig vom verwendeten Filessystem. Auch auf einem simplen ext4 Filessystem musst du jedesmal einen occ:files:scan durchfĂŒhren, wenn du Dateien direkt auf Filessystemebene hinzufĂŒgst oder entfernst.
Es wĂ€re sicher auch jetzt schon möglich, diesen Ordner irgendwie via External Storage App zu mounten und dann via Nextcloud UI darauf zuzugreifen. In einer Multiuserumgebung aber wohl nicht wirklich paraktikabel. Wenn nur du die Nextcloud nutzt oder fĂŒr einen Admin aber evtl. schon. Ich wĂŒrde aber nicht irgendwelche Dateissystemfolder mit root Rechten in mein WebUI mounten wollenâŠ
Das ist schon traurig genug âŠ
Ich gehe mal davon aus, das praktisch alle Dateisysteme Infos darĂŒber ausspucken, das sich in einem Pfad etwas geĂ€ndert hat.
Unter Linux funktioniert das definitv mit ZFS, btrfs, ext2/3/4. Und sogar unter Windows habe ich bei ntfs schon mit den âFile Change eventsâ gearbeitet.
Das ist also nichts exotisches.
Unter Linux nutze ich das konkret in folgenden Fall:
Auf einem Netzwerk MultifunktionsgerĂ€t wird ein Dokument gescannt. Das wird vom Drucker per sftp auf den Server geschoben. Dort fange ich den Event ab. Damit wird ein script getriggert, die gescannte PDF Datei durch die Texterkennung scheucht, danach wird das mit Text erweiterte Dokument in den Nextcloud Ordner verschoben. Damit es fĂŒr den Anwender sichtbar wird, wird noch der occ File Scan ausfĂŒhrt.
Da stimme ich zu.
Aber die versteckten Snapshot Ordner liegen in der Dateistruktur unterhalb des Nextcloud Wurzelverzeichnisses und haben damit dieselben Datei-Rechte wie das Original, sind also vom Webserver aus ohne weiteres verarbeitbar.
Auch hier muss man natĂŒrlich vorher mit occ nachgeholfen werden, damit die Daten in Nextcloud sichtbar sind.
Die User spezifischen Rechte sind natĂŒrlich nicht da, weil Nextcloud die ja nicht ĂŒber das Dateisystem verwaltet! Mit diesem Konstrukt sollte man also vorsichtig sein âŠ
wenn du das richtig machst, und zB den scan zB ĂŒber WebDAV hochlĂ€dst oder in einen NC Client Ordner verschiebst, ist es ohne occ File Scan sofort sichtbarâŠ
doch genau das heisst es - weil man ansonsten erweiterte Funktionen wie Snapshot fĂŒr âweniger fortgeschritteneâ Schnittstellen nachbauen muss - damit die Applikation gleich funktioniertâŠ
das liegt ganz einfach dass die Applikation diese Informationen nicht braucht. Das System is so konzipiert dass es die Daten auf dem Dateisystem allein verwaltet und niemand an den Files rumfummelt (occ files:scan Problem)
ich bin sicher dein Pull Request fĂŒr die UnterstĂŒtzung von âfile changeâ Events fĂŒr alle durch Nextcloud supportete Filesysteme und Architekturen wird dankend angenommenâŠ
das wĂŒrde aber nichts an der Tatsache Ă€ndern dass es der falsche Weg ist. Eine Applikation die mehr als nur Dateien verwaltet (Berechtigungen, freigaben usw) ist prinzipbedingt darauf angewiesen dass Zugriffe ĂŒber definierte Schnittstellen erfolgen und nicht jemand im Datenbestand wahllos Dateien Ă€ndertâŠ
mit der gleichen BegrĂŒndung kannst du auch versuchen Datenbankdateien aus dem Snapshot/Backup zurĂŒckzuholen und erwarten dass die Datenbank diesen Datenstand direkt ĂŒbernimmt⊠oder erwarten dass Nextcloud gelöschte Dateien auf den Offline Tape Backup entfernt sobald diese wegen DSGVO obsolet werdenâŠ
Das ist ja eine suuuper Idee.
1.
Ich schaffe mir einen weiteren Rechner an, mit dem der der Scanner per FTP, SFTP oder SMB kommunizieren kann.
Und dieser Rechner schiebt die Daten dann per Webdav hoch.
2.
Ich mounte auf dem Rechner, auf dem Nextcloud lÀuft, die Nextcloud Verzeichnisse noch mal per Webdav ein. Und alle Dateien die vom Scanner kommen verschiebe in dem Script eben per WebDav.
Nein eben nicht. Es kann durchaus 2 unterschiedliche Lösungen geben, die eben nur Àhnlich funktionieren.
Das ist kein Herumfummeln, sondern die Nutzung einer definierten und dokumentierten Funktion.
In der Doku steht nirgends das man bestimmte Dateisysteme nicht nutzen darf.
Und das sind auch keine wahllosen Ănderungen in Dateien. Alles passiert ĂŒber dokumentierte Schnittstellen.
Faktisch ist das genau so ein Murks, wie seit Jahren nicht funktionierende Syncronisation von Dateien mit dem Android Client.
Oder die tolle Idee, das ein Anwender der html Dateien speichert, diese nicht betrachten kann ohne sie vorher herunterzuladen.
Super Sicherheitsfeature!
Und so lĂ€Ăt sich die Liste der Katastrophen in Nextcloud weiter fortfĂŒhren.
Ich sag nur âein Ort fĂŒr all ihre Datenâ.
FĂŒr viele Anwender bedeutet das eben, das sie an Ihre eigenen Daten nicht mehr einfach ran kommen.
Wir haben das Thema zum Anlass genommen, die Abschaltung der Nextcloud Instanzen jetzt endgĂŒltig mit aller Macht voranzutreiben und zu einem geordneten Betrieb zurĂŒckzukehren. Spielzeug kann man dafĂŒr einfach nicht gebrauchenâŠ
NatĂŒrlich kannst du ZFS mit Nextcloud nutzen, bzw. den Datenordner auf einem ZFS Dataset legen oder auch die Nextcloud selbst auf ZFS betreiben. Die Vorteile von ZFS beschrĂ€nken sich ja nicht auf Snapshots. Und selbst die kannst du als Server Admin nutzen. Nur halt nicht so, dass induviduelle User, indviduelle Files aus den Snapshots wiederherstellen können.
Und nochmal: Niemand stoppt dich oder jemand anderes davor ein Plugin bzw. eine App zu programmieren, welche diese Funktion irgendwie in Nextcloud integriert. K.A. Eventuell könnte man ja den SMB Part der External Storage App irgendwie mit der Shadow Copy FunktionalitÀt erweiteren�
Klingt fĂŒr mich ein wenig nach Trotzreaktion. Du arbeitest auch irgendwo, oder? Und die Firma fĂŒr die du arbeitest hat sicher auch ein paar kernige Marketing SprĂŒche auf der Website. Und auch ihr werdet trotzdem nicht jeden Wunsch, mit dem jemand an euch herantritt, sofort und problemlos erfĂŒllen könnenâŠ
Zum Rest sage ich nichts. Wenn das Produkt nicht zu deinem / eurem Workflow passt ist das halt so.
