Hi zusammen, in meinem Server werkelt ein HP C7438A (DAT72), welches nach 2 Jahren langsam keine bänder mehr lesen & schreiben kann. Zuerst dachte ich an bandverschleiß, hab 10 nigelnagelneue Bänder besorft, das laufwerk kann kein einziges davon auch nur erkennen (die alten aber schon, aber da krieg ich nach kurzer zeit Schriebfehler) Vorher hatte ich ein anderes DAT-Laufwerk, ebenfalls nach wenigen Jahren Ausfall. Kritisch ist das ganze, weil da nicht nur mein privates Backup läuft, sondern auch das meiner Firma. zum Einen frage ich mich, ob sich sowas reparieren (oder wenigstens "überholen") lässt, um etwas zeit zu gewinnen. Einschicken und wochenlang darauf warten ist eher keine Alternative. Behandelt hab ich es gut, tägliches Backup (Sonntags Gesamtsicherung, Mo-Sa inkrementelle Sicherung), einmal wöchentlich Bandwechsel (Vollsicherung beginnt immer neues band), gleichzeitig mit dem Bandwechsel immer Reinigungsband. insofern bin ich schon etwas enttäuscht, dass das teil schon wieder den Geist aufgibt. Zum Anderen überlege ich, welche Alternativen es gibt: - Backup in die Cloud: Meine Daten sollen nicht bei der NSA liegen... - Backup auf Disk: RAID-5 vorhanden, Daten sind doppelt redundant, aber eben nicht sauber historisiert - Backup auf externe USB-Disk: wie historisieren und gegen Überspannung sichern? Bevor jetzt wieder jeder schreit "nimm eine billige USB-Disk": ich hab 10 Bänder, damit 10 Wochen zurück eine Sicherung. Es kommt leider recht oft vor, dass Kollegen versehentlich etwas löschen oder falsch überschreiben, und man kommt nach einem Monat drauf... Weiters sind die nicht eingelegten Bänder recht sicher gegen Blitzschlag, Überspannung und sonstige Widrigkeiten. Von Zeit zu Zeit wandert auch ein Band in den Tresor außer Haus, also auch eine gewisse Sicherheit gegen Großbrand. Ich bin nicht sicher ob ich mir 10 externe USB-Disks antun will... Für Vorschläge jeder Art sehr dankbar!
Michael Reinelt schrieb: > Bevor jetzt wieder jeder schreit "nimm eine billige USB-Disk": ich hab > 10 Bänder, damit 10 Wochen zurück eine Sicherung. Bei gerade mal 36 GB Kapazität pro Band würden ja schon fast USB-Sticks aus der 20-EUR-Klasse genügen. Sicher, ein "DAT72"-Band kostet nur etwa 6 EUR, aber ... die Probleme kennst Du ja jetzt. Wenn Band, dann LTO. Das ist zuverlässig und langzeitstabil, mit DAT ... macht man interessante Erfahrungen. Du nutzt ja bereits inkrementelle Backups - die lassen sich auch auf anderen Backupmedien als Bändern verwenden. Ich nutze so etwas auf einem Server, der mit Acronis gesichert wird. Daran angeschlossen ist eine USB-Platte, die alle paar Wochen durch eine andere ersetzt wird; der Pool ist fünf Platten groß. Beim Anschluss einer Festplatte wird diese gelöscht und ein Komplettbackup erstellt. Danach gibt es jeden Tag ein inkrementelles Backup. Das läuft vollautomatisch ab, und es kann der Stand jedes beliebigen Tages rekonstruiert werden. Bei einer Verweildauer von etwa einem Monat und vier im Schrank liegenden Sicherungsplatten sind also vier Monate rekonstruierbar - bzw. je nach Füllstand der im Gebrauch befindlichen Platte bis zu fünf. Damit lassen sich auch deutlich größere Datenmengen als die 36 GB handhaben, die auf so ein "DAT72"-Band passen, und etwas flotter ist es obendrein.
Welcher Datenmenge entspricht denn eine Gesamtsicherung? DAT ist als Backupmedium generell nicht mehr das Mittel der Wahl. Je nach dem, ob sich dein Laufwerk in den Jahren etwas dejustiert hat kannst du deine Bänder nur noch mit diesem einen Laufwerk lesen. Bei einem Großbrand o.ä. mit Verlust des Laufwerkes sind deine extern gelagerten Backupbänder also u.u. Nutzlos. Eine Preiswerte alternative wäre zum Beispiel ein Laufwerk, wie „Dell PowerVault RD1000“ Das ist schneller, als DAR72 und relativ gut verfügbar...
Michael Reinelt schrieb: > - Backup auf externe USB-Disk: wie historisieren und gegen Überspannung > sichern? Windows => "Hardlinkbackup". Inkrementelle Backups mit Versionierung. Die Backups sind dank der Verwendung von Hardlinks jeweils ein vollständiges Abbild des Originals, wodurch ein spezielles Restore-Programm entfällt. Mit USB-Disk ebenso verwendbar wie mit NAS. Im professionellen Umfeld ist LTO auch eine sinnvolle Wahl, aber teuer. Dafür aber zuverlässig - als Medium gesehen, die Bandlaufwerke können auch kaputt gehen. Bandlaufwerke setzen eine leidlich kontrollierte Umgebung voraus. Räume mit Rauchern oder extremen Temperaturen sind nicht ratsam.
:
Bearbeitet durch User
Michael Reinelt schrieb: > Ich bin nicht sicher ob ich mir 10 externe > USB-Disks antun will... Aber 10 Bandmedien schon? Wo ist der Unterschied, zumal wenn du den Gesamtpreis in Relation setzt? Eine USB Disk, die ein DAT72 ablösen kann, kostet nicht mehr viel.
Michael Reinelt schrieb: > ...gleichzeitig mit dem Bandwechsel immer Reinigungsband... Und genau mit dem hast Du den Kopf abgefräst. Kein Wunder also.
Michael Reinelt schrieb: > in meinem Server werkelt ein HP C7438A (DAT72), welches nach 2 Jahren > langsam keine bänder mehr lesen & schreiben kann. It's not a bug, it's a feature. HP hat die Dinger so gebaut, daß sie nach spätestens 2 Jahren den Dienst einstellen. Jedenfalls ist das auch meine Erfahrung mit HP DAT-Laufwerken, die verhielten sich ausnahmslos alle so. Ansonsten stimme ich den Vorrednern zu, Streamer sind obsolet und den Datenmengen kaum noch gewachsen. Von WD gibt es handliche USB-Platten im 2,5"-Format (WD Elements), die erfahrungsgemäß auch ohne separate Stromversorgung zuverlässig funktionieren und nicht viel größer sind als eine Zigarettenschachtel.
Ein aehnliches Problem habe ich mit meinem Audio-DAT. Neue Kasetten kann ich problemlos neu bespielen. Jedoch beim abspielen der aelteren Baender gibt es ein deutliches Jitter. Das aergert mich. Auch eine komplette Neuanschaffung eines (gebrauchten) Sony DAT brachte nur eine kurzfristige Loesung. Ich habe jedenfalls kein "Sandpapierband" benutzt. Koennten evtl. Koppelkondensatoren der Ausschlaggebende Punkt sein ? Gruss Asko.
Markus L. schrieb: > Michael Reinelt schrieb: >> ...gleichzeitig mit dem Bandwechsel immer Reinigungsband... > > Und genau mit dem hast Du den Kopf abgefräst. Kein Wunder also. Äh... ich war brav und hielt mich an die Vorgaben. Heisst das, ich war brav, aber dumm?
A. K. schrieb: > Michael Reinelt schrieb: >> - Backup auf externe USB-Disk: wie historisieren und gegen Überspannung >> sichern? > > Windows => "Hardlinkbackup". Sorry, ich vergaß zu erwähnen: Linux. Linux only.
Michael Reinelt schrieb: > Sorry, ich vergaß zu erwähnen: Linux. Linux only. Noch einfacher, da kommt das Verfahren ja ursprünglich her: "rsync", am einfachsten in Form von "rsnapshot".
:
Bearbeitet durch User
Ich bin auch der meinung das Dat mitlerweile nichtmehr das Backup mittel der Wahl ist. Es gibt Einige "Gute" programme welche deine Backups in Dateien nach Datum sortiert erstellen Können. Ich habe einen Nas Server mit Raid und einem "Hotbutton" zum Kompletten kopieren des Nas inhalts auf eine Usb platte & oder auf einen Anderen Nas server. Deine Bänder sind ja mittlerweile keine Speicherwunder mehr. Du könntest also durchaus Usbsticks oder Speicherkarten verwenden. Diese Gibts schon ab 20€ Sind meiner meinung nach unemfindlicher bei der Lagerung und haben recht wenig Verschleis. Kartenleser gibts für wenige euros. Und im Notfall kann fast jeder schnell die Backups laden ohne Spezial Laufwerk. Dat Laufwerk ~~100€ 10 Bänder @6€ 60€ == 160€ Dafür bekommste 8 stück 32gb Karten.
Michael Reinelt schrieb: > Äh... ich war brav und hielt mich an die Vorgaben. Heisst das, ich war > brav, aber dumm? Wie sind die Vorgaben bei DAT? So oft wie nötig, oder so oft wie möglich?
ich dnake euch allen. Waren zwar nicht die Antowrten, die ich hören wollte, aber deshalb frag ich ja hier :-) ich werde mich also wohl der berühmten "normativen Kraft des Faktischen" beugen, und ein Backup auf USB-Platten andenken (und den frei gewordenen 5 1/4" schacht mit einem Display bestücken :-) Was mich gleich zur nächsten Frage bringt: Welche Backup-Software setzt ihr ein, und könnt ihr empfehlen? Linux only, Debian, nur ein Server (alles andere wird über diverse Mechanismen auf diesen Server zusammengeführt). Bisher setze ich eine (uralte) Version von Arkeia an, bis auf die gewöhnungsbedürftige GUI war ich immer sehr zufrieden damit. Es muss überhaupt nicht Klickibunti sein, ich kann mit tar & co recht gut umgehen, aber ein bissi GUI schadet nicht, speziell wenn man historische Versionen einer versehentlich überschriebenen Datei sucht. Und wenns leicht geht, ohne Java-Krankheit.
A. K. schrieb: > Michael Reinelt schrieb: >> Sorry, ich vergaß zu erwähnen: Linux. Linux only. > > Noch einfacher, da kommt das Verfahren ja ursprünglich her: "rsync", am > einfachsten in Form von "rsnapshot". Heidenei, das wird ja immer spannender: ich kenne gut und liebe rsync, rsnapshot höre ich zum ersten mal... muss ich mich einlesen. Danke!
A. K. schrieb: > Michael Reinelt schrieb: >> Äh... ich war brav und hielt mich an die Vorgaben. Heisst das, ich war >> brav, aber dumm? > > Wie sind die Vorgaben bei DAT? So oft wie nötig, oder so oft wie > möglich? Müsste ich jetzt raussuchen, aber soweit ich mich erinnere: bei täglicher Nutzung einmal wöchentlich.
Michael Reinelt schrieb: > Müsste ich jetzt raussuchen, aber soweit ich mich erinnere: bei > täglicher Nutzung einmal wöchentlich. Und das LW erinnert nicht daran? Hab ich von älteren DATs so in Kopf.
A. K. schrieb: > Michael Reinelt schrieb: >> Müsste ich jetzt raussuchen, aber soweit ich mich erinnere: bei >> täglicher Nutzung einmal wöchentlich. > > Und das LW erinnert nicht daran? Hab ich von älteren DATs so in Kopf. Schon, das "Clean" Lamperl beginnt zu blinken, aber dann ists schon zu spät (zumindest dachte ich, dass ich so mein letztes DAT-laufwerk vernichtet hätte, aber das zweifle ich inzwischen an) Nochmal danke für den Hinweis auf rsnapshot, ich glaub das ist genau das tool auf meiner Wellenlänge! ("what you see ist what you get" is as bad a concept in text editors as it is in women... I prefer "you asked for it, you got it")
Michael Reinelt schrieb: > Sorry, ich vergaß zu erwähnen: Linux. Linux only. Ich benutze rdiff-backup auf Linux zu genau dem Zweck. Funktioniert prima.
Uhu Uhuhu schrieb: > Ich benutze rdiff-backup auf Linux zu genau dem Zweck. Funktioniert > prima. Kann ich bestätigen. Reverse-Inkrementelles Backup mit rdiff-Backup auf externe eSATA-Platten. Funktioniert prächtig. Noch ein paar Tips: - mounte die Backup-Platte über cryptsetup (luks). Dann ist das Zeug gleich sauber verschlüsselt und jemand der kurz in Deinen Serverraum kommt, kann nicht mit einem Griff gleich alle Daten abgreifen. - achte auf ordentliche Kühlung der Platten. Ich hab nen günstigen eSATA-Rahmen genommen, den vorhandenen Billiglüfter rausgeworfen und durch einen starken Qualitätslüfter ersetzt. Ohne das sind die Platten zu schnell gestorben, da der Billiglüfter bald den Geist aufgab. Alternativ gibt es auch noch solche SATA-Platten-Wechseleinschübe für 5.25-Slots, vielleicht sind die da besser. - ich nehm 3 Sätze an Platten, die werden immer wochenweise durchrotiert und die 2 nicht angeschlossenen extern gelagert
:
Bearbeitet durch User
Gerd E. schrieb: > Uhu Uhuhu schrieb: >> Ich benutze rdiff-backup auf Linux zu genau dem Zweck. Funktioniert >> prima. > > Kann ich bestätigen. Reverse-Inkrementelles Backup mit rdiff-Backup auf > externe eSATA-Platten. Funktioniert prächtig. Wenn ich das richtig verstanden habe, macht rdiff alleine so was ähnliches wie rsync? mit dem unterschied dass es Deltas speichert, und damit Speicherplatz spart? Wie funktioniert da der restore? Muss man das dann aus Quelle+Delta irgendiwe "zusammenstöpseln"? Erfahrungsgemäß brauchen meine inkrementellen Backups recht wenig Platz; wenn sich eine Datei geändert hat, darf die ruhig komplett am inkrementellen Backup liegen. Von daher erscheint mir rsnapshot momentan sympatischer, weil imkrementelle Files da "als Ganzes" ligene, und damit find & grep & co sauber arbeiten... ich lass mich aber gern vom gegenteil überzeugen.
Michael Reinelt schrieb: > Gerd E. schrieb: >> Uhu Uhuhu schrieb: >>> Ich benutze rdiff-backup auf Linux zu genau dem Zweck. Funktioniert >>> prima. >> >> Kann ich bestätigen. Reverse-Inkrementelles Backup mit rdiff-Backup auf >> externe eSATA-Platten. Funktioniert prächtig. > > Wenn ich das richtig verstanden habe, macht rdiff alleine so was > ähnliches wie rsync? mit dem unterschied dass es Deltas speichert, und > damit Speicherplatz spart? > > Wie funktioniert da der restore? Muss man das dann aus Quelle+Delta > irgendiwe "zusammenstöpseln"? nein. du hast auf einer platte in einem verzeichnis (a) ein vollständiges backup, und wenn backup (b) angelegt wird, auf der selben platte, werden nur die geänderten daten in (b) geschrieben und die unveränderten aus (a) nach (b) hard gelinkt. hat den vorteil das bei jedem inkrementellen backup nur wenig platz verbraucht wird - soweit ok. nachteil ist das du wegen der hardlinks immer ein vollbackup auf dem medium brauchst auf dem du inkrementelle backups machen willst. restore geht dann einfach über rm/cp (oder rsync --delete ...) aus dem verzeichnis das deinem letzen stand entspricht. wenn dir noch nicht klar ist wie das jetzt funktioniert schlage ich vor du spielst ein wenig mit rsync (man option --link-dest= ), du -hs[lL] in den zielverzeichnissen und rm -r (altes zielverzeichnis) herum - da sollte einiges klar werden :)
c.m. schrieb: > nein. edit... wenn die menge an daten die sich per inkrementellem backup ändern klein ist lässt sich so ein inkrementelles rsync backup auch prima übers netzwerk erledigen - option [-e "ssh"] (und --compress wenn es komprimierbare dateien sind) und pre shared public key in .ssh/authorized_keys (man ssh-keygen).
@c.m.: Exakt so arbeiten rsnapshot und rsync. In der Beschreibung von rdiff-backup steht es freilich völlig anders drin: "but extra reverse diffs are stored in a special subdirectory of that target directory,". Ich lese das (und den Rest der Beschreibung) so, dass nur der letzte Stand 1:1 dort steht, ältere Stände in Form ebendieser reverse-diffs in besagter Subdirectory. Gegenüber rsync/rsnapshot hat das den Vorteil, dass wirklich nur bei veänderten Files geschrieben werden muss, während rsync/rsnapshot für jedes File einen Hardlink anlegt, was bei sehr vielen Files auch etwas dauern kann. Und rdiff-backup kann Filesysteme wie FAT32 verwenden, die weder Hardlinks können, noch case sensitive sind (gibt dann aber verwurstete Filenamen).
:
Bearbeitet durch User
@c.m. Danke, aber was du beschriebst ist rsnapshot? ich denke dass ich das schon verstanden habe, mir gings mehr um den unterschied zu rdiff
:
Bearbeitet durch User
Michael Reinelt schrieb: > @c.m. Danke, aber was du beschriebst ist rsnapshot? ich denke dass ich > das schon verstanden habe, mir gings mehr um den unterschied zu rdiff rsync und wohl auch rsnapshot. ich kenne letzteres nicht wirklich, meine aber mich zu erinnern das es ein fork aus rsync ist. ich persönlich verwende nur rsync… KISS :) rdiff habe ich eben mal quer gelesen - ja, das tool legt unterverzeichnisse im backuppfad an wo es inkrementelle daten (umbenannt, gezipped) schreibt. ob das für dich besser ist als rsync/snapshot kann ich nicht entscheiden - kommt auf das typische restore szenario an wenn ein löschwütiger kollege eine datei oder einen ganzen pfad restored haben will. rsync hat hier den vorteil das alle pfade und dateien in den backups so daliegen wie im quellsystem, man also nur "rüberkopieren" muss - wie das genau bei rdiff funktioniert hat sich mir beim ersten drüberlesen nicht erschlossen (und ich mag mich nicht weiter einlesen weil rsync bei mir exzellent funktioniert). A. K. schrieb: > dauern kann. Und rdiff-backup kann Filesysteme wie FAT32 verwenden, die > weder Hardlinks können, noch case sensitive sind (gibt dann aber > verwurstete Filenamen). wenn das wichtig ist dann fallen rsync/rsnapshot natürlich weg, das ist aber wiederum ein problem das sich mir nicht stellt (glücklicherweise :). die von dir angesprochenen geschwindigkeitsprobleme kann ich nicht nachvollziehen - erstens weil ich rdiff nicht als vergleich laufen habe, und zweitens weil ich denke das backups eben zeit brauchen… einen tod muss man sterben ;) wenn es darauf ankommt das dienste (vm's, oracle, mysql + webfrontent oder dergl.) möglichst wenig downtime haben muss man sich eben was einfallen lassen - z.b. lvm-snapshots und die dann "zeitintensiv" wegsichern. hier mal ein aktuelles beispiel. sichern meines home verzeichnisses, 116GB, 400k dateien. dauer 32min - wobei ich in meinem script noch einen unnötigen schritt habe - das eigentliche sichern dauert nur 23min. quelle und ziel sind dabei doppelt verschlüsselt und die übertragung geht über usb2.
1 | CRYPT ORIN ~ # ./backup.sh |
2 | 2013_09_30-08:21:06 START ########################################## |
3 | 2013_09_30-08:21:06 quellpfad: /home/camikusch |
4 | 2013_09_30-08:21:06 zielpfad : /mnt/snapshots/ORIN |
5 | 2013_09_30-08:21:06 datum : 2013_09_30-08:21:06 |
6 | 2013_09_30-08:21:06 TARGET_FULL_PATH_TEMP: /mnt/snapshots/ORIN/2013_09_30-08:21:06.temp |
7 | 2013_09_30-08:21:06 TARGET_FULL_PATH_DONE: /mnt/snapshots/ORIN/2013_09_30-08:21:06.done |
8 | 2013_09_30-08:21:06 RSYNC_LINK_DEST : /mnt/snapshots/ORIN/2013_09_12-09:05:06.done |
9 | 2013_09_30-08:21:06 -------------------------------------------------- |
10 | 2013_09_30-08:21:06 ermittle benutzten und freien speicher... |
11 | 2013_09_30-08:30:28 benutzter speicher in /home/camikusch: 116648488kb |
12 | 2013_09_30-08:30:28 freier speicher in /mnt/snapshots/ORIN: 130046184kb |
13 | 2013_09_30-08:30:28 es ist noch genug speicher in /mnt/snapshots/ORIN übrig, muss keine alten backups löschen :) |
14 | 2013_09_30-08:53:35 ENDE ########################################### |
15 | CRYPT ORIN ~ # find /home/camikusch/ | wc -l |
16 | 408525 |
zum schluss sieht das dann so aus, wobei wie gesagt in jedem unterverzeichnis, anders als bei rdiff, das gesamte backup "copy/restore ready" zur verfügung steht:
1 | CRYPT ORIN ~ # du -hsl /mnt/snapshots/ORIN/* |
2 | 158G /mnt/snapshots/ORIN/2013_04_19-14:50:55.done |
3 | 157G /mnt/snapshots/ORIN/2013_04_29-09:13:20.done |
4 | 131G /mnt/snapshots/ORIN/2013_05_03-09:14:10.done |
5 | 133G /mnt/snapshots/ORIN/2013_05_10-12:46:24.done |
6 | 135G /mnt/snapshots/ORIN/2013_05_23-09:29:27.done |
7 | 175G /mnt/snapshots/ORIN/2013_07_19-07:45:47.done |
8 | 173G /mnt/snapshots/ORIN/2013_08_05-07:17:59.done |
9 | 173G /mnt/snapshots/ORIN/2013_08_05-08:24:01.done |
10 | 174G /mnt/snapshots/ORIN/2013_08_06-16:15:31.done |
11 | 174G /mnt/snapshots/ORIN/2013_08_07-15:55:43.done |
12 | 117G /mnt/snapshots/ORIN/2013_08_16-13:04:12.done |
13 | 135G /mnt/snapshots/ORIN/2013_09_12-09:05:06.done |
14 | 141G /mnt/snapshots/ORIN/2013_09_30-08:21:06.done |
15 | CRYPT ORIN ~ # df -h /mnt/snapshots/ |
16 | Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf |
17 | /dev/mapper/9rQ8ZdpMpzZTiRBj1ywN 459G 353G 107G 77% /mnt/snapshots |
Im Anhang mein rdiff-backup-Skript. Es kann nach vollendetem Werk den Rechner herunterfahren. Bei '/pfad1/der/vom/backup/ausgeschlossen/sein/soll' kann eine beliebig lange Liste von Pfaden angegeben werden, die von Backup ausgeschlossen sind.
c. m. schrieb: > die von dir angesprochenen geschwindigkeitsprobleme kann ich nicht > nachvollziehen - erstens weil ich rdiff nicht als vergleich laufen habe, > und zweitens weil ich denke das backups eben zeit brauchen… einen tod > muss man sterben ;) Das Hardlink-Verfahren legt bei jedem inkrementellen Backup für jedes File entweder ein File oder einen Hardlink an. Bei extrem vielen kleinen Files kann das einen wesentlichen Teil der Laufzeit ausmachen - besonders freilich unter Windows, das bei removable media wenig effizient arbeitet, und bei USB-Sticks. Beim rdiff-Verfahren wird - so wie ich es verstehe - bei inkrementellen Backups unveränderter Files nichts geschrieben. Das kann in solchen Fällen wesentlich schneller sein. Zu einem Problem hast es erst du gemacht. Ich erwähnte nur, dass die Verfahren unterschiedlich schnell sein können. ;-)
:
Bearbeitet durch User
Danke euch allen. Laufzeit ist nicht wirklich ein Problem, theoretisch darf es die halbe Nacht dauern. Immerhin hat er jetzt ja auch auf Band geschrieben. ich werde auf jeden Fall das mit den hardlinks (also rsnapshot) probieren, "zu viele" hardlinks stören mich nicht, und der Komfort schnell einige Verzeichnisse der vergangenheit zu durchsuchen gefällt mir gut.
Michael Reinelt schrieb: > ich werde auf jeden Fall das mit den hardlinks (also rsnapshot) > probieren, "zu viele" hardlinks stören mich nicht, und der Komfort > schnell einige Verzeichnisse der vergangenheit zu durchsuchen gefällt > mir gut. Die Frage ist halt wie feinkörnig Du in die Vergangenheit zurückkönnen möchtest. In der Firma machen wir 3 Backups am Tag damit nicht zu viel Zeit verloren geht wenn jemand was mit falschen Daten überschreibt oder löscht. Diese 3 Backupsätze pro Tag werden dann bis 3 Monate zurück aufbewahrt. Damit können wir auch Daten wiederherstellen wenn jemand nicht sofort den Verlust bemerkt. Kommt übrigens auch hin und wieder vor. Das wäre mit Hardlinks nicht mehr zu machen. Bei rdiff-backup werden einfach nur alle veränderten Dateien als Diffs angelegt und danach alle reverse-diffs älter 3 Monate gelöscht und fertig. Der häufigste Fall - Daten gelöscht oder überschrieben, letzten Stand wiederherstellen - kann man damit ratzfatz mit nem normalen Dateimanager machen. Wenn man dann in die Diffs rein will, ruft man halt kurz das rdiff-backup mit nem Parameter auf. Geht auch problemlos.
Gerd E. schrieb: > In der Firma machen wir 3 Backups am Tag damit nicht zu viel > Zeit verloren geht wenn jemand was mit falschen Daten überschreibt oder > löscht. Diese 3 Backupsätze pro Tag werden dann bis 3 Monate zurück > aufbewahrt. Ohne Staffelung? Ab solcher Frequenz kann man indes mal an ein Filesystem mit Snapshots denken. Nicht als Alternative zu Backups, die dann primär Desaster-Recovery darstellen, sondern als Zeitreisemaschine. Dann hat sich auch das Thema "Laufzeit" erledigt, solche Snapshots sind eine Sache von Sekunden.
:
Bearbeitet durch User
Michael Reinelt schrieb: > ich dnake euch allen. Waren zwar nicht die Antowrten, die ich hören > wollte, aber deshalb frag ich ja hier :-) > > ich werde mich also wohl der berühmten "normativen Kraft des Faktischen" > beugen, und ein Backup auf USB-Platten andenken (und den frei gewordenen > 5 1/4" schacht mit einem Display bestücken :-) Oder "normale" Festplatten und einen (Hot-Swap) Wechselrahmen z.B. so was http://www.icydock.de/goods.php?id=128
A. K. schrieb: > Gerd E. schrieb: >> In der Firma machen wir 3 Backups am Tag damit nicht zu viel >> Zeit verloren geht wenn jemand was mit falschen Daten überschreibt oder >> löscht. Diese 3 Backupsätze pro Tag werden dann bis 3 Monate zurück >> aufbewahrt. > > Ohne Staffelung? Wie meinst Du das genau? Ob die noch irgendwie aggregiert werden oder sowas? Aggregieren oder ähnliches ist bei rdiff-backup nicht nötig. Es werden wirklich nur die geänderten Dateien zusätzlich angelegt. Und die paar Files die z.B. 3x am Tag abgelegt werden machen im Vergleich zum ganzen Rest den Kohl auch nicht fett, zumindest bei uns. > Ab solcher Frequenz kann man indes mal an ein Filesystem mit Snapshots > denken. Nicht als Alternative zu Backups, die dann primär > Desaster-Recovery darstellen, sondern als Zeitreisemaschine. Dann hat > sich auch das Thema "Laufzeit" erledigt, solche Snapshots sind eine > Sache von Sekunden. Hmm. Erhöht halt die Komplexität & Speicherbedarf auf dem primären Plattensystem. Das möchte ich eigentlich möglichst vermeiden. Der Speicherbedarf dort ist teuer, da das meiste SSD wg. Random-Zugriffszeit & IO-Ops/sek. Auf die alten Backups muss ich vielleicht 1 oder 2 mal im Jahr zugreifen. Da macht es dann keinen Unterschied ob die Wiederherstellung nun 1 oder 5 Minuten dauert. Das längste daran ist dann sowieso herauszufinden, welche Version nun eigentlich wirklich benötigt wird.
Gerd E. schrieb: > Da macht es dann keinen Unterschied ob die Wiederherstellung > nun 1 oder 5 Minuten dauert. Ich dachte eher an den Backup-Vorgang. Wenn du dabei mehrmals täglich zig Millionen Files scannst, und zwar mitten in der Produktion, dann macht sich dass nicht unbedingt performance-steigernd bemerkbar. In kleinem Rahmen ist das freilich kein Thema.
:
Bearbeitet durch User
A. K. schrieb: > Ich dachte eher an den Backup-Vorgang. Wenn du dabei mehrmals täglich > zig Millionen Files scannst, und zwar mitten in der Produktion, dann > macht sich dass nicht unbedingt performance-steigernd bemerkbar. Klar. Momentan nehme ich ionice für den Backup-Prozess. Das funktioniert bisher sehr gut. Wenn es irgendwann nicht mehr gehen sollte, wären natürlich 3 Snapshots, die dann in der Nacht ausgelesen, gebackupt und gelöscht werden, ne Alternative.
A. K. schrieb: > dann macht sich dass nicht unbedingt performance-steigernd bemerkbar. Ja, das ist wahr. Aber wenn man die Sicherung nach Feierabend ankicken kann und der Rechner anschließend automatisch herunterfährt, wenn nichts weiter zu tun ist, dann ist das egal.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.