Speicherort des Backupfiles ändern

[tsohst]

• Der Pfad für das Backupfile müsste editierbar sein, es direkt neben dem "offenen" File zu legen ist im Zweifel nicht genug Schutz.

[buchen]

Du meinst: ist im Zweifel nicht genug Schutz?

[tsohst]

Stimmt, habe ich angepasst :)

[ghost]

Was ich Anmerken möchte, für sicher > 90% der Anwender bedeutet Datensicherung (wenn überhaupt daran gedacht wird):

• Wir speichern die Datei in einem anderen Verzeichnis
• Wir speichern die Datei auf einem anderen Laufwerk innerhalb der selben partitionierten Festplatte

Wenn die Festplatte abraucht ist es egal wo die Datei liegt, oder irre ich mich da?

[tsohst]

Prinzipiell möchte ich das Backup auch auf ein anderes Medium im Netzwerk auslagern und es händisch nach jedem Speichern zu kopieren könnte man vereinfachen.

[chrisaut]

Wäre es auch möglich eine Art "daily backup", bzw jedesmal wenn die Datei das erste mal pro Tag beschrieben wird zu machen? "name.backup.YYYY-MMM-DD-HH-mm.portfolio" oder so irgendwie. Ich würde das dann auf ein Verzeichnis legen das automatisch in der Cloud gebackuped wird.

Habe erst die letzten Tage angefangen mit dem Programm alle alten Buchungen zu erfassen, was ein ziemlicher Aufwand ist und meine größte Angst ist, dass die Datei mal irgendwie, irgendwo, irgendwann verloren geht oder beschädigt wird und ich das alles nochmal machen darf.

[cmaoling]

Danke @Ragas13 , hatte ich nicht gesehen.. Würde als Basis mal ein alternatives Verzeichnis vorschlagen.. Habe vorhin mal angefangen es zu codieren. Bin dabei auf die Idee gekommen das als eine Tab in den Settings einstellbar zu machen und in der XML zu speichern. Im folgenden denke ich kann man eine Art Auto-Save per Job machen und die Erweiterung mit dem Datum ist dann eine simple Zusatzoption....

[Pnda87]

sollte mE eingebaut werden. Über den parametrisierbaren Speicherpfad für das Backup File gibt man dem User zumindest die Möglichkeit, ein sinnvolles Backup anzulegen. Wie er diese Möglichkeit dann nutzt, ist seine Sache.

Ich finde die Idee einer Option in den Settings sehr gut. Bin generell dafür mehr Dinge per Einstellungsmöglichkeit änderbar zu machen

[cmaoling]

Der erste wilde Hack ist schonmal fertig. Wird dann so im XML abgespeichert:

   </entry>
    </configurationSets>
    <clientSettings>
      <attribute-type>
        <id>9d6ebb6b-d8aa-4c93-b4fe-461bba8f0a25</id>
        <name>BackupDir_ClientSetting</name>
        <columnLabel>ColumnLabel_None</columnLabel>
        <target>name.abuchen.portfolio.model.Client</target>
        <type>java.lang.String</type>
        <converterClass>name.abuchen.portfolio.model.AttributeType$StringConverter</converterClass>
      </attribute-type>
    </clientSettings>
  </settings>

Habe vor unter "Settings" ein Tab zu erstellen in dem diese dann geändert werden können.

Kann man dann theroretisch für beliebige Parameter in der Klasse Client benutzen:

private void addClientSettings() { ClientSetting backupDir = new ClientSetting(UUID.randomUUID().toString()); backupDir.setName("BackupDir_ClientSetting"); //$NON-NLS-1$ backupDir.setColumnLabel("ColumnLabel_None"); //$NON-NLS-1$ backupDir.setTarget(Client.class); backupDir.setType(String.class); backupDir.setConverter(StringConverter.class); addClientSetting(backupDir); }

Bin gerade dabei die addtribute-type Klasse aufzubohren, daß sie dann gleich den Wert beinhaltet. So gesehen die integrierte Funktionalität von ConfigurationSet ... Weil hier macht es ja wenig Seinn das als Attribute in die Client Klasse hinzuzufügen. Gibt diese Parameter ja nur einmalig..

[cmaoling]

Bummer, wird nicht so einfach klappen, da ich in jeder Zeile einen anderen EditingSupport benötige :(

[buchen]

Backups scheint ein Thema zu sein... man erfasst aber auch eine ganze Menge Daten die man nicht einfach verlieren möchte.

Hier ein paar Diskussionspunkte. Wie seht Ihr das?

Erstens: ich denke Backups sollten pro Installation verwaltet werden. Für mich macht es keinen Sinn in der XML Datei selber einen Dateipfad zu speichern weil der auf dem nächsten Rechner nicht mehr stimmt.

Zweitens: Die Logik der existierenden Backups - insbesondere "backup-after-open" - möchte ich nicht ändern. Der "backup-after-open" kopiert die Datei, die auf jeden Fall eingelesen werden konnte. Die belasse ich neben der Originaldatei.

Drittens: Braucht es einen "Daily Backup"? Natürlich könnte man mit dem Datum was Wegschreiben. Aber nach welcher Logik löscht man alte Backup-Dateien wieder? (Ansonsten läuft das Verzeichnis irgendwann über) Und wieviele Dateien legt man an, wenn mehrfach am Tag gespeichert wird?

Am einfachsten wäre es wenn man die aktuelle "backup" Datei einfach in einem anderen Verzeichnis speichert. Dieses Verzeichnis würde man über die "Einstellungen" des Programms (also über das Hilfe Menü) konfigurieren können.

Viertens: Was macht man mit den "settings"? Die findet PP entweder weil es der gleiche Dateinamen mit einer anderen Endung ist, oder in dem Workspace Verzeichnis mit dem Hash des kompletten Pfades. Wenn man "zurück" auf eine alte Datei muss, dann sind die Settings erst mal verloren es sei denn man benennt die Datei vorher um. Ich denke aber so häufig braucht es doch wohl keine Backup.

[cmaoling]

Hallo, meine Meinung: Zu Erstens: Nunja, sollte man auf einen neuen Rechner umziehen, dann müsste man vor dem ersten abspeichern den Pfad aktualisieren oder das Backup würde fehlschlagen. Ich weiß nicht, ob es viele gibt, die eine XML von verschiedenen Geräten im Wechsel bearbeiten

zu Zweitens: OK. Mir geht es um das eigentliche Backup-file: backup.xml

zu Drittens: Das mit dem Speicherplatz muss der jeweilige Anwender mit sich klären. Aus meiner Sicht wäre auch ein git repo geeignet. So verwalte ich meine XMLs und kann theoretisch auch in der Zeitleiste wandern... Oder wenn ich mal eine eigene Version total runiniert haben sollte. Hatte schon mehrfach überlegt das git backend zu integrieren, aber nie die Zeit gefunden.... Aber ja, es sollte keine vollumfängliche Backuplösung werden mit warmen, kalten und offline Daten...

"Dieses Verzeichnis würde man über die "Einstellungen" des Programms": Finde es im XML besser, da man damit für verschiedenen Portfolio Datein unabhängig das festlegen kann, statt das jede Test-XML plötzlich im Netzspeicher gesichert wird.

Zu Viertens: Den Punkt verstehe ich nicht. Die Settings sollen Einstellungen in der Datei speichern, ähnlich zu den genannten ConfigurationSets. Wenn man ein Restore machen muss, gehe ich davon aus, daß man das gesicherte XML an den primären Speicherort selbstständig kopiert/bewegt. Hier will ich nichts implementieren. (Siehe oben. keine vollumfängliche Backuplösung...)

[chrisaut]

Hi,

1) Macht Sinn 2) Diese backup-after-open schützt also vor einem fehlerhaften Beschreiben der Datei, dh. zB wenn der Strom gerade mitten während des write Vorgangs ausfällt oder ein Bug im Program die serialisierung bzw. encryption verkackt? Finde ich gut.

3) Neben diesem Schutz vor technischem Verlust, dh Unleserlichkeit, möchte ich aber auch gegen anderen Datenverlust schützen. Das kann sein, ein Bug ist im Programm der Zahlen falsch gerunded wegschreibt, eine csv import aktion die schwer wieder manuall rückgängig gemacht werden kann. Eine manuelle Änderung die fehlerhaft war und man erst 2 Wochen später draufkommt, etc. Ich glaube man sollte grundsätzlich festlegen warum man backups möchte, dH gegen was möchte man sich schützen.

Zur Logik der Verwaltung, könnte man natürlich einfach sagen dass überlässt man dem Benutzer, so groß sind die Dateien ja nun nicht, meine ist gerade mal 400kb groß bei bestimmt mehreren tausend Buchungen. Idealerweise hätte man zwei Levels, wie das auch bei Datenbank backups oft gemacht macht, n short time (daily) backups, zb. die letzten 14 Tage, und dann long time backups, 1x im Monat oder so.

Das wäre zwar alles nett und gut, ich ziehe mein feature request aber zurück da ich nicht denke dass der Aufwand sich lohnt. Business value denke ich wäre zwar da, aber der effort wohl zu groß und gibt viel anderes was mehr Wert hat. Es gibt ja auch externe Programme mit denen man Dateien gut sichern kann, und wenn die in der Cloud liegt dann gibts ja auch oft eine automatische Versionierung. Die Git variante finde ich übrigens auch interresant, wenn die Datei verschlüsselt ist klappt das mit den diffs halt nicht.

4) Verstehe ich auch nicht, vor allem mit dem Hash, und wieso settings Datei...wenn das einmal pro installation gespeichert wird dann halt in ein bekanntes Verszeichnis, die einstellung gilt dann wohl für alle .portfolio Dateien die mit dieser installation geöffnet werden. Wobei, was passiert man man in Verzeichnis a eine xy.portfolio und in einem andere Verzeichnis auch eine xy.portfolio Datei hat (also gleicher Dateiname), Backup Pfad ist eingestellt auf /irgendwas .... dann darf er halt nicht das Backup von der Datei in /a mit einem backup der Datei in /b überschreiben. Hier würde ein hash des kompletten pfades helfen...meinst du das?

[cmaoling]

Hallo zusammen, also das ist nun doch komplizierter geworden, als gedacht. Habe mal einen Snapshot hochgeladen, um Rückmeldungen zu bekommen. Ich nutze im Prinzip die AttributeType Klasse und habe diese erweitert. Client ist nun Attributable, aber nutzt nicht Attribute. Außerdem muss der View für jede Zeile einen anderen Typ annehmen. Unter "Settings" habe ich ein weiteres Tab hinzugefügt. Ich habe versucht das so allgemein zu halten, daß man mittelfristig beliebige Variablen setzen kann. Für das BackupDirectory musste ich sogleich einen Spezialfall einbauen bei dem man mit einem Dialogfenster den Wert eingibt, statt einfach nur in einem Textfeld einzugeben... Wer Zeit und Lust hatte, bitte mal den PR anschauen und kommentieren.

Danke!

[cmaoling]

Hallo, ich habe mit 571b5abef nun die autosave Funktionalität eingeführt. Bin weiterhin an Bemerkungen und Hinweisen interessiert, ob das so umgesetzt werden sollte. Danke!

@buchen Die automatische Sicherung ist evtl. eine interessante Erweiterung unabh. vom Backup

[buchen]

@cmaoling - ohne PR habe ich die Änderung nicht auf dem Radar gehabt. Ich habe einfach mal einen per #1465 angelegt damit wir da diskutieren können.

[metal450]

I wasn't able to understand all of the above comments via Google Translate, but I believe this issue is to discuss the need for a user-customizable backup location - and I'd also like to add my voice.

I've added my profile folder to a sync profile between several PCs, as well as to my regular scheduled system backup - but it causes unnecessary extra data transfer to backup both the profile, and the profile's backup, each time. Most applications solve this by allowing a separate user-configurable location for the backup ;then your system backup profile can include the original data, but not the "auto-backups" :)

[metal450]

Addendum: even if not user-configurable, at least having the backups be in a subdir next to the main file could permit moving these backups elsewhere by means of a symlink. i.e. if organized like below, "backups" could be symlinked to another location:

db.xml backups/db.backup.xml backups/db.backup-after-open.xml

[metal450]

I've spent a bit of time trying to go through this with Google Translate, & think it may actually already be possible to set a different backup directory, per https://github.com/buchen/portfolio/pull/1465/commits/4dbfb3006b62207c0a5977d9ba5374319eeaa1a3? However, I haven't been able to figure out how to actually set the directory (either in the UI, or by editing config files). If it is indeed possible & someone could provide some insight on how to setup a different backup directory, I'd appreciate it :)

[ghost]

@metal450 For example you could check how the DivvyDiary API key handled from the config dialogue thru Java functions:

https://github.com/buchen/portfolio/commit/0de5e0d9b6691fc11330731a750ef8a6e5e730f6

[metal450]

Thanks for the reply...unfortunately I'm still not really clear on how this relates to how one would change the backup directory (if it's indeed possible)... :/

[Ricent82]

I also have this issue with syncing/uploading lots of duplicate data; if the 2x backup xml files could be in a subdir or different dir from the main file, it could be excluded & fully solve the issue, cutting data transfer in 1/3.