Wie erzeugt man ein neues, lokales Full Backup?

[DS111-User]

Wie muss ich vorgehen, damit ich auf meiner DS111 ein neues, lokales Full Backup bekomme?

Ich weiss aus diesem Forum und der Wiki, dass mit Bordmitteln nur beim allerersten Lauf ein Full Backup erstellt wird. Danach sichert der gleiche Job "nur" noch die seither veränderten Daten.

Ebenfalls ist mir bekannt, dass eine wichtige Datei in diesem Zusammenhang die

/etc/synolocalbkp.conf

ist. Ohne Datensicherungs-Jobs ist diese Datei leer, sobald ich einen Job im DSM erfasse um z.B. meinen Photo-Ordner und den Blog zu sichern (diesen Job aber noch nicht ausführe) steht da z.B. für eine lokale Kopie:

[My backup Set 1]
        incrbkp="0"
        last_bkp_time=""
        dest_id=""
        last_bkp_result=""
        dest_type="internal"
        bkp_shares="photo"
        bkp_folders="/photo"
        bkp_apps="photostation,blog"
        dest_share="Gemeinsamer Ordner"

Führe ich diesen Job aus, steht z.B. folgendes drin:

[My backup Set 1]
        incrbkp="0"
        last_bkp_time="2011/02/15 17:57"
        dest_id="20110215175723-001132096B95"
        last_bkp_result="0x0"
        dest_type="internal"
        bkp_shares="photo"
        bkp_folders="/photo"
        bkp_apps="photostation,blog"
        dest_share="Gemeinsamer Ordner"

Mir fehlt nun aber die Möglichkeit, bewusst ein neues Full Backup zu erzeugen.
Den vorhandenen Job zu löschen reicht nicht, das gibt einfach eine leere synolocalbkp.conf-Datei. Einen neuen aber anderslautenden Job zu erfassen hilft auch nicht, das sichert wiederum nur die Differenz.

Wo muss ich ansetzen, damit ich ein neues, lokales Full Backup erhalte?

 

[QTip]

versuche mal den Parameter last_bkp_result="0x0" auf last_bkp_result="" zu setzen

 

[DS111-User]

Leider scheint das nicht zu helfen.

ABER:
Ich bin nun selber verunsichert. Kann es sein, dass ein neuer Job zwar sehr wohl das obige Verzeichnis /photo backuped, NICHT aber die Daten in

@app
  @blog
  @photo

und deshalb der Eindruck entsteht, dass sei kein Full Backup?
Als ich vorhin mal einen USB-Stick einsteckte und die gleiche Auswahl mit einem neuen Job auf diesen usbshare1 sichern liess, waren eben auch die beiden Backupdateien

synoblog.backup  -> @blog-Verzeichnis

und

synophoto.backup  -> @photo-Verzeichnis

auf dem USB-Stick zu finden.

Kann mir vielleicht jemand helfen, dass Brett vor meinem Kopf zu entfernen?

 

[DS111-User]

Kann das bitte jemand verifizieren:

Erstellt einen "Gemeinsamen Ordner" mit mindestens einem Leerschlag im Namen, also z.B. "Lokaler Backup Ordner" oder auch nur "Gemeinsamer Ordner".

Erstellt einen neuen Backup-Job und wählt als Speicherziel den eben erstellten Ordner mit mindestens einem Leerschlag drin aus.
Wählt als Datensicherungs-Ordner das \photo-Verzeichnis komplett aus.
Wählt als Anwendung "Photo Station" und "Blog".
Lasst den Sicherungsjob laufen.

Erstellt es Euch die beiden oben erwähnten *.backup-Dateien im @blog und @photo Verzeichnis?

Ich hab eben bei mir festgestellt, dass ich diese Dateien nur dann gesichert bekomme, wenn der Speicherziel-Namen KEINE Leerschläge enthält.

Bin gespannt auf Eure Antworten.

 

[brucki]

Hallo DS111-User,

ja, ich kann das verifizieren!

Dank Deiner Verrifizierungsanfrage bin ich auf die Lösung für mein Problem gekommen.
Nach einem Restore eines BUs waren nämlich alle Photo-User-Acounts und deren Berechtigungen, sowie der Bolg weg! :-(

Ursache: Ich hatte in derm BU-Verzeichnis Leerzeichen (Spaces) " " drin.
Folge: Die Verzeichnisse @blog und @photo blieben nach einem Backup leer. :-(

Lösung: Leerzeichen durch "_" ersetzt.
Folge: In den Verzeichnissen @blog und @photo sind nun nach einem Backup auch *.backup-Dateien angelegt worden.

-> Schade, das es keinen entspechenden Hinweis auf den Backup-Verzeichnisnamen gibt.

Ich hoffe Dir und anderen Usern damit geholfen zu haben.

... noch einen schönen Sonntag.

Brucki

 

[DS111-User]

-> Schade, das es keinen entspechenden Hinweis auf den Backup-Verzeichnisnamen gibt.

Ich hoffe Dir und anderen Usern damit geholfen zu haben.

Ja, hast Du! Danke für Dein Feedback. Einerseits weiss ich nun, dass das nicht an meiner Konfiguration liegt und andererseits wissen wir jetzt auch, wie man das Problem umgehen kann. Ich möchte im Moment allerdings nicht wissen, wieviele Leute sich einen Backup-Ordner mit Leerschlag angelegt haben und ihr blaues Wunder bei einem Restore erleben werden.

Kann man bei Synology irgendwo nachsehen, ob diesbezüglich schon ein Bug-Issue eröffent wurde?

 

[mc_midi]

Im Wiki steht folgender Hinweis, dass ein neues Full Backup erzeugt wird, wenn die Backup-Platte vom Server entfernt wurde und dann wieder verbunden wurde. Ist das nicht die Lösung?

Notes for Local Backup

* The first backup job will be a full backup, and will require the most amount of time

* Subsequent backup jobs will then be incremental backups, only files which have been modified since the last backup will be copied to the server

* The Backup drive must remain on and connected to the Synology Server at all times; if it is disconnected from the Synology Server, then the next time it is connected, Local Backup will perform a full backup. This is to insure data integrity.
o If Firmware is DSM2.0-598 or above: If the backup disk is unplugged during the backup procedure, the next backup will be a full backup. If the backup disk is unplugged after a backup task has finished and then plugged-in again, the next backup will still be incremental.

 

[DS111-User]

Danke auch dir, mc_midi.
Bei mir lag das Problem tatsächlich im Leerschlag des Pfades (siehe Beitrag #4).
Und wegen Deiner Frage: Nein, das wäre für mich keine Lösung. Ich will ja nicht jedesmal die externe Platte entfernen und wieder anschliessen, nur damit ich ein FullBackup bekomme. Das müsste für mich zwingend auch remote lösbar sein. Was es jetzt ja mit dem Wissen um den nicht erlaubten Leerschlag auch ist .-)