Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

MSDP Pool Replizierung richtig eingerichtet?

Created: 31 Jul 2013 | 5 comments

Hallo.

Ich habe an zwei Standorten ( Standort A unf Standort B ) je einen MSDP Pool und möchte die Daten vom Standort A via IP in den MSDP Pool des Standorts B replizieren.

Das habe ich mit einer SLP umgesetzt.

SLP:

Backup -> MSDP Pool Standort A

   Duplication -> MSDP Pool Standort B.

Das funktioniert auch ganz gut, aber es fühlt sich recht langsam an.

Nun meine Frage(n).

1, Ist das richtig umgesetzt/eingerichtet, dass die IMAGES im DEDUP Format via IP repliziert werden? Oder wird vor der Duplizierung das IMAGE wieder rehydriert?

2, Habt ihr einen besseren Vorschlag?

Danke

Netbackup 7.1.0.4

Operating Systems:

Comments 5 CommentsJump to latest comment

loori's picture

Wir benutzen hierfür AIR (setzt zwei Master voraus, was aber zwecks DR auch Sinn macht)

Dabei wird als Vorgang in der SLP "Replication" eingestellt, die beiden betreffenden MSDP werden vorher "gepaart".

Ich denke mal, dass die bei einer normalen Duplicatin die Daten nicht dedupliziert übertragen werden, das setzt ja voraus, dass die Media-Server die Fingerprint-DB teilen, was erst eingestellt werden müsste - und angeblich nur bei Appliances funktioniert?

Das Backup machen wir normalerweise nie in den MSDP, wegen Performance, sowohl beim Backup, als auch bei der Duplizierung auf Tape (50% Differenz). Backup geht in AdvancedDisk, Duplizierung auf Tape und MSDP, mit Replication.

Grüsse

SL

Thomas Schulz 3's picture

Hi Loori.

Das macht durchaus Sinn, aber ich hab noch im Kopf das es eine Replizierung innerhalb eines NBU Masters geben soll, welche ein rehydrieren der Daten nicht zwingend voraus setzt.

Also ein "duplizieren" der Nettodaten.

Gibts das, oder bin ich da auf dem Holzweg?

btw - Unterm Strich kann ich mit der Performance leben, weil meine Media Server "dick" genug sind. Aber wenn es eine bessere Lösung gibt, möchte ich das eben besser kösen.

Kevin Good's picture

I'll try to answer this to the best of my ability.  I apologize my german is not strong enough to respond without using google to translate.

Like Loori said, the unique data must be seeded into the replication target.  This initial copy can take quite a long time.  Earlier this month, I started the initial duplication of a 1 TB Full backup image.  This was replicated across 1/5 of a 10 Mb connection... which was very slow, (less than .25 MB/Sec)

This initial replication took about 3 weeks to complete.  This may seem unacceptable, and too slow, however; if we were to copy 100% of the data across through that link, it would take over 48 days to finish.  Additionally, the replication was stopped / restarted several times during the 3 weeks, but the data was still on the target location when the work was restarted, so it was able to skip through the data that was already present.

Since that replication finished, the subsequent full backup images for that same system complete within 15 hours of the backup completion.

Some things to check, if your replications never seem to improve:

Multiplexing - This is very bad for images written to disk, set the multiplexing to 1, and increase concurent streams to achieve the throughput you need.

Compression / Encryption - If the data you are backing up has been encrypted, or compressed before being backed up, your performance will suffer.  This does not include using the compression / encryption settings within the backup policy (only the data on the client.)

Retention settings of images - If you are expiring full images from the target pool before the next full image is copied, the deduplication ratio will be decreased, which will make more work for the duplication.

*** Google translation below ***

Ich werde versuchen, diese nach bestem meine Fähigkeit zu beantworten. Ich entschuldige mich, mein Deutsch ist nicht stark genug, um ohne Verwendung von Google zu übersetzen, zu reagieren.

Wie Loori sagte, müssen die einzigartigen Daten in die Replikationsziel ausgesät werden. Diese erste Kopie kann eine recht lange Zeit. Anfang dieses Monats begann ich die erste Duplikation eines 1 TB Voll-Backup Image. Dies wurde in 1/5 der 10 Mb Verbindung repliziert ... das war sehr langsam, (weniger als 0,25 MB / Sec)

Diese anfängliche Replikation nahm ca. 3 Wochen in Anspruch nehmen. Dies mag nicht akzeptabel, und zu langsam ist, jedoch, wenn man auf 100% der Daten über durch diesen Link zu kopieren sind, würde es über 48 Tage zu beenden. Zusätzlich wurde die Replikation gestoppt / gestartet mehrmals während der 3 Wochen, aber die Daten noch auf der Zielposition, wenn die Arbeit eingestellt wurde, so war es in der Lage, durch die Daten, die bereits vorhanden war überspringen.

Da die Replikation abgeschlossen, die anschließende vollständige Backup-Images für das gleiche System innerhalb von 15 Stunden nach Abschluss des Backups zu vervollständigen.

Einige Dinge zu überprüfen, ob Ihre Replikationen nie zu verbessern scheinen:

Multiplexing - Das ist sehr schlecht für Bilder auf die Festplatte geschrieben, stellen Sie den Multiplexing auf 1 und erhöhen concurent Streams, um den Durchsatz benötigen Sie zu erreichen.

Komprimierung / Verschlüsselung - Wenn die zu sichernden Daten werden verschlüsselt wurde, oder komprimiert, bevor sie gesichert, wird Ihre Leistung leiden. Dies beinhaltet nicht über die Komprimierung / Verschlüsselung Einstellungen innerhalb des Backup-Richtlinie (nur die Daten auf dem Client.)

Retention Einstellungen der Bilder - Wenn Sie auslaufenden voller Bilder werden von dem Target-Pool, bevor die nächste volle Bild kopiert wird, wird die Deduplizierung Verhältnis verringert werden, was mehr Arbeit für die Vervielfältigung zu machen.

Backups are IT-101 (Do Backups) Doing Backups well is an art form. Nobody cares about getting their data backed up... They only care that you can restore it for them!

loori's picture

Beim Einrichten des MSDP (geht auch später) kann man weitere Server angeben, die auch die Indexierung oder Fingerprinting übernehmen sollen — das wording habe ich nicht im Kopf, ich hab' da vor meinem Urlaub mit gekämpft. Das soll/sollte wohl dazu führen, dass die betreffenden Media-Server über die gleichen Fingerprints verfügen, damit wäre eine Duplizierung auch dedupliziert möglich. Angeblich soll das aber nur mit den Appliances funktionieren. Ich werde das nach meinem Urlaub verifizieren, da ich gerade MSDP aufbaue, um so was einzurichten.

Zur initialen Replication bei AIR kann ich Kevin bestätigen, die Replication erste Sicherung dauerte sehr lang, die zweite ging sehr viel schneller, und jetzt laufen sie nochmals schneller. Auch was die Kompression angeht kann ich die Beobachtung bestätigen, ein DBA komprimierte manuell Oracle-Dumps, der Effekt auf AIR war verheerend.

A bit condensed — englisch is good for that ;-)

While setting up MSDP you can name other media servers, I suppose they should share the fingerprinting. I was told that this works only with the appliances, but I don't know yet. I'll find out after my vacation as I'm setting up MSDP for local replication.

Kevin's observations I can confirm, the initial replication in AIR took quite some time, the following ones became successively quicker. One DBA compressed manually Oracle dumps. The impact on AIR was severe.

Thomas Schulz 3's picture

Okay ich warte dann mal bis du wieder aus dem Urlaub kommst.

Wäre schon prima wenn es innerhalb einer NBU Domain die Möglichkeit gibt die Fingerprint DB su "sharen"

Ich hab erst in 2 Wochen Urlaub :-)