24
Differentielle Sicherung ziemlich groß
Hallo,
ich hab hier einen Windows Server 2008 R2 als Domänencontroller laufen. Auf dem ist auch SQL Server mit ca. 5 Datenbanken. Der Server dient auch als kleine Art "Fileserver". Jetzt habe ich ne Frage zu Sicherung. Ich hab einmal vor 2 Monaten eine Vollsichernug gemacht die ca. 80GB groß ist. Auf diese Vollsicherung habe ich dann immer differentielle Sicherungen gemacht. Nun hab ich letztens geguckt und war etwas erstaunt das die differentielle Sicherung von Tag zu Tag immer größer wird. Mir ist klar das die differentielle Sicherung ALLE Ändernung seit dem LETZTEN Vollbackup übernimmt, dennoch find ich die Größe erstaunlich.
Die Vollsicherung war wie gesagt ca. 80GB groß. Am darauf folgenden Tag war die differentielle Sicherung 13GB. Noch ein Tag darauf 15GB. Jetzt nach 2 Monaten bin ich bei der 55ten Sicherung welche ca. 45GB groß ist.
Ist es normal das die Backups so ein großes Wachstum haben? MIr ist zwar klar das vorallem bei einem Verzeichnisdienst immer Änderungen gemacht werden und auch die Datenbanken ja immer aktuell sind aber würde der Wert dann nicht in kleinen Maßen zu nehmen?
Ich lass auch noch auf einer anderen Platte jede Woche eine Vollsicherung machen. Die ist jetzt in der letzten Woche ca. 90GB groß gewesen.
Ist es nun normal das die differentielle Sicherung so groß werden kann? Was könnte man als alternativen Backup Plan machen? Ich wollte eig. auf inkrementelle Sicherungen verzichten da ja theoretisch die ganzen Sicherungen nicht mehr von Nutzen sind wenn nur ein Backupfile defekt ist.
grüße
Burak
ich hab hier einen Windows Server 2008 R2 als Domänencontroller laufen. Auf dem ist auch SQL Server mit ca. 5 Datenbanken. Der Server dient auch als kleine Art "Fileserver". Jetzt habe ich ne Frage zu Sicherung. Ich hab einmal vor 2 Monaten eine Vollsichernug gemacht die ca. 80GB groß ist. Auf diese Vollsicherung habe ich dann immer differentielle Sicherungen gemacht. Nun hab ich letztens geguckt und war etwas erstaunt das die differentielle Sicherung von Tag zu Tag immer größer wird. Mir ist klar das die differentielle Sicherung ALLE Ändernung seit dem LETZTEN Vollbackup übernimmt, dennoch find ich die Größe erstaunlich.
Die Vollsicherung war wie gesagt ca. 80GB groß. Am darauf folgenden Tag war die differentielle Sicherung 13GB. Noch ein Tag darauf 15GB. Jetzt nach 2 Monaten bin ich bei der 55ten Sicherung welche ca. 45GB groß ist.
Ist es normal das die Backups so ein großes Wachstum haben? MIr ist zwar klar das vorallem bei einem Verzeichnisdienst immer Änderungen gemacht werden und auch die Datenbanken ja immer aktuell sind aber würde der Wert dann nicht in kleinen Maßen zu nehmen?
Ich lass auch noch auf einer anderen Platte jede Woche eine Vollsicherung machen. Die ist jetzt in der letzten Woche ca. 90GB groß gewesen.
Ist es nun normal das die differentielle Sicherung so groß werden kann? Was könnte man als alternativen Backup Plan machen? Ich wollte eig. auf inkrementelle Sicherungen verzichten da ja theoretisch die ganzen Sicherungen nicht mehr von Nutzen sind wenn nur ein Backupfile defekt ist.
grüße
Burak
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 176506
Url: https://administrator.de/forum/differentielle-sicherung-ziemlich-gross-176506.html
Ausgedruckt am: 23.12.2024 um 06:12 Uhr
24 Kommentare
Neuester Kommentar
Hallo,
es wäre nicht schlecht wenn du auch mal erwähnen würdest mit welcher Software du dies machst. Differienziell setzt immer auf der letzen Vollsicherung auf! Du verwechselst das mit Inkrementell, dort wird immer auf der letzen Teilsicherung aufgesetzt.
Gruss
es wäre nicht schlecht wenn du auch mal erwähnen würdest mit welcher Software du dies machst. Differienziell setzt immer auf der letzen Vollsicherung auf! Du verwechselst das mit Inkrementell, dort wird immer auf der letzen Teilsicherung aufgesetzt.
Gruss
Hallo Burak,
vielleicht habe ich es falsch verstanden und du machst es schon so, aber warum macht du nicht jede Woche eine Vollsicherung und täglich eine differentielle? Das würde die Zeiträume, die eine differentielle überbrücken muss, auf maximal 7 Tage erhöhen und den Speicherbedarf wohl auch verkleinern.
Viele Grüße
Henrik
vielleicht habe ich es falsch verstanden und du machst es schon so, aber warum macht du nicht jede Woche eine Vollsicherung und täglich eine differentielle? Das würde die Zeiträume, die eine differentielle überbrücken muss, auf maximal 7 Tage erhöhen und den Speicherbedarf wohl auch verkleinern.
Viele Grüße
Henrik
@dan0ne Ich hab doch x mal im Text differnetiell gesagt ^^? Ich weis schon den Unterschied! Und die SIcherung mach ich mit Acronis Backup & Recovery 11.
@henrik
Naja, das hab ich mir auch überlegt aber dann würde jede Woche rund. 90GB Vollbackup sein + die differentielle. Sagen wir mal ich komm dann auf 150GB pro Woche - nach 6-7 Wochen ist die Festplatte voll. Dann muss ich wohl die älteste Sicherung immer löschen?
@henrik
Naja, das hab ich mir auch überlegt aber dann würde jede Woche rund. 90GB Vollbackup sein + die differentielle. Sagen wir mal ich komm dann auf 150GB pro Woche - nach 6-7 Wochen ist die Festplatte voll. Dann muss ich wohl die älteste Sicherung immer löschen?
Hallo
warum machst du keine Vollsicherung jeden Tag? 80Gb ist mal "nix" was nicht in max 30 Minuten weggesichert werden kann - ich würde mir mal das Konzept überdenken .... ich kenne Acronis jetzt nicht aber ich denke schon das die so arbeiten können das du jeden Tag nebst der Festplattensicherung eine Bandsicherung machst und die Festplattensicherung nicht so lange vorhältst - selbst 90GB sind nichts - da kannst du mit einer 2TB Platte drei Wochen vorhalten und dann anfangen zu überschreiben - ohne Probleme bei einer täglichen Vollsicherung - mir wäre das bei dem kleinen Volumen viel zu aufwendig im WorstCase erst das Backup und dann diff. Sicherungen einzuspielen. Und wie bereits geschrieben - 80-100Gb einfach per Nachtjob wegsichern und max 30-45 Minuten und alles ist in Butter - das ganze dann Tagsüber auf Band wegschreiben (da wird auch LTO3 ausreichen mit 400Gb) und alles ist gut.
Wir sichern täglich die SQL und Exchange DB als Vollbackup - lediglich die Datengrab (oder auch Fileserver) -Server werden per diff. Täglich und Samstag voll und auf Tape weggeschrieben
Und Langzeitsicherung macht man auf Band und nicht auf Festplatte ... (vorallem bei dem geringen Volumen)
warum machst du keine Vollsicherung jeden Tag? 80Gb ist mal "nix" was nicht in max 30 Minuten weggesichert werden kann - ich würde mir mal das Konzept überdenken .... ich kenne Acronis jetzt nicht aber ich denke schon das die so arbeiten können das du jeden Tag nebst der Festplattensicherung eine Bandsicherung machst und die Festplattensicherung nicht so lange vorhältst - selbst 90GB sind nichts - da kannst du mit einer 2TB Platte drei Wochen vorhalten und dann anfangen zu überschreiben - ohne Probleme bei einer täglichen Vollsicherung - mir wäre das bei dem kleinen Volumen viel zu aufwendig im WorstCase erst das Backup und dann diff. Sicherungen einzuspielen. Und wie bereits geschrieben - 80-100Gb einfach per Nachtjob wegsichern und max 30-45 Minuten und alles ist in Butter - das ganze dann Tagsüber auf Band wegschreiben (da wird auch LTO3 ausreichen mit 400Gb) und alles ist gut.
Wir sichern täglich die SQL und Exchange DB als Vollbackup - lediglich die Datengrab (oder auch Fileserver) -Server werden per diff. Täglich und Samstag voll und auf Tape weggeschrieben
Und Langzeitsicherung macht man auf Band und nicht auf Festplatte ... (vorallem bei dem geringen Volumen)
Hallo clSchak,
danke für die Antwort. Bandsicherung muss ich ganz ausschließen. Dafür haben wir keine Hardware in den Server verbaut und dem Kunde wären Festplatten lieber (warum auch immer ;)). Eine Vollsicherung jeden Tag wäre auch interessant. Nur hat man bei 1TB Platten dann nur Sicherungen die maximal 14 Tage zurück gehen. Ich glaub bei Datenbanken wäre das egal da eine Datebank schon nach 5 Tagen zu alt ist (zumindenst hat mir das mal einer gesagt...)
Bei Acronis habe ich gar nicht so viel Probleme mit dem Backup zurück spielen. Ich wähl das letzte differentielle aus und der spielt dann das Vollbackup ein und dann das differentielle von selbst.
Mich wundert es halt nur das die Größe der Backupfiles so extrem anwächst. Sind 45GB Änderungen in einem Zeitraum von 2 Monaten normal? Normale Dokumente sind es vllt gerade mal 10GB, Datenbanken + Transaktionsfiles sind halt etwas groß + die Sicherungen die der SQL Server macht (wobei die nach 7 Tagen gelöscht werden, also sozusagen rotiert).
danke für die Antwort. Bandsicherung muss ich ganz ausschließen. Dafür haben wir keine Hardware in den Server verbaut und dem Kunde wären Festplatten lieber (warum auch immer ;)). Eine Vollsicherung jeden Tag wäre auch interessant. Nur hat man bei 1TB Platten dann nur Sicherungen die maximal 14 Tage zurück gehen. Ich glaub bei Datenbanken wäre das egal da eine Datebank schon nach 5 Tagen zu alt ist (zumindenst hat mir das mal einer gesagt...)
Bei Acronis habe ich gar nicht so viel Probleme mit dem Backup zurück spielen. Ich wähl das letzte differentielle aus und der spielt dann das Vollbackup ein und dann das differentielle von selbst.
Mich wundert es halt nur das die Größe der Backupfiles so extrem anwächst. Sind 45GB Änderungen in einem Zeitraum von 2 Monaten normal? Normale Dokumente sind es vllt gerade mal 10GB, Datenbanken + Transaktionsfiles sind halt etwas groß + die Sicherungen die der SQL Server macht (wobei die nach 7 Tagen gelöscht werden, also sozusagen rotiert).
naja bei uns wächst das Backup um rund 25 GB /Woche also nicht so ungewöhnlich - und bei einer diff. Sicherung wird ja selbst eine änderung am Fileserver "ich verschiebe meinen Datenordner von D:\Daten nach D:\Daten2 als Änderung angesehen. Und folglich sind 45GB in 2 Monate eigentlich "nix" - würde evtl. mal schauen ob nicht evtl. ein MA für einen Kollegen die aktuellen Kinocharts hochgeladen hat .... :o)
Und jetzt mal was anderes - Ihr sichert einen Server auf Platten innerhalb des Servers? ôÔ das muss ich jetzt nicht verstehen oder? (weil macht irgendwie garkeinen Sinn) - und das Argument "haben wir beim Kunden nicht verbaut" zieht mal nicht - dann wird sich halt mit dem Kunden hingesetzt und eine Einfach Lösung gefunden (simpler Server mit 2 x 2 TB Raid 1 und einem LTO2 Laufwerk sind unter 1500 EUR zu haben und das Backup ist dann wirklich ein Backup und kann sogar dezentral aufgestellt werden - z.B. anderer Brandabschnitt ...)
PS: bei uns sind Datenbanken nach sekunden schon alt ... alleine durch die Buchhaltung, Rückmeldezeiten der Produktion .... da helfen an sich nur asynchrone oder synchrone Spiegel um die Ausfallzeiten auf ein minimum zu reduzieren
Und jetzt mal was anderes - Ihr sichert einen Server auf Platten innerhalb des Servers? ôÔ das muss ich jetzt nicht verstehen oder? (weil macht irgendwie garkeinen Sinn) - und das Argument "haben wir beim Kunden nicht verbaut" zieht mal nicht - dann wird sich halt mit dem Kunden hingesetzt und eine Einfach Lösung gefunden (simpler Server mit 2 x 2 TB Raid 1 und einem LTO2 Laufwerk sind unter 1500 EUR zu haben und das Backup ist dann wirklich ein Backup und kann sogar dezentral aufgestellt werden - z.B. anderer Brandabschnitt ...)
PS: bei uns sind Datenbanken nach sekunden schon alt ... alleine durch die Buchhaltung, Rückmeldezeiten der Produktion .... da helfen an sich nur asynchrone oder synchrone Spiegel um die Ausfallzeiten auf ein minimum zu reduzieren
Nein, wir haben einen extra "Backup Server" mit 3x1TB Festplatten. Ich seh nicht so n guten Grund für ein RAID 1 bei einem Backup Server. Da kann man ja beim Backup Plan auswählen das er es auf einer anderen Platte repliziert.
Die Plan bisher ist eigentlich es wird auf eine Platte Mo-Fr gesichert. Dann einmal Mo-Do und diese Platte in nen Tresor und dann nochmal einmal pro Woche ne Vollsicherung welche dann auch in den Tresor kommt.
Die Plan bisher ist eigentlich es wird auf eine Platte Mo-Fr gesichert. Dann einmal Mo-Do und diese Platte in nen Tresor und dann nochmal einmal pro Woche ne Vollsicherung welche dann auch in den Tresor kommt.
Hi.
Überleg Dir doch, wie die Sicherungssoftware vorgeht. Sichert sie die Unterschied innerhalb von Dateien oder gegenüber der Vollsicherung veränderte Dateien komplett? Letzteres wohl eher. Wenn immer mehr Dateien angefasst werden und (wenn auch noch so klein) geändert werden, dann werden diese komplett ins Diff genommen.
Mach es doch so: alle 4 Wochen eine Vollsicherung (oder ein anderes, geeignetes intervall) und dazwischen Diff.
Überleg Dir doch, wie die Sicherungssoftware vorgeht. Sichert sie die Unterschied innerhalb von Dateien oder gegenüber der Vollsicherung veränderte Dateien komplett? Letzteres wohl eher. Wenn immer mehr Dateien angefasst werden und (wenn auch noch so klein) geändert werden, dann werden diese komplett ins Diff genommen.
Mach es doch so: alle 4 Wochen eine Vollsicherung (oder ein anderes, geeignetes intervall) und dazwischen Diff.
Das düfte mit den SQL-Datenbanken zusammenhängen.
Das Backup arbeitet immer Dateiweise.
D.h. wenn in einer SQL-Datei mit mehreen tausend Datensätzen nur ein einziger Datensatz verändert wird muss beim nächsten Backup die komplette Datei gesichert werden.
Ich fürchte damit wirst du leben müssen.
Das Backup arbeitet immer Dateiweise.
D.h. wenn in einer SQL-Datei mit mehreen tausend Datensätzen nur ein einziger Datensatz verändert wird muss beim nächsten Backup die komplette Datei gesichert werden.
Ich fürchte damit wirst du leben müssen.
Moin,
nehmt es mir nicht übel, aber mir ist grad genauso...
Backupserver mit ohne Raid 1 oder was anderem.
Fullbackup jede xx Monate und diff Sicherung täglich und das jedesmal auf eine andere Platte...
Und geplant ist, die kommen in den Safe, also externe Platten?
Da stimmt doch vorne und hinten nix, vor allem die frage nach dem Wachstum sollte einem zu denken geben...
Ganz ehrlich, ich war neulich erst wieder bei einer "bekannten" wo auch so ein vollpfroffesioneller am Werk war.
Als ich das gezimmerte gesehen hab und nachdem ich den am Telefon hatte, wusste ich bescheid.
Maedelzz bevor ihr jemandem was verkauft, übt und lernt Zuhause, wo es nix schadet....
Gruss
nehmt es mir nicht übel, aber mir ist grad genauso...
Backupserver mit ohne Raid 1 oder was anderem.
Fullbackup jede xx Monate und diff Sicherung täglich und das jedesmal auf eine andere Platte...
Und geplant ist, die kommen in den Safe, also externe Platten?
Da stimmt doch vorne und hinten nix, vor allem die frage nach dem Wachstum sollte einem zu denken geben...
Ganz ehrlich, ich war neulich erst wieder bei einer "bekannten" wo auch so ein vollpfroffesioneller am Werk war.
Als ich das gezimmerte gesehen hab und nachdem ich den am Telefon hatte, wusste ich bescheid.
Maedelzz bevor ihr jemandem was verkauft, übt und lernt Zuhause, wo es nix schadet....
Gruss
@timobeil Ich bin jetzt etwas verwirrt was dir jetzt nicht gefällt ;). ich nehm keinem seine Meinung/Kommentar übel nur find ich es dann nett wenn man n anderen Vorschlag hat oder meint was überhaupt nicht passt und besser gemacht werden kann. Wenn mir nur gesagt wird "es passt alles nicht" kann ich schlecht was besseres daraus zaubern ;)
@DerWoWusste Hallo, also ich bin der Meinung das Acronis dein letzten Gesagten Punkt umsetzt. Der übernimmt veränderte Dateien komplett. An eine Vollsicherung und darauf basierte diff. Sicherungen im kleineren Intervall dachte ich auch, nur muss man halt schauen welches Intervall am besten wäre.
@jens2001 Damit hab ich ja auch kein Problem. Aber wäre dann die größe nicht Konstant bzw. leicht darüber? Die Datenbankgröße ist ja nicht extrem gewachsen. Wenn Änderungen vorgenommen werden, dann wird die neue Datenbank gesichert. Aber das die Sicherung dann so extrem zu wächst?
Nochmal zum Sicherungsplan. Die Idee zur Sicherheit war halt das eine Festplatte in den Tresor kommt bei Brand/Diebstahl. Auf zwei Festplatten wurd am Anfang eine Vollsicherung gemacht und seit dem läuft da immer eigen eine differenzielle Sicherung. Da es kein Sinn macht am nächsten Morgen bis zum Abend die Festplatte in den Tresor zu tun wird die eine Festplatte am Freitag in den Tresor gelagert und die dritte Festplatte wo jede Woche nur einmal gesichert wird (und das Voll) halt an dem entsprechenden Tag rausgenommen/weggetan.
Das sind keine externe Festpatten. Sind alles in einem HotSwap Käfig damit man die im laufenden Betrieb die Festplatte rausnehmen kann.
Klar, ich geb zu - das Konzept geht nicht ganz auf. Eine Festplatte ist immernoch im Server. Bei der zweiten Festplatte fehlt immer der Datenstatus von Freitag. Die wöchentliche Sicherung ist eigentlich schon zu alt - aber so ein gutes inviduelles Konzept zu erstellen ist gar nicht so einfach.
@DerWoWusste Hallo, also ich bin der Meinung das Acronis dein letzten Gesagten Punkt umsetzt. Der übernimmt veränderte Dateien komplett. An eine Vollsicherung und darauf basierte diff. Sicherungen im kleineren Intervall dachte ich auch, nur muss man halt schauen welches Intervall am besten wäre.
@jens2001 Damit hab ich ja auch kein Problem. Aber wäre dann die größe nicht Konstant bzw. leicht darüber? Die Datenbankgröße ist ja nicht extrem gewachsen. Wenn Änderungen vorgenommen werden, dann wird die neue Datenbank gesichert. Aber das die Sicherung dann so extrem zu wächst?
Nochmal zum Sicherungsplan. Die Idee zur Sicherheit war halt das eine Festplatte in den Tresor kommt bei Brand/Diebstahl. Auf zwei Festplatten wurd am Anfang eine Vollsicherung gemacht und seit dem läuft da immer eigen eine differenzielle Sicherung. Da es kein Sinn macht am nächsten Morgen bis zum Abend die Festplatte in den Tresor zu tun wird die eine Festplatte am Freitag in den Tresor gelagert und die dritte Festplatte wo jede Woche nur einmal gesichert wird (und das Voll) halt an dem entsprechenden Tag rausgenommen/weggetan.
Das sind keine externe Festpatten. Sind alles in einem HotSwap Käfig damit man die im laufenden Betrieb die Festplatte rausnehmen kann.
Klar, ich geb zu - das Konzept geht nicht ganz auf. Eine Festplatte ist immernoch im Server. Bei der zweiten Festplatte fehlt immer der Datenstatus von Freitag. Die wöchentliche Sicherung ist eigentlich schon zu alt - aber so ein gutes inviduelles Konzept zu erstellen ist gar nicht so einfach.
also - damit ich das jetzt richtig verstehe - du ziehst "interne" Platten im Betrieb aus dem Rechner - die als Backupmedium dient? Also nicht via eSATA / USB o.ä. angeschlossen ... sondern den "knopf" vorne drücken und dann per Hebel die Festplatte aus Array ziehen? Wenn ja ôÔ ... also das geht mal garnicht ... was machst denn wenn noch Daten "offen" im Cache des Controllers liegen?
Und warum Raid 1? Auch ein Backupserver sollte wie ein normaler Server behandelt werden - was machste denn wenn dir ein Platte abraucht und die dann Daten von letzter Woche wiederhaben wollen *ja äh das geht leider nicht* oder wie?
Ein sicheres und gutes Konzept ist mal relativ "simpel" zu erstellen: Backup from Disk to Disk to Tape (deinem Fall Disk-Disk-Disk) - Kurzzeitsicherung auf Disk und Langzeit auf externe Platte/Band - so hast immer die Möglichkeit schnell eine Wiederherstellung zu machen die auf relativ aktuelle Daten zugreift oder via Langzeitsicherung auf ältere Wiederherstellungspunkte zurückgreifen - und den Kunden kann man ohne weiteres klar machen, dass Tapesicherung weitaus besser ist wie Plattensicherung -> "Platte fällt beim Transport aus der Hand --> kaputt ... das Tape kann ein runterfallen mal haben...)
Und du wiedersprichst dir - du redest von Diff. Sicherung schreibst aber:
ja was denn nun? Diff oder voll? Klar wird die entsprechend geänderte Datei gesichert aber das ist dann kein SQL Backup - was ist mit den Transaktionlogs usw. ich denke nicht das du die so konsistent weggesicherst bekommst ...
Und warum Raid 1? Auch ein Backupserver sollte wie ein normaler Server behandelt werden - was machste denn wenn dir ein Platte abraucht und die dann Daten von letzter Woche wiederhaben wollen *ja äh das geht leider nicht* oder wie?
Ein sicheres und gutes Konzept ist mal relativ "simpel" zu erstellen: Backup from Disk to Disk to Tape (deinem Fall Disk-Disk-Disk) - Kurzzeitsicherung auf Disk und Langzeit auf externe Platte/Band - so hast immer die Möglichkeit schnell eine Wiederherstellung zu machen die auf relativ aktuelle Daten zugreift oder via Langzeitsicherung auf ältere Wiederherstellungspunkte zurückgreifen - und den Kunden kann man ohne weiteres klar machen, dass Tapesicherung weitaus besser ist wie Plattensicherung -> "Platte fällt beim Transport aus der Hand --> kaputt ... das Tape kann ein runterfallen mal haben...)
Und du wiedersprichst dir - du redest von Diff. Sicherung schreibst aber:
Zitat von @vBurak:
@jens2001 Damit hab ich ja auch kein Problem. Aber wäre dann die größe nicht Konstant bzw. leicht darüber?
Die Datenbankgröße ist ja nicht extrem gewachsen. Wenn Änderungen vorgenommen werden, dann wird die neue Datenbank
gesichert. Aber das die Sicherung dann so extrem zu wächst?
@jens2001 Damit hab ich ja auch kein Problem. Aber wäre dann die größe nicht Konstant bzw. leicht darüber?
Die Datenbankgröße ist ja nicht extrem gewachsen. Wenn Änderungen vorgenommen werden, dann wird die neue Datenbank
gesichert. Aber das die Sicherung dann so extrem zu wächst?
ja was denn nun? Diff oder voll? Klar wird die entsprechend geänderte Datei gesichert aber das ist dann kein SQL Backup - was ist mit den Transaktionlogs usw. ich denke nicht das du die so konsistent weggesicherst bekommst ...
Der Backup Server läuft über onBoard Intel AHCI. Festplattencache habe ich deaktiviert. RAID 1 seh ich im allgemeinen (auch wenn ich es hier nicht mache - hast schon recht) wie eine Replikation von der Sicherung. Bei Acronis kann ich als Einstellung das erstellte Backup an einen andere Ort replizieren - was wäre hier dann der Unterschied zu RAID 1? RAID dient für mich als Hochverfügbarkeitszusatz. Wenn eine Platte ausfällt kann mit der anderen Platte weiter gearbeitet werden.
Disk to Disk to Tape wäre sozusagen noch ein Tape-Laufwerk in dem Backup Server der dann die "Sicherung" sichert?
Was meinst du bei dem Zitat von mir? Ich bin da etwas auf dem Schlauch. Der SQL Server hat einige Wartungstasks die jeden Tag die Datenbank sichert. Nach 7 Tagen wird das älteste Backup File gelöscht. Ich sichere dann eigentlich mit Acronis alle Festplatten und somit auch die Backup Files die der SQL Server anlegt.
Disk to Disk to Tape wäre sozusagen noch ein Tape-Laufwerk in dem Backup Server der dann die "Sicherung" sichert?
Was meinst du bei dem Zitat von mir? Ich bin da etwas auf dem Schlauch. Der SQL Server hat einige Wartungstasks die jeden Tag die Datenbank sichert. Nach 7 Tagen wird das älteste Backup File gelöscht. Ich sichere dann eigentlich mit Acronis alle Festplatten und somit auch die Backup Files die der SQL Server anlegt.
ok - das mit dem SQL Script hast ja nirgends geschrieben 
Disk2Disk2Tape -> ja, die Tapesicherung (je nach Einstellung) nimmt dann den aktuellsten Sicherungssatz und schreiben diesen auf Band, das System hat den Vorteil das die eigentliche Sicherung relativ zügig geht (weil auf Festplatte) und die "langsamere" Sicherung auf Tape auch Tagsüber laufen kann ohne Probleme - was du jetzt noch lediglich brauchst ist entweder ein SCSI Controller und ein Tapelaufwerk oder das ganze via SAS - je nach Geschmackssache - kosten sind in etwas identisch.
Disk2Disk2Tape -> ja, die Tapesicherung (je nach Einstellung) nimmt dann den aktuellsten Sicherungssatz und schreiben diesen auf Band, das System hat den Vorteil das die eigentliche Sicherung relativ zügig geht (weil auf Festplatte) und die "langsamere" Sicherung auf Tape auch Tagsüber laufen kann ohne Probleme - was du jetzt noch lediglich brauchst ist entweder ein SCSI Controller und ein Tapelaufwerk oder das ganze via SAS - je nach Geschmackssache - kosten sind in etwas identisch.
Okay, das hab ich soweit verstanden. Aber wie du schon sagtest das bei dir eine Datenbank nach. 30 Sekunden schon alt ist - machen dann Langzeitsicherungen Sinn? Bei Dokumenten könnte ich es verstehen, auch Datenbanken von vor ein paar Wochen oder 1-2 Monaten. Aber Langzeitsicherung hört sich nach Jahr(en) an.
Was mir auch gerade eingefallen ist - rohe Datenbanken ohne Transaktionslog ist ja wertlos? Bringen dann sogesagte Image Backups der Festplatten? Oder ist das einzigste was mir bringt nach einem Crash die eigene Backup Files vom SQL Server? Ein Großteil der Daten wird ja in den RAM reingeladen (bei 5 User, 5 Datenbanken, ca. 8GB SQL Server im RAM). Wird sowas beim Backup überdacht (vom SQL Server aus)?
Was mir auch gerade eingefallen ist - rohe Datenbanken ohne Transaktionslog ist ja wertlos? Bringen dann sogesagte Image Backups der Festplatten? Oder ist das einzigste was mir bringt nach einem Crash die eigene Backup Files vom SQL Server? Ein Großteil der Daten wird ja in den RAM reingeladen (bei 5 User, 5 Datenbanken, ca. 8GB SQL Server im RAM). Wird sowas beim Backup überdacht (vom SQL Server aus)?
Zitat von @vBurak:
@timobeil Ich bin jetzt etwas verwirrt was dir jetzt nicht gefällt ;). ich nehm keinem seine Meinung/Kommentar übel nur
find ich es dann nett wenn man n anderen Vorschlag hat oder meint was überhaupt nicht passt und besser gemacht werden kann.
Ich sag's mal so, es gibt kein ideales sicherungskonzept, irgendwo klemmst immer und deswegen muss man Abstriche machen.@timobeil Ich bin jetzt etwas verwirrt was dir jetzt nicht gefällt ;). ich nehm keinem seine Meinung/Kommentar übel nur
find ich es dann nett wenn man n anderen Vorschlag hat oder meint was überhaupt nicht passt und besser gemacht werden kann.
Aber an dem gezeigten Konzept passt ja nix wirklich
Wenn mir nur gesagt wird "es passt alles nicht" kann ich schlecht was besseres daraus zaubern ;)
nun den Ball spiele ich zurück und "danke für dein nicht persönlich nehmen" aber du fragst nach der wachsenden Größe und nachdem dir jeder schreibt Aeh Moment mal, da kannst du du kein Konzept erwarten.Und ich behaupte mal, aus deinem Text gelesen zu haben, dass das bisherige Konzept aus euren Ideen stammt.
Nochmal, jede Firma, jeder fall ist anders.
ideal ist immer der backupserver, der die Disk Backups hält kann auch als notfall szenario laufen.
(wobei in Größeren Umgebungen dafür separate Hardware steht).
Von daher, das muss alles passen und mit so wenig Infos, die sich dann auch teilweise widersprechen, wird's schier unmöglich.
Es gab hier mal vor kurzer zeit einen Mitstreiter, der von uns nicht lesen wollte, das ein replizierter dC nicht mehr gesichert werden muss.
Den Fred und den Mitstreiter findest du aber nicht mehr, beides in der Tonne.
Gruss
Ich versteh nicht so ganz was du mir sagen willst. Du hast mir jetzt wiederholend gesagt dass, das Konzept nicht passt. Okay, streite ich nicht ganz ab - dennoch läuft es. Was willst du denn wissen damit du einen besseren Vorschlag machst?
Das eigentliche Thema war ja warum es so groß anwächst - vllt. ist es bei differentielle Sicherung so normal oder er sichert irgendwie etwas falsch. Inzwischen kann ich so leicht heraus lesen das es normal ist und eine Lösung wäre entweder jeden Tag vollsichern da 80GB "nichts" sind oder im Intervall immer ein Vollbackup machen und dann darauf differenziell.
Das eigentliche Thema war ja warum es so groß anwächst - vllt. ist es bei differentielle Sicherung so normal oder er sichert irgendwie etwas falsch. Inzwischen kann ich so leicht heraus lesen das es normal ist und eine Lösung wäre entweder jeden Tag vollsichern da 80GB "nichts" sind oder im Intervall immer ein Vollbackup machen und dann darauf differenziell.
Was mir auch gerade eingefallen ist - rohe Datenbanken ohne Transaktionslog ist ja wertlos? Bringen dann sogesagte Image Backups
der Festplatten? Oder ist das einzigste was mir bringt nach einem Crash die eigene Backup Files vom SQL Server? Ein Großteil
der Daten wird ja in den RAM reingeladen (bei 5 User, 5 Datenbanken, ca. 8GB SQL Server im RAM). Wird sowas beim Backup
überdacht (vom SQL Server aus)?
der Festplatten? Oder ist das einzigste was mir bringt nach einem Crash die eigene Backup Files vom SQL Server? Ein Großteil
der Daten wird ja in den RAM reingeladen (bei 5 User, 5 Datenbanken, ca. 8GB SQL Server im RAM). Wird sowas beim Backup
überdacht (vom SQL Server aus)?
Nein die Backupsoftware sagt dem SQL Server das alles was im RAM ist zum Zeitpunkt der Sicherung weggeschrieben werden soll - eine Datenbank ohne Logs ist wertlos ja, eine Sicherung schreibt aber alle offenen Prozeduren zu dem Moment der Sicherung zurück in die DB - so das dann das BAK File eine vollständige Datenbank ist (sofern auch eine vollständige Sicherung durchgeführt wurde). Im ganzen machts das eigentlich die Backupsoftware - sofern entsprechende Agent vorhanden sind für Datenbanken - die 08/15 Sicherung macht das nicht (bei Symantec sowie DPM gibt es extra Agents dafür)
Okay, gut zu wissen! Vielen Dank! Der damalige Installateur von der Softwarefirma hat nämlich auch keine Transaktionsprotokollsicherung eingerichtet sondern nur die Vollsicherunge. Ich denk da füg ich noch Logsicherung hinzu und schieb das dann immer alles direkt auf den Backup Server.
Ob ich nun immer eine Vollsicherung vom Server mache jeden Tag muss ich mal schauen. Aber recht vielen Dank für die Tipps und Infos!
Ob ich nun immer eine Vollsicherung vom Server mache jeden Tag muss ich mal schauen. Aber recht vielen Dank für die Tipps und Infos!
Mahlzeit,
Denn das, was ich hier von dir las, war schon nicht so dumm (war wohl aber von jemand anderem eingerichtet worden):
Zitat von @vBurak:
Okay, gut zu wissen! Vielen Dank! Der damalige Installateur von der Softwarefirma hat nämlich auch keine
Transaktionsprotokollsicherung eingerichtet sondern nur die Vollsicherunge. Ich denk da füg ich noch Logsicherung hinzu und
schieb das dann immer alles direkt auf den Backup Server.
Ich denke, du erkundigst dich erst einmal, was mit der Sicherungsmethode beim SQL-Server genau gemeint ist, bevor du funktionierende Wartungspläne über den Haufen schmeißt. Okay, gut zu wissen! Vielen Dank! Der damalige Installateur von der Softwarefirma hat nämlich auch keine
Transaktionsprotokollsicherung eingerichtet sondern nur die Vollsicherunge. Ich denk da füg ich noch Logsicherung hinzu und
schieb das dann immer alles direkt auf den Backup Server.
Denn das, was ich hier von dir las, war schon nicht so dumm (war wohl aber von jemand anderem eingerichtet worden):
Der SQL Server hat einige Wartungstasks die jeden Tag die Datenbank sichert. Nach 7 Tagen wird das älteste Backup File gelöscht.
Zitat von @vBurak:
Ich versteh nicht so ganz was du mir sagen willst. Du hast mir jetzt wiederholend gesagt dass, das Konzept nicht passt. Okay,
streite ich nicht ganz ab - dennoch läuft es. Was willst du denn wissen damit du einen besseren Vorschlag machst?
Festplatten aus einem RAID-Verbund entfernen und auslagern ist keine Sicherungsmethode!Ich versteh nicht so ganz was du mir sagen willst. Du hast mir jetzt wiederholend gesagt dass, das Konzept nicht passt. Okay,
streite ich nicht ganz ab - dennoch läuft es. Was willst du denn wissen damit du einen besseren Vorschlag machst?
servus Goscho,
lass mal - der Fred ist schon so unübersichtlich .-(
(irgendwo steht, dass der backupserver kein Raid hat, und das ist einer der div. Gründe warum weshalb und wieso ich mich eingemischt habe)
Es steht aber auch irgendwo, dass da doch noch Wartungsscripte auf dem SQL Server laufen.
@all
Und nein - ich will jetzt nicht nochmal irgendwas "offtopic" schreiben, aber dennoch läuft es ist beim Thema Backup auch erst dann berechtigt, wenn man es mindesten 5* geschafft hat, die Daten "problemlos" zurückzuholen.
(oder 100% bei mehr als 5 versuchen)
Ich will mich eigentlich auch nicht wirklich aufdrängen, aber die Überschrift lautet doch eigentlich "Differentielle Sicherung ziemlich groß" - warum das so ist, das haben wir hoffe ich zumindestens eindeutig erklären können, wobei ich mir den Schuh vom Erklärbär garnicht anziehe.
Von daher:
(IMHO) - Fred abhaken und mit genauen Infos, was das für SQL Datenbanken sind, wieviele Server da stehen und wie hoch die max. tolerierte Ausfallszeit ist - eine neue Frage stellen und dann kommt auch der TO weiter.
Gruß
lass mal - der Fred ist schon so unübersichtlich .-(
(irgendwo steht, dass der backupserver kein Raid hat, und das ist einer der div. Gründe warum weshalb und wieso ich mich eingemischt habe)
Es steht aber auch irgendwo, dass da doch noch Wartungsscripte auf dem SQL Server laufen.
@all
Und nein - ich will jetzt nicht nochmal irgendwas "offtopic" schreiben, aber dennoch läuft es ist beim Thema Backup auch erst dann berechtigt, wenn man es mindesten 5* geschafft hat, die Daten "problemlos" zurückzuholen.
(oder 100% bei mehr als 5 versuchen)
Ich will mich eigentlich auch nicht wirklich aufdrängen, aber die Überschrift lautet doch eigentlich "Differentielle Sicherung ziemlich groß" - warum das so ist, das haben wir hoffe ich zumindestens eindeutig erklären können, wobei ich mir den Schuh vom Erklärbär garnicht anziehe.
Von daher:
(IMHO) - Fred abhaken und mit genauen Infos, was das für SQL Datenbanken sind, wieviele Server da stehen und wie hoch die max. tolerierte Ausfallszeit ist - eine neue Frage stellen und dann kommt auch der TO weiter.
Gruß
Hallo,
das kann ich machen. Ist es aber nicht etwas unpraktisch wenn man nur die SIcherung vom letzten Abend hat? Wenn die Daten aktuell sein müssen, dann wäre es doch besser Transaktionsprotokollsicherung hinzuzufügen?
das kann ich machen. Ist es aber nicht etwas unpraktisch wenn man nur die SIcherung vom letzten Abend hat? Wenn die Daten aktuell sein müssen, dann wäre es doch besser Transaktionsprotokollsicherung hinzuzufügen?
Ich ziehe keine Festplatten aus einem RAID Verbund. Das dies evtl. Schäden hat und natürlich RAID unbrauchbar macht ist mir klar ;). Der Backup Server besitzt nämlich aus diesem Grund auch kein RAID. Das sind drei einzelne Festplatten in einem Hotswap Käfig wodurch man diese dann in n Tresor legen kann.
EDIT: Hab jetzt hier Frage gelöst eingestellt und einen neuen Thread zum eigentlichen Konzept aufgemacht.
EDIT: Hab jetzt hier Frage gelöst eingestellt und einen neuen Thread zum eigentlichen Konzept aufgemacht.
