Welche Root-Server Backup-Methode?

    Hallo zusammen,


    tl;dr: Wer kennt gute Backup-Methoden für einen netcup-root-Server RS 1000 G9.5?


    Langversion:

    Ich habe seit kurzem einen root-Server (RS 1000), den ich auch gerne mal ge-backupt haben möchte (ist noch nicht wirklich in Betrieb).

    Leider werde ich nicht so ganz schlau daraus, wie ich das bewerkstelligen kann; denn bei meinem bisherigen Anbieter, von dem ich

    hierher gewechselt bin gab es 30 Tage automatische Snapshots, um die ich mich nicht kümmern musste (ja, ich weiß snapshots

    sind keine "echten" Backups, aber das hat mir gereicht).


    So wie ich die verfügbaren Erklärungen bisher verstanden habe, sehen die Möglichkeiten wohl aktuell so aus:

    Mit den "inklusive-"Features ist es möglich, (manuell) ein Snapshot zu erstellen, und kann dieses auf einem FTP-Server "zu Gesicht" bekommen,

    so dass man es z.B. irgendwohin wegsichern kann.


    Das würde mir für den Anfang schon mal reichen. Ich habe aber noch nicht herausgefunden, wie man das scriptgesteuert hinbekommt;

    also den Snapshot anstoßen, den (jedes Mal anderen) Namen des Images ausfindig machen und dann wegsichern.


    Falls das ein Ding der Unmöglichkeit sein sollte (bzw. zu aufwendig), würde ich mich freuen, wenn mir jemand einen Tipp geben könnte,

    welche (bestenfalls) kostenlose Backup-Programme für (Ubuntu-)Linux zu empfehlen wären.


    Im Forum habe ich was von Bareos gelesen; hat hier jemand Erfahrung damit?


    Schön wäre es, so eine Art "incremental forever" auf irgendeinen Storage abzulegen. Die Backup-Tools, die ich beruflich so kenne, kann ich

    mir a) nicht leisten und wären hier auch b) definitiv überdimensioniert. Privat läuft zur Sicherung bei mir u.a. "dd", "duplicati" und "rsync";

    die haben aber in diesem Bereich alle so ihre Nachteile.


    Danke schonmal und
    Viele Grüße

    "incremental forever", da fällt mir direkt Veeam ein. Mit einer NFR Lizenz (kann man sich online klicken und kommt sofort per Mail) kannst du ewig incremental auf das erste Full "draufschaufeln". Veeam ist einfach und hält die Klappe. Mit v12 Ende diesen Jahres sogar auf S3 Storage

    sla Dein ewig mögen evtl. nur 365 Tage sein;

    so freizügig ist doch niemand und läßt sich mit TeraBytes an Backup-Daten kostenlos zumüllen, oder?

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Der TE hat nicht genau definiert wie viel Storage es zur Verfügung hat. Wo genau das Limit von Veeam ist keine Ahnung, weiter als ~150 TiB habe ich es noch nicht getrieben. Dann schaltet man eben die Rotation ein wenn der Backupspace begrenzt ist.


    Falls die 365 Tage auf die Laufzeit der NFR bezogen sind, ja das ist richtig. Die kann man aber beliebig oft verlängern.

    Danke Euch für die Infos!
    Ich schau mir schon mal restic (kam in zwei Antworten vor) und borg an...


    Und sorry für mein ungenaues und altmodisches "incremental forever": Da meinte ich nicht die Dauer,

    wie lange ich die Sicherung aufheben will, sondern nur "ewig" inkrementell sichern möchte. Ich geh' mal davon aus,

    dass das inzwischen schlicht alle Backupprogramme so machen und lass zukünftig diese Bezeichnung weg :)

    Das Backupalter liegt bei maximal einem Jahr und muss auch keine 365 Versionen haben.

    Hallo zusammen,
    kleines Feeback von mir: Ich bin mit "restic" zurechtgekommen und erst mal sehr zufrieden damit!

    Wen es interessiert: Das Backup geht jetzt mit restic per sftp und ssh-keys (via ~/.ssh/config) an eine Storage-Box, die ich noch "herumliegen" habe.

    Schön finde ich auch, dass der Speicher nur 2,7ms "entfernt" ist :) Hätte ich gar nicht gedacht.

    Danke und schönen Abend!

  • boberle

    Selected a post as the best answer.
    Quote from boberle

    Hallo zusammen,
    kleines Feeback von mir: Ich bin mit "restic" zurechtgekommen und erst mal sehr zufrieden damit!

    Wen es interessiert: Das Backup geht jetzt mit restic per sftp und ssh-keys (via ~/.ssh/config) an eine Storage-Box, die ich noch "herumliegen" habe.

    Schön finde ich auch, dass der Speicher nur 2,7ms "entfernt" ist :) Hätte ich gar nicht gedacht.

    Danke und schönen Abend!

    So ähnlich ist es bei mir auch. Jede Nacht läuft ein Skript, das alles auf eine Storagebox in Finnland sichert, das Repository aufräumt und den Status per Mail verschickt. Läuft schmerzfrei und hat sich bewährt. ;)

    Quote from Loxley

    Das kann ganz schlimme Nachteile haben, wie ein paar Leute beim Großbrand in Frankreich erfahren haben.


    Cloud-Speicher kostet nur Cents und ist mit restic in null,nichts angebunden.

    Jo das stimmt. Deshalb hat es mich auch überrascht, dass der Storage, der 150 km entfernt sein soll, nur eine ping-Laufzeit von 2,7 ms hat. Anhand der Lichtlaufzeit könnte das zwar plausibel sein, war aber überraschend. Ich tippe mal darauf, dass da die beiden beteiligten Provider ein direktes peering haben.

    Quote from boberle

    Jo das stimmt. Deshalb hat es mich auch überrascht, dass der Storage, der 150 km entfernt sein soll, nur eine ping-Laufzeit von 2,7 ms hat. Anhand der Lichtlaufzeit könnte das zwar plausibel sein, war aber überraschend. Ich tippe mal darauf, dass da die beiden beteiligten Provider ein direktes peering haben.

    Reden wir vom roten H? Wenn ja, die Nürnberg Server stehen bei denen im DC, daher hat auch Netcup ein direktes Peering nach FSN

    compi.dev

    Ein Mensch hat zwei Beine, ein Regenwurm hat keine.

    Mein Backup steht im Keller und jede Nacht werden alle "neuen" Daten auf ein Raid 5 System gezogen - rsync kümmert sich da sehr gut drum.
    Zusätzlich gibt es ein Backup aller Datenbanken der letzten 14 Tage, dann eins pro Woche. Muss reichen :)
    Im Falle eines Falles hätte ich Ausfallzeiten von 1-2 Tagen aber was soll schon passieren :D

    Quote from RAD750

    Reden wir vom roten H? Wenn ja, die Nürnberg Server stehen bei denen im DC, daher hat auch Netcup ein direktes Peering nach FSN

    Jo, rotes H stimmt! Und dass da ein Peering da ist, finde ich natürlich klasse :) (war ein paar Tage im Urlaub mit wenig Internet; deshalb die späte Antwort).