PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Bitte um Tips f. Server-Backup m. Deduplikation



Seiten : [1] 2

prostetnik
08.09.16, 17:26
Hallo,

habe mir einen Server quasi als NAS eingerichtet (noch nicht fertig), auf dem ich alle Dokumente, Videos, Bilder, eben alle Daten abgelegt habe.
Ich greife darauf per nfs4 mit Desktop-PC und Notebook zu. Per Notebook auch über vpn von außerhalb (oder ssh).

Als Server dient ein HP ProLiant MicroServer Gen8 Celeron G1610T, 4GB RAM.
Das System ist Ubuntu 16.04.1
Das mag für den einen oder anderen etwas Overkill sein - soll aber für mich auch zum lernen dienen.

Auf dem Server ist als Systemplatte eine 60 GB SSD am 5. Sata-Port
In den 4 Platten-Einschüben sind je eine 500 GB-Platte.
Die ersten beiden dienen als Daten-Platten im RAID1-Verbund
Die anderen beiden sollen als Backup-Platten ebenfalls im RAID1-Verbund dienen.
Viel Platz ist das nicht, aber späterer Plattentausch ist damit schon vorprogrammiert (gut zum Lernen).

Auf früheren Servern (alte PCs) habe ich mit rsnapshot gute Erfahrungen - sehr solide.
Doch einmal ein Video umbenennen verbrauchte dann gleich fast 1 GB mehr.
Also benötige ich in irgendeiner Form Deduplikation.

Habe schon viel recherchiert, konnte mich aber noch nicht entscheiden:

- Anfangs war ich von storebackup ganz angetan. Aber das scheint nicht weiter enwickelt zu werden...es ist sehr ruhig auf dem Portal

- Habe bereits Erfahrungen (auch unter Windows) mit Veeam Endpoint Backup FREE. Nicht schlecht - hat Vorteile. Das kann aber eben nur mit Veeam... gelesen werden. Da ist mir die "offene" Hardlink-Version sympathischer.

- Auch an ZFS auf den beiden Backup-Platten (als raid1) habe ich bereits gedacht. Zwar würde ich vermutlich nur bei Bedarf ein Backup durchführen - aber ich bin mir nicht sicher, ob ein Celeron G1610T mit 4GB RAM da ausreicht.

Was haltet Ihr davon?
Wie würdet Ihr solch ein System einrichten?

Vielen Dank im Voraus

gruß
prostetnik

marce
08.09.16, 18:43
Ganz anders.

Datensicherung erfolgt idealerweise auf ein ded. externes Medium, welches mit dem zu sichernden System möglichst wenig gemein hat - heute gern genommen sind externe USB- oder anderweitig anzuschließende Platten - und ja, wenn das Umbennen einer Datei viel Speicher benötigt dann ist das halt so (und mal ehrlich - 1 GB ist echt nicht die Welt bei TB-Platten nahezu im €-ct Bereich) - zudem ist das ja nicht zu tausenden übliches Verhalten von großen Dateien...

Dann noch min. einer weitere ext. Platte für die Sicherung der Sicherung und Du bist für fast alle Eventualitäten gerüstet. Wenn man auf exotische Dateisysteme und Verschlüsselung in der Sicherung verzichtet gibt's noch nicht mal Ärger beim zurückspielen...

fork
08.09.16, 19:10
Zu ZFS und Deduplikation gibt's nur eines zu sagen: Nimm's nicht. Braucht extrem viel Speicher(RAM).

Ein Backup-Programm mit Deduplikation ist z. B. BackupPC. Da ist es bzgl. Weiterentwicklung auch recht ruhig. Funktioniert aber gut.

Die Deduplikation ist aber eigentlich meist nicht ohne irgendwelche "Kosten". Im Falle von Backuppc ist es der regelmässige BackupPC_Nightly Job. BackupPC rödelt über alle Dateien des Backups drüber und schaut, was er löschen kann. Für den Fall ist es gut, dass Du auch die Backup-Platte im Server hast, weil das viel Platten-Performance braucht. Da das bei Dir wahrscheinlich alles noch übersichtlich ist vom Backupvolumen, wirst Du davon wahrscheinlich auch gar nicht so viel merken. BackupPC hat auch noch ein Webinterface, was sehr angenehm ist. Ich bekomme die Daten mit BackupPC reduziert um den Faktor 8-12.

Was marce sagt, ist natürlich sehr wichtig. Ein gutes Backup ist woanders als die Nutzdaten.

prostetnik
08.09.16, 19:22
Hallo marce,

danke für Deine Antwort.


heute gern genommen sind externe USB- oder anderweitig anzuschließende Platten
...davon hab ich auch schon'mal gehört ;-)

...bedenke, mir geht's natürlich auch um's Experimentieren - in Maßen.

Eine externe Sicherung habe ich zusätzlich als externe Festplatte über USB3 - das aber nicht extra erwähnt. Das geschieht dann aber seltener.
Es sollten einfach zu handhabende Backups, ohne an- und abstöpseln, sein. Prinzipell wäre natürlich ein externer Backup-Server sinnvoller, aber das würde für mich dann doch Overkill bedeuten.

Zur Deduplikation:
Es geht ja beim Umbenennen nicht nur um einzelne Dateien - sondern im schlimmsten Fall auch um ganze Verzeichnisse und mir auch um's Prinzip.

Aber hast Du Erfahrungen mit zfs oder storbackup?

florian0285
08.09.16, 19:30
Ich bin mir nicht zu 100% sicher, aber rsnapshot verlinkt beim Umbenennen dennoch auf das Original via Hardlink. Ergo kein Speicherzuwachs. Da ändert sich vermutlich am File selbst was.

Davon abgesehen... welche Anforderungen stellst du genau an die Backup Software?

prostetnik
08.09.16, 19:38
Hallo fork,

BackupPC hatte ich auch schon im Visier. Das schien mir aber zu gewaltig, eher für größere Landschaften. Aber vielleicht täusche ich mich ja.
Soweit ich weiß, arbeitet das auch mit hardlinks. Habe gerade heute wieder darüber gelesen.

Wie geht BackupPC mit großen Image-Dateien um?

StoreBackup kann die aufsplitten und nur die veränderten Teile sichern - finde ich schon genial, z. B. bei 17 GB großen VMs macht das für mich Sinn.
Werd'mich einmal damit näher befassen.

Aber danke für Deinen tip.

gruß
prostetnik

prostetnik
08.09.16, 19:46
@florian0285


Ich bin mir nicht zu 100% sicher, aber rsnapshot verlinkt beim Umbenennen dennoch auf das Original via Hardlink.
Das ist mir nicht bekannt.

Würde ich /srv/Videos in /srv/film (theoretisch) umbenennen, so würde der komplette Pfad mit rsnapshot neu angelegt.
Das kann eben nur StoreBackup oder evtl. BackuPC (weiß ich noch nicht).

gruß
prostetnik

fork
08.09.16, 19:58
Das schien mir aber zu gewaltig, eher für größere Landschaften. Aber vielleicht täusche ich mich ja.
BackupPC ist eher übersichtlich zu konfigurieren. Es sichert per SSH/Rsync. Es kann auch noch mehr. Aber ich nutze nur rsync über ssh. Manches mag etwas gewöhnungsbedürftig sein. Im grossen und ganzen ist es ein alter Perl-Klotz, der für mich in vieler Hinsicht bzgl. der Nutzung sehr gut abschneidet.


Soweit ich weiß, arbeitet das auch mit hardlinks. Habe gerade heute wieder darüber gelesen.

Hardlinks werden verwendet um identische Dateien zu speichern.



Wie geht BackupPC mit großen Image-Dateien um?
prostetnik

Eine Imagedatei ist auch eine Datei. Nix aussergewöhnliches.

prostetnik
08.09.16, 20:11
...habe aber gerade gelesen, dass BackupPC Dateien größer 4 GB (http://www.pro-linux.de/artikel/2/1183/6,backuppc-als-backupserver-im-heimnetzwerk-wiederherstellung.html) nicht sichert, zu splitten scheint es auch nicht - oder?
Damit würde dann jede VM nach Benutzung neu gesichert werden.

fork
08.09.16, 20:15
Ich sichere keine VM-Images damit. Die Deduplikation bei BackupPC findet auf Dateiebene statt, wäre damit für VM-Images bestensfalls unwirkksam bei BackupPC.

prostetnik
08.09.16, 20:19
...wie sicherst Du Deine VMs?

Habe halt mein VMs ebenfalls auf dem Server, damit ich sie auch auf allen PCs nutzen kann.

marce
08.09.16, 20:19
...habe aber gerade gelesen, dass BackupPC Dateien größer 4 GB (http://www.pro-linux.de/artikel/2/1183/6,backuppc-als-backupserver-im-heimnetzwerk-wiederherstellung.html) nicht sichert, zu splitten scheint es auch nicht - oder?
Damit würde dann jede VM nach Benutzung neu gesichert werden.
6 Jahre alte Artikel müssen nicht zwingend aktuell sein :-)

Immerhin verlinkt er noch auf die richtige Doku, mit der man das evtl. ein wenig besser einordnen kann, ob man von irgendwelchen Limits betroffen sein könnte... http://backuppc.sourceforge.net/faq/limitations.html

fork
08.09.16, 20:22
Hier ist was genaueres:

http://backuppc.sourceforge.net/faq/limitations.html#maximum_backup_file_sizes

Kommentare dazu:

* Nicht "tar" - Als Transportmethode verwenden.
* Schauen ob perl "largefilesupport" aktiviert hat

Trotzdem würde ich BackupPC nicht für Imagedateien verwenden. Deduplikation auf Dateiebene greift da nie, da sich Imagedateien immer ändern.

Vielleicht wäre da etwas mit zfs/btrfs-snapshots gut. Ein Snapshot enthält nur geänderte Daten eines Dateisystems. Was es da für Lösungen gibt, kann ich Dir nicht sagen.

prostetnik
08.09.16, 20:35
Deduplikation auf Dateiebene greift da nie, da sich Imagedateien immer ändern.
ist mir schon klar - deswegen ja StoreBackup. Ob es funktioniert, weiß ich allerdings auch nicht. Ich habe es mal vor ein paar Jahren getestet, aber nicht im alltäglichen Gebrauch.

Aber zurück zu meiner Frage:
Wie sicherst Du Image-Dateien?

marce
08.09.16, 20:39
Meine Privat-persönlichen Erfahrungen mit ZFS unter Linux sind leider so rein gar nicht in der Art, daß man das System empfehlen könnte.

... und die Raid-Features unter BTRFS sollte man wohl noch mal gegenchecken, ob die "minimalen" :-) Bugs darin inzwischen gefixed sind.


Dazu die kleine Erkenntniss aus den letzten +20 Jahren IT: Meistens funktioniert eine Backuplösung nur zu max. 90% für alles nach Wunsch. Es gibt immer Exoten-Daten, für die man irgendwelche Sonderlösungen braucht. Kann also gut sein, daß Du für Images idealerweise eine eigene Backuplösung suchst, die damit gut und besser umgehen kann als Lösungen, die eher für tägliche-Arbeitsdateien gedacht sind...

florian0285
08.09.16, 21:26
@florian0285


Das ist mir nicht bekannt.

Würde ich /srv/Videos in /srv/film (theoretisch) umbenennen, so würde der komplette Pfad mit rsnapshot neu angelegt.
Das kann eben nur StoreBackup oder evtl. BackuPC (weiß ich noch nicht).

gruß
prostetnik
Richtig das Verzeichnis wird neu angelegt, aber der Inhalt zeigt trotzdem auf die Originaldatei via Hardlink. Vorausgesetzt du benutzt ein entsprechendes Filesystem, welches Hardlinks unterstützt und der Inhalt wurde nicht verändert. So gesehen ist die Datei im Backup nur einmal vorhanden obwohl mehrfach gelistet. Der Eintrag für das neue Verzeichnis dürfte ja nur gefühlt 1Kb groß sein.

Zur Info:
https://de.m.wikipedia.org/wiki/Harter_Link

Zusätzlich kann ich die Aussage von marce nur stützen.

fork
08.09.16, 21:47
Wie sicherst Du Image-Dateien?

Im Grossen und Ganzen: Gar nicht. Bis auf ein paar Windows VMs, bei denen es gar nicht anders geht.
Ist bei der Wiederherstellung etwas aufwändiger. Kommt allerdings auch nicht so oft vor.

Grundsätzlich würde ich das so machen, dass ich die VMs nachts mal herunterfahre und auf ein ZFS/btrfs exportiere. Das ganze in Kombination mit einer persönlich zu wählenden Anzahl und Häufigkeit von Dateisystem-Snapshots. Damit ist das Ganze sehr speichereffizient. Das sollte nicht all zu schwer zu skripten sein. Natürlich sind Imagebackups für ein Disaster-Recovery wesentlich zeitsparender und einfacher zu handhaben, als Dateibackups.


Meine Privat-persönlichen Erfahrungen mit ZFS unter Linux sind leider so rein gar nicht in der Art, daß man das System empfehlen könnte.

Einer meiner Backupserver(~10 TB) läuft mit BackupPC und ZFS(Debian + zfsonlinux). Am Anfang vor 2 Jahren hat's mit den ersten Versionen von zfsonlinux einen Fehler gehabt, der einen gelegentlichen Neustart des Servers erfordert hat. Doch nach 1-2 Monaten war das auch gefixed und seit dem läuft das Ding rund.(Festplatten glühen 24/7). Nie was gehabt. Es gibt auch ab und an Mal ZFS-Updates(per apt-get upgrade), die auch kleinere Dateisystem-Updates mit sich bringen. Bisher nie ein Problem.

Was btrfs betrifft: Es gibt davon stabile Features und es gibt da experimentelle Features. Bei ersteren gibt es viele Leute, die das produktiv im Einsatz haben. Im Debianforum (http://www.debianforum.de) gibt's da ein paar Spezialisten und auch einige Beiträge zu dem Thema. Von den experimentellen bzw. in Entwicklung befindlichen Features sollte man immer die Finger lassen.

storbackup

Ich habe da in einem Heise-Artikel was von MD5-Summen gelesen. D. h.: Deduplikation auch nur auf Dateiebene.

florian0285
08.09.16, 21:53
Betrachte die VM's doch als physikalisches System und implementiere ein entsprechendes Backup-Konzept innerhalb dieser VM.

prostetnik
08.09.16, 22:46
Man, hier brummt aber heute das Forum.
Komme mit dem Beantworten garnicht hinterher - vielen Dank erst noch einmal für Eure tolle Hilfe



@florian0285


Richtig das Verzeichnis wird neu angelegt, aber der Inhalt zeigt trotzdem auf die Originaldatei via Hardlink.

also, das würde mich wirklich wundern. Rsnapshot sammelt ja nicht die Dateinamen und kreiert dann den Hardlink - arbeitet ja auch nicht mit einer Datenbank, um die Dateien miteinander zu vergleichen. Stell Dir vor in zwei unterschiedlichen Pfaden Dateien gleichen Namens unterschiedlichem Inhalts.
Das macht eben StorBackup.
Rsnapshot vergleicht lediglich die URL einer Datei und die Attribute, so wie ich das verstehe.


Betrachte die VM's doch als physikalisches System und implementiere ein entsprechendes Backup-Konzept innerhalb dieser VM.
Daran habe ich auch schon gedacht. Das wäre aber wieder aufwändiger. Darüber hinaus wüsste ich nicht wie dann ein restore einfach zu handhaben wäre - mit einer vm???!! :-(
Ich scheue mich nicht mit einigem Aufwand das einmal zu konfigurieren oder mich irgendwo einzulesen. Später sollte das aber mit möglichst nur einem Befehl laufen.


@fork


Grundsätzlich würde ich das so machen, dass ich die VMs nachts mal herunterfahre und auf ein ZFS/btrfs exportiere. Das ganze in Kombination mit einer persönlich zu wählenden Anzahl und Häufigkeit von Dateisystem-Snapshots
So ähnlich hätte ich mir das vorgestellt.

Und was sagst Du zu den Serverdaten Celeron G1610T, 4GB RAM?? bei zur zeit 500 GB Daten?
Schafft der das?


storbackup
Ich habe da in einem Heise-Artikel was von MD5-Summen gelesen. D. h.: Deduplikation auch nur auf Dateiebene.
...aber über unterschiedliche Pfade und Partitionen hinweg - wenn ich das richtig in Erinnerung habe.

ThorstenHirsch
08.09.16, 23:01
Meine Privat-persönlichen Erfahrungen mit ZFS unter Linux sind leider so rein gar nicht in der Art, daß man das System empfehlen könnte.
Verrätst Du uns wann das war, mit welcher Distribution und ZFS-Version? Ich hatte nämlich gehofft, dass jetzt, wo es ZFS offiziell in Ubuntu 16.04 gibt, die Sache stabil läuft.

florian0285
08.09.16, 23:08
Du solltest dir etwas Doku zu rsync anschauen, worauf rsnapshot zugreift. Der Abgleich erfolgt nach dem Inhalt der Daten.

https://de.m.wikipedia.org/wiki/Rsync

Dein Beispiel verstehe ich nicht. Zwei Dateien mit unterschiedlichem Inhalt, in unterschiedlichen Verzeichnissen, aber gleichem Namen sind zwei unterschiedliche Dateien. Auch wenn ich StorBackup nicht kenne wird keine Backup-Software diese Zusammenführen.

Du solltest mal die Anforderungen an die Lösungsneutrale "Software" definieren bevor Missverständnisse zu einer falschen Wahl führen.

Die VM Geschichte ist Aufwendiger aber u. U platzsparender. Snapshots sind eine Alternative, sowie Vollbackups. Das liegt an dir das ganze Abzuwägen. Du kannst Betriebssystem spezifische Tools verwenden um diese Backups durchzuführen und entsprechend auch den Restore. Die VM ist egal. Das wird gehandhabt wie bei einer physikalischen Maschine.

Möglichst nur ein Befehl? Davon würde ich ggf. Abstand halten. Der Do-It-All-Button war nie sehr überzeugend.

fork
08.09.16, 23:14
... disaster-recovery einer vm aus dateien ...
Ich scheue mich nicht mit einigem Aufwand das einmal zu konfigurieren oder mich irgendwo einzulesen. Später sollte das aber mit möglichst nur einem Befehl laufen.


Disaster-Recovery aus Dateien ist schon etwas komplexer als nur Image Backup Restore. Du musst Dateisysteme erzeugen(und wissen welche das sein müssen), Dateien kopieren, boot-loader-Konfiguration anpassen, fstab anpassen, bootloader installieren). Ein Projekt, dass sich das auf die Fahnen geschrieben hat ist rear (http://relax-and-recover.org/).


Der Do-It-All-Button war nie sehr überzeugend.

Hört sich für mich wie 'ne typische Linuxer-Krankheit an: Es muss richtig weh tun! Du brauchst einen Befehl mit 395 Kommandozeilenschaltern. Davor musst Du noch eine Konfigurationsdatei erstellen und Dir mit awk und perl irgendwelche Ausgaben zurechtparsen.

Hä? WTF?

Wenn ich eine Disaster-Recovery brauche, dann brennt schon auch mal die Luft. Dann will ich ein Backup haben, was mit wenigen Handgriffen einfach funktioniert. Dann will ich, dass es automatisiert ist und sehr einfach funktioniert. Auch ein normales Backup soll einfach funktionieren: Ich navigiere mich durch Pfade und Backupzeit klicke die benötigten verzeichnisse an und klicke auf restore. Fertig!(So funktioniert Backuppc) Genau so will ich persönlich das haben. Im übrigen gibt es ja vielleicht auch manchmal den Kollegen oder Stellvertreter, der sich nicht so gut mit Linux auskennt. Umso einfacher die Handhabung ist, umso besser für diesen.


Und was sagst Du zu den Serverdaten Celeron G1610T, 4GB RAM?? bei zur zeit 500 GB Daten?
Schafft der das?


Ja, denke schon. Wenn Du nicht anfängst die Images zu komprimieren, dann geht das. Ich würde aber trotzdem die Dateisystemkompression ausprobieren. (Bei ZFS: lz4 (automatisch ausgewählt) Bei btrfs: lzo (viel schneller als zlib, komprimiert nicht so gut, lz4 ist bei btrfs noch work-in-progress). Die CPU ist jetzt eher schwachbrüstig, deswegen lieber die schwächere Komprimierung.

marce
08.09.16, 23:37
Verrätst Du uns wann das war, mit welcher Distribution und ZFS-Version? Ich hatte nämlich gehofft, dass jetzt, wo es ZFS offiziell in Ubuntu 16.04 gibt, die Sache stabil läuft.
Genaues OS habe ich gerade nicht zur Hand, müsste ich nachfragen - spontan ich vermute ein *buntu LTS, Versions- und Patchlevel müsste ich ebenso nachfragen. Wurde nicht von mir betreut, ich hab' das Ding nur als NFS-Share zur Verfügung bekommen.

Lief bis vor kurzem, also so ca. bis Q1, 2016.

Problem war einfach, daß das System selbst im Betrieb immer mehr Last verursachte und irgendwann mit den internen Caches durcheinander kam. Wurde zwar von Patchlevel zu Patchlevel immer besser aber nie so, daß das System dauerhaft zum prod. Betrieb geeingnet gewesen wäre - unnatürlich hohe Load des Hosts, im Laufe der Uptime ansteigende Zahl / Häufung von TimeOuts, Einbrüche / sinkender Read- und v.o. Write-Durchsatz mit zunehmender Uptime, merkwürdiges Cache-Verhalten bei mehrmaligem Zugriff, Sync-Probleme bei Write und direkt nachfolgendem Read, ...

Das Verhalten trat aber erst über höhere Betriebszeiten auf, also nicht am Anfang, als es eingerichtet wurde sondern im Laufe der Zeit, als die Daten- und Dateimengen immer weiter anstiegen.

Nachdem wir das Datenshare dann auf "etwas konservativeres Dateisystem" migriert hatten war die Welt wieder in Ordnung.

ThorstenHirsch
08.09.16, 23:57
Oh, das ist dann ja ziemlich aktuell. Schade. Wir wechseln gerade von Solaris nach Linux (RHEL) und werden ZFS wohl vermissen. "Meine" Admins haben sich ganz konservativ für ext4 entschieden.

prostetnik
09.09.16, 00:10
@florian0285


Auch wenn ich StorBackup nicht kenne wird keine Backup-Software diese Zusammenführen.

"Erkennen von identischen Dateien (Doubletten) in unterschiedlichen, unabhängigen Backups (z.B. von unterschiedlichen Rechnern)"
schau einmal hier (http://www.nongnu.org/storebackup/de/node2.html)
Bin mir aber nicht sicher, ob ich das getestet habe (vor 2 Jahren)... ist auch schon spät ;-) habe schon rechteckige Augen


@fork

Disaster-Recovery aus Dateien ist schon etwas komplexer als nur Image Backup Restore.
glaube, da ist ein Missvertändnis:
Ich meinte nicht Server-VMs sondern konkret z. B. eine
/mnt/server/KVMs/images_libvirt/win7pro86.qcow2
die auf meinem Server liegt und mit der eben Win7 läuft.

Aus dieser *vm heraus*, wie von florian0285 vorgeschlagen, könnte ich durchaus z.B. über veeam ein inkrementelles Backup erstellen. Nur ein bare metal restore (bezogen auf die vm) stelle ich mir hier kompliziert vor - wenn's überhaupt geht

Nur so nebenbei:
Einen Daten-Server in einer VM laufen zu lassen, das Backup in einer weiteren VM, ggf. mit einer 3. VM z. B. als Kerberos-Server war auch schon eine Überlegung.
Aber ich weiß nicht, ob die Performance ausreichend wäre (bei obigen Server-Hardware-Daten)

florian0285
09.09.16, 13:11
Du beschreibst aber keine doppelten Files, das was du da beschrieben hast sind zwei unterschiedliche mit gleichem Namen. [emoji1] Is aber auch egal, das kommt in die Missverständnis Schublade.

Meiner Meinung nach wäre es sinnvoller die Duplikate bereits vor dem Backup zu "entfernen", als dies ständig in jedem Backup zu tun. Als Ansatz wäre es z. B. mit fdupes und Hardlinks möglich:

fdupes -rL /path/to/dir

Wenn das dann zuverlässig läuft könnte man dies als Cronjob vor dem eigentlichen Backup laufen lassen.

Deine Ansicht zum rsnapshot-Verhalten ist für mich immernoch nicht nachvollziehbar. Aber mit fdupes dürftest du das dann auch umgangen haben.

Thorashh
09.09.16, 13:17
Moin
Nutzt hier wirklich niemand Borgbackup (https://borgbackup.readthedocs.io/en/stable/)?
Deduplication auf Blockebene mit variabler Blockgröße.
Thorashh

prostetnik
09.09.16, 13:38
Hallo florian0285,

ja, ich dachte an die doppelten files, die erst auf dem Backup-Server entstehen, weil rsnapshot nicht erkennt, wenn sie verschiedene URLs oder Namen haben - StoreBackup erkennt das (m. E.) und bildet hardlinks (s. o.). Bei BackupPC weiß ich's nicht.

Mein obiges Beispiel (http://www.linuxforen.de/forums/showthread.php?280070-Bitte-um-Tips-f-Server-Backup-m-Deduplikation&p=1840108&viewfull=1#post1840108) war unsinnig, weil ja rsnapshot, wie erwähnt, anhand der Datei-Attribute den unterschiedlichen Inhalt erkennen würde.
War halt schon spät ;-)

Duplikate bereits vor dem Backup zu entfernen ist natürlich auch sinnvoll - das habe ab und zu mit fslint gemacht.

gruß
prostetnik

prostetnik
09.09.16, 13:40
Hallo Thorashh,

Borgbackup kenne ich nicht - das schaue ich mir'mal an.

danke für den Tip

edit:
scheint ja ein sehr heißer Tip zu sein

Huhn Hur Tu
13.09.16, 09:07
Borg ist seeehr nice, hier ein kleines Beispiel


#!/bin/bash

## Some Variables
Datum=$(date "+%A-%H-%M")
BorgBinary="$HOME/bin/borg-linux64"

## Do the Backup
nice -n 19 $BorgBinary create -x -p -v --stats --compression zlib,8 \
/backup/desk/home::$Datum $HOME \
--exclude svn \
--exclude git \
--exclude deploy \


nice -n 19 $BorgBinary create -x -p -v --stats --compression zlib,8 \
/backup/desk/etc::$Datum /etc

## Remove Older
# Keep last Backup of an hour for 72 Hours
# Keep Last Backup of the Day for 14 Days
# Keep Last Backup of the Week for 6 Week
# Nothing needed would deleted, only unused chunks would removed
nice -n 19 $BorgBinary prune --keep-hourly=72 --keep-daily=14 --keep-weekly=6 \
/backup/desk/home

nice -n 19 $BorgBinary prune --keep-hourly=72 --keep-daily=14 --keep-weekly=6 \
/backup/desk/etc



Das lasse ich einmal die Stunde laufen, dauert ca. 1 Minute wenn nicht viel dazu gekommen ist.
Es haelt die letztenb 72 Stunden alle Backups vor, die letzten 14 Tage jeweils das letzte des Tages und die letzten 6 Wochen das letzte Backup der Woche.

Dann kann man jeden Stand einzeln mounten und hat den Stand fuer das Ganz Verzeichniss, ist wirklich geil und vor allem schnell.
Kann auch encryption, compression, ...