Was ist für meinen Anwendungsstil besser geeignet, differential oder inkrementelles Backup

1lluminate23

Lieutenant
Registriert
Aug. 2018
Beiträge
975
Hallo liebe CB-Community,

ich nutze für die Backups meines System Veeam Agent for Windows, welcher immer nur ein inkrementelles Backup erstellt. Und im Gegenzug nehme ich Macrium Reflect, welches in der kostenlosen Edition nur differentiale Backups anlegen kann. Ich habe mich eingelesen, aber so wirklich schlau werde ich da nicht draus..

Ich ändere oftmals kleine Dateien, Schriftstücke, nenne Bilder ergänze bei meiner Musik die ID-Tags. Jetzt meine Frage, welche der beiden Methoden ist eigentlich effektiver, oder "sicherer" ist gegen einen möglichen Datenverlust bei einer Widerherstellung?

Vielen Dank für Eure Zeit.

Lg. David
 
Sind beide gleich sicher oder unsicher. Inkrementell reicht ein fehlerhaftes Backup aus, und kein Recovery ist möglich. Bei Differentiellen kann zwischendrin mal ein Backup futsch sein, das davor oder danach muß dann aber funktionieren.

Ich für meinen Teil mache nur noch Vollbackups mit Verify. Ich hatte schon bei diversen Kunden mit Tapes und Co. keine guten Erfahrungen mit oben genannten Verfahren gemacht.
 
  • Gefällt mir
Reaktionen: mae1cum77, ella_one und 1lluminate23
Beide Methoden sollten gleich sicher sein. Der Unterschied ist nur die Methode wie gesichert wird, bzw. wie das Programm im Falle eines Restores vorgeht. Wenn du z.B. 1 Vollbackup und 10 inkrementelle Backup hast und du willst eine Datei aus dem zuletzt angelegten Backup haben, brauchst du alle 11 Backups (das volle und die 10 inkrementellen). Das inkrementelle Backup baut also immer auf das vorherige Backup (das erste inkrementelle auf das vorangegangen Vollbackup, das dritte inkrementelle Backup auf das zweite inkrementielle Backup, etc.). Das differentielle Backup sichert im differentiellen Teil quasi immer alle Änderungen seit dem letzten Vollbackup. Du brauchst dann also beim Restore vom letzten Backup nur das volle Backup und das letzte differentielle Backup.
 
  • Gefällt mir
Reaktionen: 1lluminate23
Hi,
sie unterscheiden sich in der Datenmenge des Backups. In Firmen, wo sich viel ändert und viele Sicherungen gemacht werden, wird eher das inkrementelle verwendet, denn Speicher Platz kostet Geld und Sicherungzeit hat man oft nicht viel übrig.
In beiden Fällen brauchst du aber die Vollsicherung, ohne gehts nicht.
In deinem Anwendungsfall würde ich zum differential Backup gehen.
 
  • Gefällt mir
Reaktionen: 1lluminate23
Hoch interessant für mich, dass wenn ein inkrementelles einen Fehler hat, das Backup für den Popo ist. Ja, dann hat differentiales ganz klar die Nase vorn! Ich werde das nutzen. Habt vielen Dank. Dann nehme ich Aomei und Macrium die können diffenrentiales kostenlos
 
Ich weiß schon, warum ich mit rsync inkrementell sichere und unveränderte Dateien als harte Links einfügen lasse...Da habe ich keine Abhängigleiten von früheren Backups und jedes Backup sieht wie ein Vollbackup aus!
 
  • Gefällt mir
Reaktionen: Blende Up, nkler und Purche
@tcool

Leider reichet mein Kenntnisstand nicht für rysnc, ich setze da lieber auf Macrium und Aomei
 
Bei inkrementellen Sicherungen geht die Sicherung schneller da immer nur die Änderung seit der letzten Sicherung ins Backup muss, dafür braucht der Restore in der Regel länger weil die Backupsoftware die Daten aus dem letzten Voll- und den folgenden inkrementellen Sicherungen zusammen fügen muss.
Differentielle Sicherungen brauchen bei der Erstellung mit jedem Tag seit der letzten Vollsicherung länger da jedes Mal alle Änderungen seit letzter Sicherung wiederhergestellt werden müssen. Die Wiederherstellung geht daher schneller da man nur die gewünschte Voll- sowie Differentialsicherung benötigt.

Beide Beispiele für einen vollständigen Restore. z.B. eines PCs/Servers/VM. Bei einzelnen Dateien klappt die Wiederherstellung auch mit inkrementellen Sicherungsmethoden sehr schnell.

@1lluminate23 Fehler bzw. korrupte inkrementelle Sicherungen kommen ja nicht nicht mehrfach täglich vor und es gibt ja Möglichkeiten die Wahrscheinlichkeit für solche Fehler zu reduzieren. Zum Beispiel indem man nicht nur eine Vollsicherung und dann dutzende und hunderte inkrementelle Sicherungen macht sondern z.B. wöchentlich eine Vollsicherung oder indem man reverse-incremental bzw. forever-incremental verwendet. Hierbei ist die letzte Sicherung immer die Vollsicherung. Das erzeugt zwar auf dem Backupstorage höhere IO-Last weil nach jeder Sicherung die aktuelle Fullsicherung erzeugt werden muss aber dadurch gewinnt man Vorteil der schnelleren Wiederherstellung bei Komplettausfall. Im privaten Umfeld nutzen jedoch die wenigsten Programme diese Funktion, daher bleibt da eher der Rat regelmäßige Vollsicherungen anzulegen bzw. nicht zu viele und ausschließlich inkrementelle Sicherungen zu nutzen.
Wenn du z.B. einen Monat lang jeden Tag ein Backup anlegen willst würde ich mindestens alle 14 Tage eine Vollsicherung anlegen.
 
Alte Weisheit: Ein nicht getestetes Backup ist ein kaputtes Backup.
Der im ersten Beitrag genannte Veeam Agent bietet das 'health check' Feature. Dabei wird das Backup gegen Prüfsummen die beim erstellen des Backup generiert wurden getestet. Ich empfehle, das Feature zu nutzen.

(Das volle Backup & Replication bietet noch deutlich mehr, übersteigt dabei aber auch 99,99% der privaten Usecases.)

tollertyp schrieb:
@grand_sniper: Wenn sich viel ändert, verliert das inkrementelle Backup doch aber eigentlich seine Vorteile?
Worst-Case ist die Backup-Kette genauso groß wie eine differentielle. Dafür müssen aber auch wirklich jedesmal dieselben Dateien wieder geändert werden.

Persönlich würde ich immer incrementals machen trotz dem höheren Risiko, falls auch nur eins davon defekt ist. Dann den Speicherplatz stattdessen lieber nutzen um entweder häufiger Fullbackups zu machen oder um weiter nach hinten noch restore-Punkte zu haben.

T00L schrieb:
Ich weiß schon, warum ich mit rsync inkrementell sichere und unveränderte Dateien als harte Links einfügen lasse...Da habe ich keine Abhängigleiten von früheren Backups und jedes Backup sieht wie ein Vollbackup aus!
Verstehe ich da was falsch?
Harte Links sind doch ein Verweis auf die Datei in einem anderen Backup, die Abhängigkeiten bleiben also bestehen.
Außer du kombinierst das mit einem Dateisystem, dass damit umgehen kann und sozusagen eine zentrale Ablagestelle für alle Dateien hat, auf die deine eigentlichen Backups nur noch verlinken, aber letztendlich losgelöst sind und nicht gelöscht werden bis der letzte Link auf die Datei gelöscht ist.
Veeam macht mit Block Cloning für synthetic fulls in ReFS Repositories auch nichts anderes.

Wenn jedes Backup wie ein Fullbackup aussieht ist das zum erstellen einer Backup-Kopie bequem und sonst eigentlich nichts.
 
  • Gefällt mir
Reaktionen: niteaholic, 1lluminate23, snaxilian und eine weitere Person
tollertyp schrieb:
Wenn sich viel ändert, verliert das inkrementelle Backup doch aber eigentlich seine Vorteile?
Warum? Wenn sich täglich viel ändert, hätte das differentielle Backup größere Probleme wegen dem mehr Verbrauch vom Speicher. Es gibt nicht die Beste Backup Methode. Es kommt immer auf die Rahmenbedingungen an und wie deine RPO, RTO und MAO Anforderungen sind.
In einer langen Kette von incr. Backups, hätte das differenzille den Vorteil das der Restore schneller wäre, denn es muss nur das letzte diff. Backup durchsucht werden.
Ergänzung ()

Differentielles Backup hat man früher eher gerne gemacht, wie man noch stark auf Tape gesichert hat.
Bei einer langen Kette von incr. Backups musste die Tapes viel gespuhlt werden, Start und Stop Opperationen über sich ergehen lassen, was die Lebenszeit stark verkürzte. Zudem den Restore extrem lange werden lies.
Band/Tapes waren und sind es auch jetzt noch zum Teil teuer und haben das Problem das sie gerne mal fehlerhaft sind. Vorallem wenn sie zu oft überschrieben werden.
Heute wird eher mit Backup to Disk gearbeitet, da kann man problemlos auf inkrementelles Backup zurückgreifen. Auch die Fehlerüberprüfungen sind heute deutlich besser und schneller als damals.

Auf Disk ist ein incr. Backup genauso sicher wie ein diff. Ich habe nur die diff. Methode empfohlen, weil bei 1Iluminate23 Bedenken wegen der Verkettung hatte. Oder anders, er kann davon auch mal ein diff. einfach so löschen, ohne seine Chain zu zerstören so lange das Full noch existiert.

Wie @Rickmer schon richtig sagt. Teste dein Backup nicht erst wenn du es wirklich brauchst. Sondern prüfe ob du einen Wiederherstellungsdatenträger hast, das dieser funktioniert und das du das Backup damit auch einlesen kannst.
Sollte auf dem System eine Datenbanken geöffnet sein, dann muss noch mehr beachtet werden.
Ein Image Backup ist ein crash consistent backup. Mehr nicht.
Ergänzung ()

Rickmer schrieb:
Veeam macht mit Block Cloning für synthetic fulls in ReFS Repositories auch nichts anderes.
Bei dieser Methode würde ich die Chain nicht zu lange werden lassen und regelmäßig ein Active Full reinhauen.
Das REFS ist mitlerweile stabil aber ist trotzdem nicht ganz ohne.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: PHuV und 1lluminate23
Sorry, ich dachte es geht um inkrementell vs vollständigem Backup. Inkrementell und differentiell sind ja in ihrer Philosophie eh schon recht nahe beieinander.
 
grand_sniper schrieb:
Differentielles Backup hat man früher eher gerne gemacht, wie man noch stark auf Tape gesichert hat.
Bei einer langen Kette von incr. Backups musste die Tapes viel gespuhlt werden, Start und Stop Opperationen über sich ergehen lassen, was die Lebenszeit stark verkürzte. Zudem den Restore extrem lange werden lies.
Band/Tapes waren und sind es auch jetzt noch zum Teil teuer und haben das Problem das sie gerne mal fehlerhaft sind. Vorallem wenn sie zu oft überschrieben werden.
Heute wird eher mit Backup to Disk gearbeitet, da kann man problemlos auf inkrementelles Backup zurückgreifen. Auch die Fehlerüberprüfungen sind heute deutlich besser und schneller als damals.
Das kann ich so bestätigen. In einer großen Behörde wurden Daten zuerst auf Disk, dann nach 7 Tagen auf Tape gesichert. 1 Tag FullBackup, 6 Tage inkrementell. Die Daten per Disk konnten immer zu 100% wieder inplace hergestellt werden, bei Tape lag die Wahrscheinlichkeit bei unter 50%. Hier mußten wir sehr oft den 2.Recovery-Weg über zusätzlich gesicherte Archive Logs (waren Oracle DBs), einschlagen, um erfolgreich zurücksichern zu können. Zum Glück verwenden heute immer mehr Kunden nur noch Disk-Sicherungen, die Herstellungswahrscheinlichkeiten liegt hier auch gefühlt bei fast 100%.
 
Rickmer schrieb:
Verstehe ich da was falsch?
Harte Links sind doch ein Verweis auf die Datei in einem anderen Backup, die Abhängigkeiten bleiben also bestehen.
Außer du kombinierst das mit einem Dateisystem, dass damit umgehen kann und sozusagen eine zentrale Ablagestelle für alle Dateien hat, auf die deine eigentlichen Backups nur noch verlinken, aber letztendlich losgelöst sind und nicht gelöscht werden bis der letzte Link auf die Datei gelöscht ist.
Veeam macht mit Block Cloning für synthetic fulls in ReFS Repositories auch nichts anderes.
Das schon, aber alles bleibt auf Dateisystemebe. Somit kann das Backup von jedem System gelesen werden ohne Abhängigkeit vom Backup-Programm. Kommt auch noch ein (proprietäres) Kontainerformat zum Einsatz, ist bei einem Fehler vielleicht der Kontainer defekt und alle abhängigen Backups zumindest unvollständig und vielleicht nicht mehr lesbar. Falls mal eine Datei defekt sein sollte, verliere ich nicht gleich mein ganzes Backup. Und für diesen Fall gibt es redundanzen auf anderen Datenträgern.
Für mich sollte die Wiederherstellung so einfach wie möglich sein mit minimalen Anhängigkeiten. Das ist bei rsync gegeben. Daten werden inkrementell gesichert und mit Dateisystemfeatures wird Platz gespart.
 
1lluminate23 schrieb:
Leider reichet mein Kenntnisstand nicht für rysnc, ich setze da lieber auf Macrium und Aomei
Such mal nach "RsyncBackup 1.3.3"
3.14, wobei ich mir bei der .14 nicht sicher bin.
Der Name führt leider zu vielen misses bei der Suche, aber das Tool kommt auch gut mit umfangreichen Dateisystemen klar und bietet halt ein incrementelles Backup mit Hardlinks auf unveränderte Dateien, so dass jedes Backup wie ein Vollbackup aussieht. Fühlt sich an wie Snapshot, isses aber nicht....

Ich komm derzeit nicht an meinen PC, und könnte somit bei Namen oder Version auch daneben liegen. Aber das kennt hier bestimmt auch der Eine oder Andere...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 1lluminate23
So @Home.

v.1.3. war die Version, Name war aber korrekt.

Die Linke auf die Seite des Authors ist

http://www.lupinho.net/

Das Tool läuft jetzt unter dem Namen HardlinkBackup (shreware), während RsyncBackup noch Freeware war.


Aber im Forenbeitrag
https://www.computerbase.de/forum/t...ur-daten-synchronisiert.1412142/post-17013146

gibt es einen Hinweis darauf, wo die alte Version noch zu bekommen ist.
http://web.archive.org/web/20110520075055/http://www.lupinho.net/rsyncbackup/

Das Tool macht einen etwas "spartanischen" Eindruck. Ist aber tatsächlich überaus hilfreich und super einsetzbar. Zum Preis des Datenverbrauches eines incremental Backups, erhält man sozusagen ein Generationen Vollbackup. Einzige Voraussetzung, das Zieldateisystem muss Hardlinks unterstützen (NTFS, Ext-x, BTRFS, ...)

Ich benutze es seit vielen Jahren immer mal wieder. Selbst immoment um 2 tägglich, automatisch die Datenpartition meines PS's auf ein Synology Verzeichnis zu backupen.

1635580590633.png
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 1lluminate23
Inkriminelle Backup´s halte ich nichts davon. Ist mir zu unsicher. Ich mache immer Vollbackup´s. Ich habe eine externe Festplatte mit 500 GB Speicher. Da paßt einiges drauf. Wenn es zuviele werden, lösche ich einfach ein paar alte wieder und schon ist wieder Platz da für neue Backup´s.
Ergänzung ()

Dieses Veam sieht gar nicht schlecht aus. Ist sogar ein Stand-Alone.
 
Zuletzt bearbeitet von einem Moderator: (Edit)
Inkrementelle Backups machen nur dann Sinn, wenn man sicherstellt, dass die Backup Chain regelmäßig durchläuft und die Verwaltung dem Backup Programm überlässt. Oder andersrum, der Platz muss vorhanden sein, damit schön die Backup Chain gebaut werden können, damit sie hinterher wieder ausaltern können.
 
  • Gefällt mir
Reaktionen: snaxilian
Zurück
Oben