In meinen Augen widerspricht das der Definition 24/7.
Öhm... ok. 
Szenario a) Wir haben Urlaub und lassen die Kiste laufen 24/7, oder halt am Wochenende 24/3.
Szenraio b) wir gehen Arbeiten und brauchen den Server nicht so oft, dann wird er bei Bedarf eingeschaltet
Ein echtes Backup ist eines, was man in den Tresor legen kann ohne daß beim Schliessen der Tür ein Kabel abgeschert wird.
So isses.
Ein Blitztreffer auf das eigene Dach (oder das des Nachbarn) bedeutet normalerweise, daß alles, was an Elektronik zu diesem Zeitpunkt eingeschaltet war oder auch nur mit langen Kabeln verbunden war, defekt ist.
Wir verstehen uns. 
Oder lass es ein Hochwasser sein, oder einen kleinen Brand in der Abteilung. Wenn danach eine komplette Entwickungsabteilung zu ist, weil halt keine Daten mehr vorhanden sind, ist was falsch gelaufen.
Nein, eben nicht, wenn du rsync mit --link-dest= benutzt ...
Nimm doch rsnapshot das nimmt dir viel in der Hinsicht ab, ist aber dennoch unpraktischer (unter der Haube) als TimeMachine.
Quote from Off-TopicTimeMachine hält folgende Backups vor: Stündlich für die letzten 24 Stunden, Täglich für die letzte Woche und Wöchentlich so lange der Platz reicht.
rsnapshot speichert die letzten $x Stunden UND/ODER die letzten $y Tage UND/ODER die letzten $z Wochen. Welches von denen und wie lange ($x,$y,$z) muss manuell eingestellt werden. Problem dabei ist: das sind drei getrennte Backups, benötigen also drei mal den platz für die backups. Wie gesagt ist das schon viel besser als einfach "nur" rsync oder was auch immer aber nicht annähernd so komfortabel wie TimeMachine wo alles AUTOMATISCH ineinander übergeht und demnach für den selben Service nur ca. 1/3 des Platzes benötigt.
Nimm doch rsnapshot das nimmt dir viel in der Hinsicht ab, ist aber dennoch unpraktischer (unter der Haube) als TimeMachine.
Meine Scripte sind fertig und funktionieren. Ich habe damit ein Backup aller mir wichtigen Daten auf mehreren Datenträgern und dank --link-dest= auch alle Versionen der diversen Dateien. Ein Restore würde von Hand per 'cp -a' erfolgen, aber das ist auch nur ein privater Rechner, kein hochverfügbarer Server, ein bisschen Downtime stört nicht.
Passt schon so für mich.
Oder lass es ein Hochwasser sein, oder einen kleinen Brand in der Abteilung
In einer Firma behandelt man Backups noch ein bisschen paranoider. Da gibt es extra wasserdichte und feuerfeste (für eine bestimmte Zeit natürlich) Tresore für.
Für das Backup daheim reicht bei Hochwassergefahr eine dichte Frischhaltebox (also nicht die billigen) in der man die Backup-HD oder Bänder lagert und zur Feuersicherheit ein off-site Backup (verschlüsselt!) welches bei einem Freund lagert und hin und wieder aufgefrischt wird.
In einer Firma behandelt man Backups noch ein bisschen paranoider. Da gibt es extra wasserdichte und feuerfeste (für eine bestimmte Zeit natürlich) Tresore für.
Eben, das ist dann Teil des Konzepts. Wenn ich dann hier sinngemäß lese »unsere Backupdatenträger sind alle immer angeschlossen«, hinterfrage ich entweder das Backupkonzept, oder aber die Relevanz der Daten.
Für das Backup daheim reicht bei Hochwassergefahr eine dichte Frischhaltebox (also nicht die billigen) in der man die Backup-HD oder Bänder lagert und zur Feuersicherheit ein off-site Backup (verschlüsselt!) welches bei einem Freund lagert und hin und wieder aufgefrischt wird.
Geht auch, genau. Hier im 3. Stock wird ein Hochwasser vermutlich nicht zuschlagen, drum ist mir das egal. Beim Thema Feuer muss ich dann sagen: Wenn das zuschlägt, habe ich vermutlich eh andere Sorgen, als meine paar Daten. Aber gegen Blitzschlag oder auch einfach nur Netzüberspannung (soll ja zuweilen mal vorkommen) z. B. bin ich auch nicht gefeit, drum gibts zwei Backupplatten, die /nur/ im Wechsel benutzt werden, also nie gleichzeitig.
Beim Thema Feuer muss ich dann sagen: Wenn das zuschlägt, habe ich vermutlich eh andere Sorgen, als meine paar Daten.
Seitdem µSD-Karten mit großer Kapazität bezahlbar sind kann man die wichtigsten 32 oder 64GB seiner Daten (Zeug, daß man nicht mehr bekommen würde, selbst erstelltes, Scans von wichtigen Dokumenten usw.) immer in der Brieftasche dabeihaben (Verschlüsselung dringend angeraten!) und hat so ein Backup der letzten Chance wenn z.B. die Bude und damit alle EDV abgebrannt ist.
Auch hier das Befüllen und Verifizieren per Script automatisieren, dann wirds nicht vergessen.
Seitdem µSD-Karten mit großer Kapazität bezahlbar sind kann man die wichtigsten 32 oder 64GB seiner Daten (Zeug, daß man nicht mehr bekommen würde, selbst erstelltes, Scans von wichtigen Dokumenten usw.) immer in der Brieftasche dabeihaben (Verschlüsselung dringend angeraten!) und hat so ein Backup der letzten Chance wenn z.B. die Bude und damit alle EDV abgebrannt ist.
Oder eben nen USB-Stick. So läuft das bei mir auch. Wäre schon scheiße, wenn der Passwortmanager mit verkohlt...
Auch hier das Befüllen und Verifizieren per Script automatisieren, dann wirds nicht vergessen.
Früher per *.bat, heute eben per *.sh.
Bei Flash-Medien für Backups mache ich mir immer die Mühe alle Daten nach dem Schreiben noch einmal zu verifizieren. Ich hatte schon zuviele defekte Sticks/Karten die beim Schreiben keinen Fehler meldeten aber beim Lesen Fehler in den Daten hatten.
Total Commander hat da auch eine Funktion integriert, die nach dem kopieren noch mal verifiziert. Wie sehen denn da die Meinungen zu aus?
Flash-Speicher ist für ein ständiges überschreiben nicht geeignet da er je nach Typ nur (typisch) 5.000 mal überschrieben werden kann.
Lösch-Schreib-Zyklen: USB-Sicks, NAND-Flash Allgemein. Kann aber mit Wear leveling "verbessert" weren, ist aber typischerweise auf SD-Karten und USB-Sicks nicht vorhanden...
Lass es mich mal so ausdrücken: Wenn ich den Stick ein mal am Tag voll schreibe, also auch ein evtl. Wearleveling nicht mehr greifen wird, sind das immerhin mehr als 13 Jahre, die der Stick halten müsste. Das reicht mir. Wenn er doch mal ausfällt, kauf ich halt nen neuen. Da interessiert mich schon eher, ob die Daten auch sauber geschrieben wurden. Das Problem habe ich auch schon auf Festplatten, dass Dateien urplötzlich im Arsch sind, ohne dass ich wüsste, in welcher Situation das vorgekommen sein soll. Aus meiner Sicht müssen das fast schon Hardwaredefekte sein, seis, dass die Platte selbst Fehler produziert, die man nicht aufgedeckt bekommt, oder der RAM ein Problem hat. Drum bin ich bei meiner nächsten Server-Anschaffung auch drauf aus, dass da ECC-RAM mit drin ist und dann im Idealfall ein ZFS drauf kommt.
Flash-Speicher ist für ein ständiges überschreiben nicht geeignet da er je nach Typ nur (typisch) 5.000 mal überschrieben werden kann.
Für das wöchentliche Backup auf USB-Stick oder µSD absolut problemlos. Zur Sicherheit mounte ich die Dateisysteme von Flashmedien aber immer mit 'noatime' weil sonst jeder Zugriff (es reicht schon das listen) auf eine Datei einen Schreibzyklus auslöst um die 'access time' (Zeit des letzten Zugriffs) auf den aktuellen Stand zu bringen.
Nein, eben nicht, wenn du rsync mit --link-dest= benutzt, dann kannst du damit das gleiche erreichen wie timemachine, also mehrere Versionen derselben Datei vorhalten. Du hast dann eine Sammlung von Directories, aber jede Inkarnation/Version einer Datei nur einmal dank Hardlinks. Die Funktion ist nicht besonders intuitiv, aber wenn man sie mal kapiert und in ein Script gegossen hat funktioniert sie genau wie beschrieben.
Für Windows:
In einer Uralt-C'T gab es sowas als VBS Script auch mit für Win32 kompilierten Version von RSync, welches mit Hardlinks arbeitet. Das Script funktioniert AFAIK auch heute noch.
Mittlererweile verwende ich der "Nachfolger" Hardlinkbackup der die ganze Idee in eine schöne GUI umgesetzt hat als Enterprise Edition im Büro fast täglich.
Ich mag, dass ich die Backup-Dateien als Datums-Subverzeichnisse holen/anschauen kann, ohne irgendeine spezielle Software oder ein spezielles OS installieren oder einen Entzipper verwenden zu müssen.
Bei aller Liebe zum Programm: Mit jedem Backup wird das Ding zum Sichern immer träger. Ich vermute mal, das liegt an den vielen Hardlinks, die (vermutlich) nicht gerade auf Speed optimiert sind.
Deshalb lösche ich nach ca. 2 Monate alte Backupsätze (mit dem Tool selbst) regelmässig wieder raus.
