Ich verwende rdiff-backup für ein System, auf dem auch Git-Repos liegen. Immer wenn sich irgendeine Kleinigkeit getan hat, sind die internen Datenstrukturen scheinbar völlig umgestellt. Das bläht die Backup-Inkremente unfassbar auf. Kann Git das auch besser?
Du Pedd, geht’s noch ein bisschen unfreundlicher? Man kann jemanden auch freundlicher (wenigstens neutral) darauf hinweisen, Stuss geschrieben zu haben, oder?
Von Verfluchtnochmal-05995bd7b am So, 27. Mai 2018 um 03:24 #
Es kann gar nicht unfreundlich genug sein wenn jemand "Ich verwende rdiff-backup für ein System, auf dem auch Git-Repos liegen" schreibt und dann ein Dummtroll daher kommt und "GIT ist kein Backup" antwortet
Von Verfluchtnochmal-05995bd7b am So, 27. Mai 2018 um 03:22 #
Was genau ist an "Ich verwende rdiff-backup für ein System, auf dem auch Git-Repos liegen" nicht zu verstehen und wie verdammt nochmal koot man dann auf die dumme Aussage "Git ist eine Versionierungs- und keine Backup-Software"?
Er fragt ob man GIT irgendwie dazu brigen kann nicht bei jedem Fliegenschiss soviele Änderungen zu schreiben damit die BACKUPS DES GIT REPOS nicht so aufgeblasen werden
"Immer wenn sich irgendeine Kleinigkeit getan hat, sind die internen Datenstrukturen scheinbar völlig umgestellt. Das bläht die Backup-Inkremente unfassbar auf. Kann Git das auch besser?" hat verdammtnochmal nichts damit zu tun dass auchnur irgendjemand davon spricht GIT ALS BACKUP zu benutzen
... für alle, die jetzt mit einer gewissen Überheblichkeit empfehlen, das Backup einfach mit Git zu machen: Nein! Die Lösung ist nicht immer, ein anderes Tool oder eine andere Distri zu empfehlen, Jungs! Das ist schwer albern Die existiernde Backuplösung arbeitet mit rdiff-backup, und das werde ich dafür auch nicht umstellen. Ich möchte vorallem _ein_ Backup, und nicht für jede Fuddelssoftware wieder was anderes. Und wie gut 'git clone' meine SVN-Repos und meine Wikis sichert, weiß ich nicht...
Was willst Du, ein File-backup sichert geänderte Daten das gilt für alles...ansonsten musst du zu Blocksicherung gehen (ala ZFS) Das kannst du nur optimieren wenn Du auf die daten schausst die du sichern willst in deinem fall excludieren vom rdiff und: Git clone = Git-backup SVN = Tar oder woanders replizieren (analog zu git) Wikis? Ich denke die spielst auf die DB an = Tar oder woanders replizieren (analog zu git)
Das problem ist weder rdiff noch Git, das Problem ist dass EIN backup-programm/Strategie niemals für alle Daten optimal sein kann
Ja gut, wenn's nicht geht, geht's nicht... Schade... Ich wollte ja nur mal fragen.
Für SVN, Wikis und einiges sonst funktioniert rdiff-backup halt ganz gut. Auch das Sql-Backup kann ich damit gut machen, wenn ich vorher mysqldump aufrufe und diesen Output ins Backup schiebe.
Nur für Git habe ich noch keine Strategie, die mittels rdiff-backup halbwegs erträglich effiziente Backups macht.
Klar 'kann' ich auch irgendwann die Flinte ins Korn werfen und für Git einen Sonderweg gehen. Ist halt nur nicht direkt schön...
Mit rdiff-backup wirst du in so einem Fall aber wohl nie ein effizientes Backup erreichen, mit so etwas wie urbackup stünden die Chancen erheblich besser.
Wow...das versteht jemand das Problem nicht, auch borg kann compression und deduplication, das bringt aber beides nix bei git repos und Bin-Datenbankdateien.
Wir haben in unserer Firma einen zentralen GIT-Server (CentOS-Kiste mit Zugriff per SSH, ein Ordner wo alle Repos drinliegen), welcher ohnehin per Hyper-V gesichert wird (jaja, das war nicht meine Entscheidung) - ich lasse aber auf einer exakten Kopie einmal am Tag alle Repositories spiegeln, ich gehe per Skript der gesamte Verzeichnis durch und pulle alle (alle Branches) oder clone neue - und habe somit dann eine Kopie Sind über 250 Repositories und klappt hervorragend.
Ich verwende rdiff-backup für ein System, auf dem auch Git-Repos liegen. Immer wenn sich irgendeine Kleinigkeit getan hat, sind die internen Datenstrukturen scheinbar völlig umgestellt. Das bläht die Backup-Inkremente unfassbar auf. Kann Git das auch besser?
Git ist eine Versionierungs- und keine Backup-Software.
Wow...wohl gar nichts verstanden oder?
Du Depp er spricht von Backups von GIT-Repos
Du Pedd, geht’s noch ein bisschen unfreundlicher? Man kann jemanden auch freundlicher (wenigstens neutral) darauf hinweisen, Stuss geschrieben zu haben, oder?
Es kann gar nicht unfreundlich genug sein wenn jemand "Ich verwende rdiff-backup für ein System, auf dem auch Git-Repos liegen" schreibt und dann ein Dummtroll daher kommt und "GIT ist kein Backup" antwortet
Also ich habe es mir nochmals durchgelesen und wie ich es verstehe, spricht der Mann von backups.
Was genau ist an "Ich verwende rdiff-backup für ein System, auf dem auch Git-Repos liegen" nicht zu verstehen und wie verdammt nochmal koot man dann auf die dumme Aussage "Git ist eine Versionierungs- und keine Backup-Software"?
Er fragt ob man GIT irgendwie dazu brigen kann nicht bei jedem Fliegenschiss soviele Änderungen zu schreiben damit die BACKUPS DES GIT REPOS nicht so aufgeblasen werden
"Immer wenn sich irgendeine Kleinigkeit getan hat, sind die internen Datenstrukturen scheinbar völlig umgestellt. Das bläht die Backup-Inkremente unfassbar auf. Kann Git das auch besser?" hat verdammtnochmal nichts damit zu tun dass auchnur irgendjemand davon spricht GIT ALS BACKUP zu benutzen
Gewöhnlich wird »git bundle« für Repository Backups genutzt!?
Git clone? Wohl das distributed nicht verstanden?
... für alle, die jetzt mit einer gewissen Überheblichkeit empfehlen, das Backup einfach mit Git zu machen: Nein! Die Lösung ist nicht immer, ein anderes Tool oder eine andere Distri zu empfehlen, Jungs! Das ist schwer albern
Die existiernde Backuplösung arbeitet mit rdiff-backup, und das werde ich dafür auch nicht umstellen. Ich möchte vorallem _ein_ Backup, und nicht für jede Fuddelssoftware wieder was anderes. Und wie gut 'git clone' meine SVN-Repos und meine Wikis sichert, weiß ich nicht...
Was willst Du, ein File-backup sichert geänderte Daten das gilt für alles...ansonsten musst du zu Blocksicherung gehen (ala ZFS)
Das kannst du nur optimieren wenn Du auf die daten schausst die du sichern willst in deinem fall excludieren vom rdiff und:
Git clone = Git-backup
SVN = Tar oder woanders replizieren (analog zu git)
Wikis? Ich denke die spielst auf die DB an = Tar oder woanders replizieren (analog zu git)
Das problem ist weder rdiff noch Git, das Problem ist dass EIN backup-programm/Strategie niemals für alle Daten optimal sein kann
Ja gut, wenn's nicht geht, geht's nicht... Schade... Ich wollte ja nur mal fragen.
Für SVN, Wikis und einiges sonst funktioniert rdiff-backup halt ganz gut. Auch das Sql-Backup kann ich damit gut machen, wenn ich vorher mysqldump aufrufe und diesen Output ins Backup schiebe.
Nur für Git habe ich noch keine Strategie, die mittels rdiff-backup halbwegs erträglich effiziente Backups macht.
Klar 'kann' ich auch irgendwann die Flinte ins Korn werfen und für Git einen Sonderweg gehen. Ist halt nur nicht direkt schön...
Mit rdiff-backup wirst du in so einem Fall aber wohl nie ein effizientes Backup erreichen, mit so etwas wie urbackup stünden die Chancen erheblich besser.
Wow...das versteht jemand das Problem nicht, auch borg kann compression und deduplication, das bringt aber beides nix bei git repos und Bin-Datenbankdateien.
Kommt drauf an WIE Deduplication umgesetzt ist
Goggle mal nach "emc variable-length deduplication"
Wir haben in unserer Firma einen zentralen GIT-Server (CentOS-Kiste mit Zugriff per SSH, ein Ordner wo alle Repos drinliegen), welcher ohnehin per Hyper-V gesichert wird (jaja, das war nicht meine Entscheidung) - ich lasse aber auf einer exakten Kopie einmal am Tag alle Repositories spiegeln, ich gehe per Skript der gesamte Verzeichnis durch und pulle alle (alle Branches) oder clone neue - und habe somit dann eine Kopie
Sind über 250 Repositories und klappt hervorragend.