Autor Thema: Backupkonzept für viel zu viele große Notesdatenbanken.  (Gelesen 5459 mal)

Offline notesman

  • Aktives Mitglied
  • ***
  • Beiträge: 226
  • Geschlecht: Männlich
  • Jeder Tag ist ein Geschenk Gottes
    • Gedankensalat
 :) Hallo Admins  :knuddel:

unsere Postfächer wachsen und das Backup wird immer länger.

Ich beschreibe mal kurz die Backup-Landschaft (die gesichert wird)
(Alles Windowsserver)
2 Domino 8.53 Server mit je 450 GB Postfächern und Datenbanken
als Cluster     = 900 GB zu sichern

1 Archivserver Domino 8.53 mit 800 GB Archiven

Macht zwei LTO-5 Bänder täglich (Dauer 17 - 20  Std. incl. Verify)
Per Backup Exec 2010 R2 Vollsicherung

Warum sollte ich den gesamten Cluster immer vollsichern.
Ich suche eine Lösung um z.B. alle DBs in einen gemeinsamen Speicher täglich zu
sichern (brächte eine "fast" 100% Deduplizierung) und nur diesen Pool dann auf Band zu sichern.

Leider bietet der DominoCluster keine 100%ige Spiegelung aller DBs bzw Datensätze (Replizierkonflikte, Warnschwellen überschritten, ...)
Kann also nicht einfach nur einen Server sichern.

Für das nächste Jahr möchte ich neue Möglichkeiten entdecken.
Hat jemand eine Lösungsidee?.

Z.B. Alles in eine "LAN interne Cloud" legen und dann "in Ruhe" auf ein Band sichern - oder so was.

Oder von allen Datenbanken eine Replik auf einen Server den ich dann für die Sicherung runterfahre
und ohne Notes-Agenten sichern kann. (Wie sichere ich ab, dass ich alles erwische.)

Ein weitere Idee wäre die Sicherung mit einer Software wie VMprotect* (eigener Backupstorage = schnell) und einem Restore
auf eine "Freigabe" für eine Sicherung 2 Tape z.B. tagsüber ohne Dominoagenten - da keine DomServer zu berücksichtigen ist.
*leider kann VMProtect so was nicht, da es eher für Restore ganzer Maschinen gedacht ist und Restore nicht automatisierbar.

Die Lösung soll außerdem NICHT 10.000€ plus Loader kosten  :o
Bestehendes Backup EXEC würde ich gerne weiterverwenden für den Loader.
Eine DISK2TAPE Sicherung brachte leider nur Performanceprobleme da die Sicherung auf den Loader schneller war als
die Sicherung auf die Festplatten (SCSI mit 10000 u/min im RAID 5)

OK soweit dann mal.
Lieben Gruss
Frank

Offline Pfefferminz-T

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 1.204
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #1 am: 14.08.13 - 20:09:46 »
Ich nehme an, dass ihr einen Backup-Zyklus mit Vollbackup + inkrementellen Sicherungen habt. Setzt ihr Transaction Logging ein (falls ja, wie)? Nutzt ihr DAOS?

Du hast verschiedene Möglichkeiten:

- eigener Backup-Domino Server, auf den die Datenbanken repliziert werden und auf den keine Endnutzer zugreifen. Über diesen Server erfolgt dann auch das Restore um die "User facing"-Systeme zu entlasten
- entsprechende Backup-Strategie Vollbackup/inkrementell
- DAOS
- schnellere Plattensysteme, mehr kleine Platten
- bessere Anbindung der Bandsysteme oder schnellere Systeme

Meinen Kunden würde ich nicht empfehlen, beide Server eines Clusters zu sichern. Stellst Du bei einer Rücksicherung aktuell beide gesicherten Datenbanken wieder her und vergleichst? Das kann ich mir nicht wirklich vorstellen...

Grüsse,
Thorsten
Grüsse,
Thorsten

Offline Jens_1

  • Senior Mitglied
  • ****
  • Beiträge: 440
  • Geschlecht: Männlich
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #2 am: 16.08.13 - 11:50:19 »
Ich möchte mich dem Vorposter anschliessen.
Ein eigener Server ist auch aus meiner Sicht die Wahl.

Allerdings wird dann oftmals der Cluster überhaupt nicht mehr gesichert und das halte ich für einen Fehler.
Das heisst, die Datenbanken, die auf den Sicherungsserver repliziert werden, die sollten von der Sicherung auf dem Cluster ausgeschlossen werden.
Alle anderen wie names, admin4 und/oder log gehören in's Backup!

Gruß
Jens
CLP Domino R5 System Administrator
CLP IBM Lotus Domino 6 System Administrator
CLP IBM Lotus Domino 7 System Administrator
IBM Certified System Administrator - Lotus Notes and Domino 8

Offline notesman

  • Aktives Mitglied
  • ***
  • Beiträge: 226
  • Geschlecht: Männlich
  • Jeder Tag ist ein Geschenk Gottes
    • Gedankensalat
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #3 am: 16.08.13 - 12:11:30 »
Danke für die netten Antworten. Wirft aber eher Fragen auf:

Backup-Zyklus ist Vollbackup täglich.    Weil: DBs werden doch eh jeden Tag alle verändert und das sieht BE

Transaction Logging?  ja
DAOS? Nein                                        (macht woanders wieder Probleme)

>>>- eigener Backup-Domino Server, auf den die Datenbanken repliziert werden und auf den keine Endnutzer zugreifen. Über
>>>  diesen Server erfolgt dann auch das Restore um die "User facing"-Systeme zu entlasten

Ja - aber wie kann ich sicherstellen, dass alle DBs wirklich und vollständig repliziert wurden?
      (Z.B. wenn Postfach größér als erlaubt - stoppt replizierung - passiert leider manchmal)

>>> - entsprechende Backup-Strategie Vollbackup/inkrementell
Wie schon gesagt: Inkrementell = Vollbackup bei Postfächern

>>> - DAOS
Auch nach Schulung und Diskussionen eher NEIN -  Restore und Bandsicherung und Cluster und Externer Server mit Repliken
machen das alles schlecht handhabbar

>>> - schnellere Plattensysteme, mehr kleine Platten
Teils auf einem SAN (Externer / Traveller Server) Hardware hat keine Erweiterungsmöglichkeiten

>>> - bessere Anbindung der Bandsysteme oder schnellere Systeme
Ja wäre schön: wer möchte das nicht

>>>  Meinen Kunden würde ich nicht empfehlen, beide Server eines Clusters zu sichern. Stellst Du bei einer Rücksicherung aktuell
         beide gesicherten Datenbanken wieder her und vergleichst? Das kann ich mir nicht wirklich vorstellen...
Bisher immer nur eine DB wiederhergestellt und dann eine neue Replik erstellt. War nie ein Problem.

Bleibt also das Problem:  Wie kann ich sicherstellen, dass alle DBs wirklich und vollständig repliziert wurden?
Einen Server für die Repliken hätte ich frei. (Ist dann auch gleich ein virtueller Backup Exec Server.)

Danke

Offline Jens_1

  • Senior Mitglied
  • ****
  • Beiträge: 440
  • Geschlecht: Männlich
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #4 am: 16.08.13 - 12:47:59 »
AFIK gelten Quotas nur serverbezogen.
Du müsstest also nur die Quotas auf dem Backup-Server deaktivieren.....

Und:
Bist Du sicher, das der Remote-Agent von Backup-Exec nur ein Vollbackup der Datenbank durch zieht?
Ich bin nicht mehr im Thema aber meine mich zu erinnern, das der Agent auf Dokumentenebene sichern konnte....?!

Gruß
Jens
CLP Domino R5 System Administrator
CLP IBM Lotus Domino 6 System Administrator
CLP IBM Lotus Domino 7 System Administrator
IBM Certified System Administrator - Lotus Notes and Domino 8

Offline notesman

  • Aktives Mitglied
  • ***
  • Beiträge: 226
  • Geschlecht: Männlich
  • Jeder Tag ist ein Geschenk Gottes
    • Gedankensalat
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #5 am: 16.08.13 - 13:01:54 »
AFIK = SWIW ;-)    gut das es Google gibt - kannte ich nicht   ;D

Wenn die Datenbankgröße auf dem Hauptserver überschritten ist - repliziert der dann trotzdem
"Weil auf dem Backupserver keine Größe definier ist"? + Da dieser nicht zum Domino-Cluster gehört?

Frank

Offline m3

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 8.102
  • Geschlecht: Männlich
  • Non ex transverso sed deorsum!
    • leyrers online pamphlet
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #6 am: 16.08.13 - 13:11:32 »
Zitat
- Using transaction logging simplifies your daily backup procedure. You can use a third-party backup utility to perform daily incremental backups of the transaction logs, rather than perform full database backups.

The backup and recovery API in Domino® provides the capability to perform online full backups of individual databases and archives of the transaction log when archival logging is in effect. A transaction log captures database changes for logged databases so full database backups are not required as frequently. Updates to a logged database are recorded in the Domino server transaction log. Changes to a database since the last full backup can be applied from the transaction log after the backup is restored from the last full backup.

Dass man beide Server eines Clusters sichert, hätte ich noch nicht erlebt. Da würde ich eher mal den Cluster debuggen, wenn die auseinanderlaufen.
Damit hätteste Du die Datenmenge schon mal reduziert.

Mit Umstellen auf Transactionlog-Sicherung (siehe oben) und Fullbackup nur 1x die Woche hättest Du nochmal Speed dazu gewonnenen bei weniger Platzbedarf.

Und mit DAOS könntest Du nochmal Platz sparen und Speed gewinnen. Das ist einfacher, als man glaubt.  DAOS Backup and Restore


BackupExec kann beides:
Best practices for the Backup Exec 2012 Agent for Lotus Domino
How to properly perform a backup of Lotus Domino with Backup Exec
HTH
m³ aka. Martin -- leyrers online pamphlet | LEYON - All things Lotus (IBM Collaborations Solutions)

All programs evolve until they can send email.
Except Microsoft Exchange.
    - Memorable Quotes from Alt.Sysadmin.Recovery

"Lotus Notes ist wie ein Badezimmer, geht ohne Kacheln, aber nicht so gut." -- Peter Klett

"If there isn't at least a handful of solutions for any given problem, it isn't IBM"™ - @notessensai

Offline notesman

  • Aktives Mitglied
  • ***
  • Beiträge: 226
  • Geschlecht: Männlich
  • Jeder Tag ist ein Geschenk Gottes
    • Gedankensalat
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #7 am: 16.08.13 - 13:33:19 »
Jaaaaaaa Danke,

>>>>> Dass man beide Server eines Clusters sichert, hätte ich noch nicht erlebt. Da würde ich eher mal den Cluster debuggen,
>>>>> wenn die auseinanderlaufen.
>>>>> Damit hätteste Du die Datenmenge schon mal reduziert.

Jetzt weisst Du dass es einen gibt, der dass seit 10 Jahren tut. :-)
Wenn auf den Servern nur die Postfächer wären - hätte ich dass vermutlich auch versucht.
Dank weiterer Software bzw. Datenbanken - welche über die Jahre nicht immer geklustert waren, war mir beide sichern immer
die bessere Lösung. Trotzdem sollte man die aktuelle Lage mal prüfenn bzw. überdenken. Dann könnte ich
z.B. die Mailpostfächer aus der "Doppelten" Sicherung ausschließen. Allerdings hatte ich schon - das von einem
Postfach (längere Zeit) unbemerkt, die Replk einen Defekt hatte. Da war ich froh beide Repliken zu haben.
Wenn ich kurzfristig die Trennung des Backup von TASI 2 Disk und nur WOSI/Mosi 2 Tape hinbekomme. Würde das ja auch schon viel bringen.


Weder im Domino-Kurs :-)
Noch im Backup Exec 2012 Kurs (ja da war ich ! ) hat sich als empfehlenswert ergeben, auf Fullbackup zu verzichten.
>>> Mit Umstellen auf Transactionlog-Sicherung (siehe oben) und Fullbackup nur 1x die Woche hättest Du nochmal Speed dazu
>>> gewonnenen bei weniger Platzbedarf.

Bisher hatte ich den Eindruck, das DAOS zu betreiben gut funktionieren würde - aber Backup Restore eher unsicherer / aufwändiger wird.

>>> Und mit DAOS könntest Du nochmal Platz sparen und Speed gewinnen. Das ist einfacher, als man glaubt. 
>>> DAOS Backup and Restore

>>> BackupExec kann beides:
>>> Best practices for the Backup Exec 2012 Agent for Lotus Domino
JAaaaaa, kann sein - aber selbst "nur 4" Domino Server zu sichern - war ein Albtraum (trotz Schulung)
Wir warten auf 2013 - da in R3 ja leider nicht die Rückkehr weg von der Serverbasierten Sicht gekommen ist :-(
Auf Band sichern mit 2012 ist unhandlich bis Murks
 :-\
>>> How to properly perform a backup of Lotus Domino with Backup Exec
Schau ich mir mal an.

Danke  :)
 
 

Offline Jens_1

  • Senior Mitglied
  • ****
  • Beiträge: 440
  • Geschlecht: Männlich
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #8 am: 16.08.13 - 13:47:56 »
[...]
Jetzt weisst Du dass es einen gibt, der dass seit 10 Jahren tut. :-)
Wenn auf den Servern nur die Postfächer wären - hätte ich dass vermutlich auch versucht.
Dank weiterer Software bzw. Datenbanken - welche über die Jahre nicht immer geklustert waren, war mir beide sichern immer
die bessere Lösung. Trotzdem sollte man die aktuelle Lage mal prüfenn bzw. überdenken. Dann könnte ich
z.B. die Mailpostfächer aus der "Doppelten" Sicherung ausschließen. Allerdings hatte ich schon - das von einem
Postfach (längere Zeit) unbemerkt, die Replk einen Defekt hatte. Da war ich froh beide Repliken zu haben.
[...]

Wenn ich mich recht erinnere, dann konnte man das immer sehr komfortabel mit der Cluster-Analyse monitoren.

Gruß
Jens
CLP Domino R5 System Administrator
CLP IBM Lotus Domino 6 System Administrator
CLP IBM Lotus Domino 7 System Administrator
IBM Certified System Administrator - Lotus Notes and Domino 8

Offline m3

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 8.102
  • Geschlecht: Männlich
  • Non ex transverso sed deorsum!
    • leyrers online pamphlet
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #9 am: 16.08.13 - 14:33:01 »
Jaaaaaaa Danke,

>>>>> Dass man beide Server eines Clusters sichert, hätte ich noch nicht erlebt. Da würde ich eher mal den Cluster debuggen,
>>>>> wenn die auseinanderlaufen.
>>>>> Damit hätteste Du die Datenmenge schon mal reduziert.

Jetzt weisst Du dass es einen gibt, der dass seit 10 Jahren tut. :-)
War auch nicht so boese gemeint, wie es vielleicht ruebergekommen ist. Sorry. ;)

Trotzdem sollte man die aktuelle Lage mal prüfenn bzw. überdenken.
Darauf wollte ich hinaus  :D


Weder im Domino-Kurs :-)
Noch im Backup Exec 2012 Kurs (ja da war ich ! ) hat sich als empfehlenswert ergeben, auf Fullbackup zu verzichten.
Das habe ich ja auch nicht gesagt. Aber ein FB muss ja nicht jeden Tag gemacht werden ...


Bisher hatte ich den Eindruck, das DAOS zu betreiben gut funktionieren würde - aber Backup Restore eher unsicherer / aufwändiger wird.
initial ja, ist DAOS bezgl. Backup/Restore etwas aufwaendiger, da man sich das mal mit den NLOs udn Cutoffs durchdenken muss. Aber wenns mal rennt, ist nicht mehr viel Unterschied.


HTH
m³ aka. Martin -- leyrers online pamphlet | LEYON - All things Lotus (IBM Collaborations Solutions)

All programs evolve until they can send email.
Except Microsoft Exchange.
    - Memorable Quotes from Alt.Sysadmin.Recovery

"Lotus Notes ist wie ein Badezimmer, geht ohne Kacheln, aber nicht so gut." -- Peter Klett

"If there isn't at least a handful of solutions for any given problem, it isn't IBM"™ - @notessensai

Offline notesman

  • Aktives Mitglied
  • ***
  • Beiträge: 226
  • Geschlecht: Männlich
  • Jeder Tag ist ein Geschenk Gottes
    • Gedankensalat
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #10 am: 16.08.13 - 14:40:58 »
 :)  Danke und schönes Wochenende - bin dann mal weg (Inliner warten) Sonne am Rheinmuss man nutzen. :D

Offline Jens_1

  • Senior Mitglied
  • ****
  • Beiträge: 440
  • Geschlecht: Männlich
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #11 am: 16.08.13 - 14:41:58 »
[...]
Dass man beide Server eines Clusters sichert, hätte ich noch nicht erlebt. [...]

Also das man die Cluster komplett sichert oder auch das man, so wie ich oben geschrieben habe, die Datenbanken ausklammert und die Logs usw. sichert?

Gruß
Jens
CLP Domino R5 System Administrator
CLP IBM Lotus Domino 6 System Administrator
CLP IBM Lotus Domino 7 System Administrator
IBM Certified System Administrator - Lotus Notes and Domino 8

Offline m3

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 8.102
  • Geschlecht: Männlich
  • Non ex transverso sed deorsum!
    • leyrers online pamphlet
Re: Backupkonzept für viel zu viele große Notesdatenbanken.
« Antwort #12 am: 16.08.13 - 15:12:09 »
Komplett sichern wuerde ich ihn nicht. Dass DD, admin4, .. gesichert gehoeren, steht nicht zur Diskussion ;)
HTH
m³ aka. Martin -- leyrers online pamphlet | LEYON - All things Lotus (IBM Collaborations Solutions)

All programs evolve until they can send email.
Except Microsoft Exchange.
    - Memorable Quotes from Alt.Sysadmin.Recovery

"Lotus Notes ist wie ein Badezimmer, geht ohne Kacheln, aber nicht so gut." -- Peter Klett

"If there isn't at least a handful of solutions for any given problem, it isn't IBM"™ - @notessensai

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz