Backup verbraucht zu viel Platz

Status
Für weitere Antworten geschlossen.

barghest

Benutzer
Mitglied seit
29. Apr 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
Liebe DS-Gemeinde,

ich habe hier eine DS 107 mit einer 500GB Festplatte. Auf dieser Platte befinden sich Daten mit einer Gesamtgröße von 350GB.

Um diese Daten zu sichern habe ich mir eine externe Festplatte gekauft, die per USB angeschlossen ist und insgesamt 640GB fasst.

Nun habe ich den letzten Wochen regelmäßige Backups über die Web-Oberfläche durchgeführt. Leider ist das gestrige Backup fehlgeschlagen und ich staunte nicht schlecht, dass die Fehlermeldung lautete :"Insufficient disk space". Ich habe dann nachgeschaut und die USB-Festplatte war tatsächlich fast voll (630GB).

In dem Optionen habe ich kein Häkchen gesetzt bei "Inkrementelles Update", da dort steht, dass in diesem Fall Dateien, die in der Quelle gelöscht wurden auch im Ziel gelöscht werden (ist das nicht eine etwas seltsame Auslegung des Begriffs inkrementell - aber das nur am Rande).

Warum verbraucht mein Backup 280GB mehr als eigentlich benötigt?

Danke!

Thomas
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Viele Dateien im Original gelöscht?
Papierkorb an?
Schau dir doch mal die Sicherungsplatte an, was da drauf ist und vor allem, was deiner Meinung nach doppelt bzw. überflüssig ist.

Itari
 

barghest

Benutzer
Mitglied seit
29. Apr 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
Hi,

danke für die schnelle Antwort.

Viele Dateien im Original gelöscht?

Eigentlich dachte ich ja, dass gelöschte Dateien auch auf der USB-Platte gelöscht werden:

Wenn diese Option markiert ist, bleiben Dateien, die am Quellort entfernt werden, am Speicherort bestehen. Ansonsten werden Dateien, die am Quellort entfernt werden, auch am Speicherort entfernt.

Hier habe ich also kein Häkchen gesetzt, damit sich auf der USB-Platte nichts "ansammelt".

Wegen der anderen beiden Punkte schaue ich nach, wenn ich wieder zu Hause bin. Sollte der Mülleimer aber nicht auch beim verbrauchten Speicherplatz mit einberechnet sein?
 
Zuletzt bearbeitet:

barghest

Benutzer
Mitglied seit
29. Apr 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
OK, der Papierkorb war nicht aktiviert. Er war es wohl einmal, denn nachdem ich ihn geleert habe, sind nun ein paar GB weniger belegt auf der DS.

Ich bin auch die Ordner durchgegangen, aber dort war nichts doppelt oder überflüssig. Was noch eben gesehen habe ist, dass die USB-Platte eine angezeigte Kapazität von 586GB hat (davon 569 belegt). Das liegt dann aber eher an den unterschiedlichen Umrechnungsfaktoren zwischen Herstellern und Realität. Dennoch dürfte die USB-Platte ja auf keinen Fall voll sein.
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Mit was ist die USB-Platte formatiert? NTFS, FAT, EXT3?

Mit du [disk usage] kann man sich schon einen Überblick darüber verschaffen, wo wie viel liegen sollte. Die Sicherung kann ja nur dann größer sein, wenn irgend etwas auf der Platte ist, was entweder doppelt, zu viel oder mit einem anderen Programm dahin kopiert wurde.

Kannst aber auch die Platte löschen und einen ersten vollständige Backup fahren, dann dürfte es ja wohl wieder stimmen.

Itari
 

barghest

Benutzer
Mitglied seit
29. Apr 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
Formatiert habe ich sie mittels Web-Oberfläche - das dürfte dann ext3 sein, oder?

Was mir eben eingefallen ist: Wie sieht es denn mit Hard-Links aus? Auf die DS sichere per rsync regelmäßig mein System. Dabei entstehen natürlich Hard Links. Kann das zu Problemen führen bzw. gibt es diesbezüglich Konfiguratnsmöglichkeiten? Das Synology BAckup wird ja auch auf rsync basieren.

Ein neues, vollständiges Backup wollte ich eigentlich vermeiden, da es 1. ewig dauert und 2. das Problem ja nicht löst. Am Ende kann ich alle 4 Wochen ein neues vollständiges Update durchführen.
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Zwar wird auch ein rsync fürs Backup von Synology verwendet, aber Hardlinks werden nicht erkannt ... also bekommst jede Menge Kopien. Am besten du bastelst dir selbst ein Skript, wo die Optionsschalter dann richtig gesetzt werden, damit du dein Problem in den Griff bekommst.

Itari
 

barghest

Benutzer
Mitglied seit
29. Apr 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
Zwar wird auch ein rsync fürs Backup von Synology verwendet, aber Hardlinks werden nicht erkannt ... also bekommst jede Menge Kopien. Am besten du bastelst dir selbst ein Skript, wo die Optionsschalter dann richtig gesetzt werden, damit du dein Problem in den Griff bekommst.

Itari

Schade, dass die Synology-Lösung nicht anpassbar ist.

Ich habe im englischen Wiki folgendes Skript gefunden und angepasst:
Code:
# Simple script to backup data from BACKUP_SOURCE to BACKUP_TO_DEVice
#
# this can be any drive attached to your synology box ...
# ... internal drive(s), external USB drive(s), external SATA drives(s)
#
# To keep the script short and simple, it doesn't check that the source
# and/or target directories exists -- If they don't then it fails!
# It also makes no check that you have sufficient space on the drive.


# Backup source device/share/directory/etc
BACKUP_SOURCE=/volume1/

# Backup destination device/directory -- DO NOT include the trailing slash
BACKUP_TO_DEV=/volumeUSB1/usbshare/backup

rsync -q -axH --delete --exclude="@eaDir" $BACKUP_SOURCE $BACKUP_TO_DEV/

# end

Ist alles so korrekt?

Nun weiß ich leider gar nicht, wo das auf der DS gespeichert werden muss (nur dass noch ein chmod +x gemacht werden muss, um das Ganze ausführbar zu machen).

Cron ist ja auch schon auf der DS, oder?

Könnte denn mit dem Skript auch das gesichert werden, was im Web-Interface unter "Anwendungen" fällt (z.B. Photo-Station)?
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Schau auch mal in unser Wiki. Zum Thema Backup gibt es da ne Menge Ideen.

Die Photo-Station lässt sich leider nicht ganz so einfach sichern, da einige Informationen in der Postgres-Datenbank drin sind und die kann man nicht so einfach per rsync sichern. Aber man kann ja sowohl die eingebaute Sicherung als auch was eigenes parallel machen ... Ich habe bestimmt 15 Sicherungssätze (für jede Share einen eigenen) und das geht hervorragend.

Itari
 

barghest

Benutzer
Mitglied seit
29. Apr 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
Alles klar, danke.

Ich weiß, dass das kein rsync-Forum ist, aber ich habe ein Problem mit Symlinks. Bei diesen bekomme ich immer die Fehlermeldung
Code:
rsync: open(/pfad/zum/symlink) failed!!: No such file or directory (2)

Die Option -a beinhaltet ja die Option -l, die sich um symlinks kümmern sollte.
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
In der Tat ist das Sichern von Symlinks nicht einfach. Warum? Die originalen Symlinks sollen ja nicht kopiert werden, weil sie ja auf die originalen Dateien verweisen, sondern sie sollen ja auf die "gesicherten" Kopien verweisen, nicht wahr? Da können sie aber erst, wenn die originalen Dateien gesichert sind, vorher würden sie ja ins leere gehen. Nun müsste man also immer erst alle Originale sichern und anschließend die Kopien ...

Und nun zum Zurücksichern? Da müsste also der rsync sehr intelligent sein, um zu wissen, auf welches Original er wieder zurück verknüpft und dieses müsste dann auch früher zurückgespielt werden als der Symlink ...

Merkst du was? Es ist kompliziert. Es ist deswegen einfacher ohne das Konzept des Symlinks zu arbeiten.

Am Rande, auch bei Hardlinks gibt es Ungereimtheiten ... man muss sich das sehr genau ansehen, wenn es funzen soll.

Ich hab mal die Stelle aus dem Manual herauskopiert:

-l, --links
When symlinks are encountered, recreate the symlink on the destination.
-L, --copy-links
When symlinks are encountered, the item that they point to (the referent) is copied, rather than the symlink. In older versions of rsync, this option also had the side-effect of telling the receiving side to follow symlinks, such as symlinks to directories. In a modern rsync such as this one, you'll need to specify --keep-dirlinks (-K) to get this extra behavior. The only exception is when sending files to an rsync that is too old to understand -K -- in that case, the -L option will still have the side-effect of -K on that older receiving rsync.
--copy-unsafe-links
This tells rsync to copy the referent of symbolic links that point outside the copied tree. Absolute symlinks are also treated like ordinary files, and so are any symlinks in the source path itself when --relative is used. This option has no additional effect if --copy-links was also specified.
--safe-links
This tells rsync to ignore any symbolic links which point outside the copied tree. All absolute symlinks are also ignored. Using this option in conjunction with --relative may give unexpected results.
-k, --copy-dirlinks
This option causes the sending side to treat a symlink to a directory as though it were a real directory. This is useful if you don't want symlinks to non-directories to be affected, as they would be using --copy-links.
Without this option, if the sending side has replaced a directory with a
symlink to a directory, the receiving side will delete anything that is in the way of the new symlink, including a directory hierarchy (as long as --force or --delete is in effect).
See also --keep-dirlinks for an analogous option for the receiving
side.
-K, --keep-dirlinks
This option causes the receiving side to treat a symlink to a directory as though it were a real directory, but only if it matches a real directory from the sender. Without this option, the receiver's symlink would be deleted and replaced with a real directory.
For example, suppose you transfer a directory lqfoorq that contains a file
lqfilerq, but lqfoorq is a symlink to directory lqbarrq on the receiver. Without --keep-dirlinks, the receiver deletes symlink lqfoorq, recreates it as a directory, and receives the file into the new directory. With --keep-dirlinks, the receiver keeps the symlink and lqfilerq ends up in lqbarrq.
One note of caution: if you use --keep-dirlinks, you must trust all
the symlinks in the copy! If it is possible for an untrusted user to create their own symlink to any directory, the user could then (on a subsequent copy) replace the symlink with a real directory and affect the content of whatever directory the symlink references. For backup copies, you are better off using something like a bind mount instead of a symlink to modify your receiving hierarchy.
See also --copy-dirlinks for an analogous option for the sending side.
-H, --hard-links
This tells rsync to look for hard-linked files in the transfer and link together the corresponding files on the receiving side. Without this option, hard-linked files in the transfer are treated as though they were separate files.
When you are updating a non-empty destination, this option only ensures
that files that are hard-linked together on the source are hard-linked together on the destination. It does NOT currently endeavor to break already existing hard links on the destination that do not exist between the source files. Note, however, that if one or more extra-linked files have content changes, they will become unlinked when updated (assuming you are not using the --inplace option).
Note that rsync can only detect hard links between files that are inside
the transfer set. If rsync updates a file that has extra hard-link connections to files outside the transfer, that linkage will be broken. If you are tempted to use the --inplace option to avoid this breakage, be very careful that you know how your files are being updated so that you are certain that no unintended changes happen due to lingering hard links (and see the --inplace option for more caveats).
If incremental recursion is active (see --recursive), rsync may transfer
a missing hard-linked file before it finds that another link for that contents exists elsewhere in the hierarchy. This does not affect the accuracy of the transfer, just its efficiency. One way to avoid this is to disable incremental recursion using the --no-inc-recursive option.

*link*

Itari
 

barghest

Benutzer
Mitglied seit
29. Apr 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
Ja, damit hatte ich mich schonmal auseinadergesetz.

Ich habe ja auch schon diverse rsync-Skripts, mit denen ich von meinen PCs auf die DS sichere. Bei denen hatte ich diese Fehlermeldungen nie, auch wenn die Datei, auf den der Symlink verweist, außerhalb des zu sichernden Pfads liegt. Der Symlink ist ja vorhanden und soll auch gesichert werden. Warum beschwert sich hier rsync nun, dass der Symlink gar nicht erst existiert?

Wie handhabst Du das bzw. was empfiehlst Du?
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Vielleicht gibt dir die /var/log/messages noch genauere Hinweise über diese Fehlermeldungen ... und schau mal, ob du die fehlerhaften Symlinks manuell erwischen kannst, damit du mal an einem Objekt studieren kannst, was da zum Fehler führt.

Itari
 

barghest

Benutzer
Mitglied seit
29. Apr 2008
Beiträge
53
Punkte für Reaktionen
0
Punkte
0
Nein, in /var/log/messages findet sich leider nichts.

Im Prinzip stoplter rsync über jeden Symlink, egal ob er auf eine Datei im zu sichernden Pfad oder auf eine außerhalb verweist (habe per ls -la mal einen Ornder angeschaut und er meckerte bei allen Symlinks).

Was mich eben wundert ist, dass es mit den selben Paramtern auf die DS funktioniert, aber nicht von der DS auf eine USB-Platte.

Naja, das Projekt backup muss nun erst einmal ruhen, nachdem es mal wieder zu einem Freeze der DS kam (häuft sich in den letzten Tagen ich bin im regen Austasuch mit den netten SUpport).
 

brakeprofi

Benutzer
Mitglied seit
14. Okt 2008
Beiträge
200
Punkte für Reaktionen
0
Punkte
16
Liebe DS-Gemeinde,

ich habe hier eine DS 107 mit einer 500GB Festplatte. Auf dieser Platte befinden sich Daten mit einer Gesamtgröße von 350GB.

Um diese Daten zu sichern habe ich mir eine externe Festplatte gekauft, die per USB angeschlossen ist und insgesamt 640GB fasst.

Nun habe ich den letzten Wochen regelmäßige Backups über die Web-Oberfläche durchgeführt. Leider ist das gestrige Backup fehlgeschlagen und ich staunte nicht schlecht, dass die Fehlermeldung lautete :"Insufficient disk space". Ich habe dann nachgeschaut und die USB-Festplatte war tatsächlich fast voll (630GB).

In dem Optionen habe ich kein Häkchen gesetzt bei "Inkrementelles Update", da dort steht, dass in diesem Fall Dateien, die in der Quelle gelöscht wurden auch im Ziel gelöscht werden (ist das nicht eine etwas seltsame Auslegung des Begriffs inkrementell - aber das nur am Rande).

Warum verbraucht mein Backup 280GB mehr als eigentlich benötigt?

Danke!

Thomas

Was mir neulich passiert ist, ich hatte auf der Synology mehrere große Dateien vergeschoben. Wenn das backup anfängt geht die DS Ordner für Ordner durch. Sie hat praktisch die verschobenen Dateien schon woanders auf der backup Platte angelegt, bevor sie an den alten Ordner dran kam um diese dort zu löschen. Also war die Platte "voll" und ein komplettes backup stand anschließend an :rolleyes:

Ich arbeite mittlerweile mit zwei backup Platten die auch an verschiedenen Orten lagern. Wenn wieder so ein murks passiert gehen einem wenigstens nicht die Daten flöten, wenn die DS zufällig crasht und bei backup Platte nummer eins der status unbekannt ist :)
 
Zuletzt bearbeitet:

tmfkab

Benutzer
Mitglied seit
01. Aug 2009
Beiträge
41
Punkte für Reaktionen
0
Punkte
6
Hallo zusammen,

habe bei meiner DS109 300GB belegt (laut Anzeige im DSM), ein Backup auf einer neuen/formatierten platte (nativ), belegt dan aber 580 von möglichen 600GB.

woran liegt das? Zuerst dachte ich, dass die DS den potentiell verfügbaren platz auf er verbauten HDD wie einen gleichgroßen Datencontainer auf die eSATA Disk schreibt, aber jede Woche beim Backuptermin wird das Backup abgebrochen, weil nicht genug Platz vorhanden ist. Wäre es ein Datencontainer könnte es ja darin schreiben...

Habe vorhin in einem anderen Thema was von Zeitstempel und Zeitabgleich gelesen, könnte das vielleicht damit zusammenhängen? die eSATA Platte hängt ja nur 1x die Woche dran, die DS macht aber jeden Tag einen NTP abgleich ( laut LOG jedesmal eine abweichung von 3-7 sec). Kann es sein, dass dieser Zeitabgleich jedesmal dazu veranlasst, ein neues, komplettes Backup zu schreiben???

jedoch ändert dieser Ansatz nichts an der Tatsache, dass die DS fasst doppelt so viel backup platz benötigt, wie daten vorhanden sind.

für Hilfen oder Erklärungen wäre ich Dankbar

tmfkab
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Wie sehen denn deinen Backup-Sätze aus? Kann es sein, dass da Verzeichnisse ineinander verlinkt sind und deshalb 2x gesichert werden?

Itari
 

tmfkab

Benutzer
Mitglied seit
01. Aug 2009
Beiträge
41
Punkte für Reaktionen
0
Punkte
6
eigentlich nicht, das einzige was doppelt gesichert wird, ist der ordner photos dadurch, dass die photostation inkl. daten und blog auch gesichert werden sollen, allerdings wären das nur ca 5 GB nicht 280GB...
ansonsten läuft das backup standardmäßig über die einstellungsmöglichkeiten im DSM. Die Verzeichnisse sollten eigentlich nicht querverlinkt sein, zumiondest habe ich da nichts eingerichtet...papierkorb ist aus, und "inkrementell" ist auch aus
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Du kannst ja mal mit dem File Manager auf die Sicherung schauen; vielleicht siehst ja, wo die Unstimmigkeiten herkommen ...

Itari
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Könnten Euch ggf die rsync Parameter -aH helfen? -a entspricht -rlptgoD und ein zusätzliches -H sorgt dafür das Hardlink Files als Links kopiert werden. Per Default kopiert rsync solche Dateien als Dateien und nicht als Links
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat