klassisches Backup - Speicherplatz

[goldene-zeiten]

Liebe KeyHelp-Freunde,

ich würde gerne neben dem Restic-Backup auch noch ein klassisches machen, da mich das mehr beruhigen würde. Also lokal auf dem Server ablegen und hin und wieder lokal archivieren.

Ausgangssituation: Frei: 225,94 GB Belegt: 185,51 GB Gesamt: 433,54 GB

Meiner Meinung nach sollte der Speicherplatz doch ausreichen? Ich habe auch maximale Kompression ausgewählt. Wie viel Speicher sollte denn frei sein? Bestünde das Problem auch, wenn man das Archiv remote speichert?

LG von

Hahni

[24unix]

Bestünde das Problem auch,

Welches denn?

[Tobi]

Das "alte" Backup ist deprecated und sollte für neue Projekte nicht mehr verwendet werden.

Nutze rsync für deine Backupidee.

[goldene-zeiten]

Das weiß ich ja. Drum muss ich das ja auch ausdrücklich im Backend freischalten. Nichtsdestotrotz finde ich ein klassisches Backup - bestehend aus FTP-Daten und Datenbank - prima und möchte die Funktion nutzen, so lange es geht...

[Florian]

Hallo,

wieviel Platz er genau will siehst du im Backup Log unter /var/log/keyhelp/backup

Die Kompression hat keinen Einfluss, denn vor dem Komprimieren muss er das Backup erstmal zusammenstellen. Wenn nicht genügend Platz ist hilft nur das /backup Verzeichnis auf einen anderen Datenträger zu mounten

[Tobi]

Du willst scheinbar alles bis zum St. Nimmerleinstag am Laufen halten .

rsync bietet gegenüber FTP viele Vorteile mit demselben Endergebnis.
Gerne auch mit grafischer Oberfläche.
viewtopic.php?p=21354#p21354

Aber bitte nicht mehr das alte Backup verwenden.
Das fällt über kurz oder lang endgültig raus.
Besser jetzt ohne Stress eine sichere Alternative suchen & finden als plötzlich überrascht festzustellen "Wo ist denn das alte Backup hin?"
Und ja ich weiß, du bist Systemintegrator, daher musst du diese Warnung nicht beachten.

An alle anderen Leser:
Besser ist es das alte Backup-System nicht mehr zu verwenden.

[goldene-zeiten]

Tobi, deine Argumente überzeugen mich. Ich folge später deinem Link und lese mich da mal ein.

[goldene-zeiten]

Die Lösung scheidet nunmehr definitiv aus. Der Speicherplatz ist zu knapp und selbst bei Remote-Speicherung muss der Speicherplatz erst einmal komplett zur Verfügung stehen. Das ist natürilch im Vergleich zu Restic ein sehr großer Nachteil.

[24unix]

und selbst bei Remote-Speicherung muss der Speicherplatz erst einmal komplett zur Verfügung stehen.

Warum?

Du musst das lokal nicht erst packen.

[goldene-zeiten]

Das kann man ja nicht einstellen bei der alten Lösung.

[24unix]

Das kann man ja nicht einstellen bei der alten Lösung.

Ich habe Dich so verstanden, dass Du Dich von der verabschiedet hast.

Ich sichere einen nicht-KH Account so:

Code: Select all

export RESTIC_REPOSITORY=sftp:restic@xxx.yyy.24unix.net:/tank/backup/Restic/yyy.de
export RESTIC_PASSWORD="aWeirdOne"

restic backup /path/to/folder
sleep 60

restic forget --keep-daily 30
restic prune

restic check

Funktioniert analog mit rdiff-backup oder rsync,

[goldene-zeiten]

Im Grunde genommen würde mir ein globales Backup wie das klassische Backup reichen. Denn das würde ich dann auch lokal mit speichern - für den Fall der Fälle, wenn mal was im RZ oder mit dem Repository von Restic falsch läuft. Aber das klassische Backup läuft ja bisher auf meinem Server nicht. Denn es wird wohl komplett zuerst lokal gespeichert und da reicht der Speicherplatz eben nicht aus

[24unix]

Im Grunde genommen würde mir ein globales Backup wie das klassische Backup reichen. Denn das würde ich dann auch lokal mit speichern - für den Fall der Fälle, wenn mal was im RZ oder mit dem Repository von Restic falsch läuft. Aber das klassische Backup läuft ja bisher auf meinem Server nicht. Denn es wird wohl komplett zuerst lokal gespeichert und da reicht der Speicherplatz eben nicht aus

Was spricht gegen ein Script, wie dass, dass ich ben gepostet haben?

Datenbanken dumpen, sichern.

/etc und /home, und gut ist.

Dass das normale Backup mehrere Stunden jeden Tag braucht nervt mich auch, überlege, das durch ein Script zu ändern.

Ich sehe keinen wirklichen Vorteil, erst lokal was zu packen, ausser, dass die Backup-Verfahren gehindert werden, ihre eigenen Algorithmen für inkrementelle Backups zu nutzen.

[goldene-zeiten]

Ich bin vollkommen bei dir. Restic möchte ich bei meinem zweiten parallelen Backup nicht im Einsatz haben. Das läuft zuverlässig und nach meinen Tests klappt auch der Restore. Finde es aber unpraktisch, dass es eigentlich immer der gleiche Software-Stand und auch die gleiche Hardware-Ausstattung sein muss. Aber dafür gibt es ja auch wieder triftige Gründe, warum das so ist.

Deshalb würde ich gerne ein klassisches Backup machen. Da würde es mir reichen, wenn - wie du es sagst - die FTP-Daten als auch die Datenbanken komplett gesichert sind. Bestehend aus FTP und eben den Datenbanken. Und Übertragung wahlweise mit FTP/SFTP oder WebDav. Ich bin eigentlich unkompliziert...

[24unix]

Ich bin vollkommen bei dir. Restic möchte ich bei meinem zweiten parallelen Backup nicht im Einsatz haben. Das läuft zuverlässig und nach meinen Tests klappt auch der Restore. Finde es aber unpraktisch, dass es eigentlich immer der gleiche Software-Stand und auch die gleiche Hardware-Ausstattung sein muss. Aber dafür gibt es ja auch wieder triftige Gründe, warum das so ist.

Deshalb würde ich gerne ein klassisches Backup machen. Da würde es mir reichen, wenn - wie du es sagst - die FTP-Daten als auch die Datenbanken komplett gesichert sind. Bestehend aus FTP und eben den Datenbanken. Und Übertragung wahlweise mit FTP/SFTP oder WebDav. Ich bin eigentlich unkompliziert...

Ich habe Dir mal das Repo zu meinem alten DB-backup-Script freigeschaltet, evtl. hilft es etwas:

https://git.24unix.net/tracer/backupdb