Skip to main content
  • EN

Hallo zusammen, 

 

eventuell ist hier jemand im Forum, der diesen Anwendungsfall schon einmal hatte. Wir versuchen aktuell eine Migration, unserer VCCRs durchzuführen, ohne eine größere Downtime in Kauf zu nehmen. Hierfür haben wir nicht vor, den Tenant zu deaktivieren, sondern uns eine andere Möglichkeit ausgedacht. Zudem nachfolgenden Szenario, haben wir uns auch schon eine Testumgebung gebaut, um den Vorgang einmal zu testen.

Der Grund für diese “Migration” ist der Situation geschuldet, dass wir die Downtime möglichst gering halten wollen. Für den Kunden(alle Kunden) sowie für uns. Meine Frage zielt darauf ab, ob jemand schon einmal eine ähnliche Migration durchgeführt hat.

Hier wäre einmal der “Schlachtplan”: 

  • Ablösung der vccr004-006 hat die höchste Priorität.
    • 3x vccr(013-015) mit rbd auf lvm erstellen
    • rsync von vccr004-006 auf vccr013-015 der Backupdaten durchführen über eine Woche am Anfang des Monats durchfürhen
    • Laufzeiten der rsync-Jobs der unterschiedlicher tage ermitteln
    • Wartungsfenster für Tag mit vermutlich kürzester rsync-Job Laufzeit erstellen. Am besten immer nur einen vccr pro Wartungsfenster durchführen
      • Betroffenen vccr(004-006) in Veeam auf maintenance setzen
      • rsync des Delta durchführen
      • Betroffenen vccr(004-006) in Veeam entfernen
      • Neuen vccr(013-015) in Veeam hinzufügen
      • Rescan des gesamten SOBR in Veeam durchführen

 

Beste Grüße und für diejenigen die Erfahrung/Ideen/Meinungen haben schon einmal dankeschön.

 

Guten Morgen! Dein Schlachtplan ist gut und funktioniert. Veeam hat hier darüber geschrieben https://helpcenter.veeam.com/docs/backup/cloud/moving_backups.html?ver=120

Deine andere Option sonst ist: https://helpcenter.veeam.com/docs/backup/cloud/cc_sobr_migration.html?ver=120 hast du de gesehen? Wenn deine Data ist zu groß für rsync, du kannst kopieren das Daten mit Veeam, pro Backup.

 

Es tut mir leid für mein schlecht Deutsche.

Here is my text in english once again:

Maybe someone in the forum has already encountered this use case. We are currently trying to carry out a migration of our VCCRs without incurring significant downtime. We do not intend to deactivate the tenant for this, but have come up with an alternative solution. We have also set up a test environment to test the process with the following scenario.

The reason for this "migration" is that we want to keep the downtime as low as possible for both the customer (all customers) and ourselves. My question is whether anyone has already carried out a similar migration.

Here is the "battle plan":

Replacement of vccr004-006 has the highest priority.
Create 3x vccr (013-015) with RBD on LVM
Perform rsync of backup data from vccr004-006 to vccr013-015 over a week at the beginning of the month
Determine runtime of rsync jobs on different days
Schedule maintenance window for the day with the presumably shortest rsync job runtime. Ideally, only one VCCR per maintenance window
Set affected VCCR (004-006) to maintenance mode in Veeam
Perform rsync of the delta
Remove affected VCCR (004-006) from Veeam
Add new VCCR (013-015) to Veeam
Rescan the entire SOBR in Veeam

Guten Morgen! Dein Schlachtplan ist gut und funktioniert. Veeam hat hier darüber geschrieben https://helpcenter.veeam.com/docs/backup/cloud/moving_backups.html?ver=120

Deine andere Option sonst ist: https://helpcenter.veeam.com/docs/backup/cloud/cc_sobr_migration.html?ver=120 hast du de gesehen? Wenn deine Data ist zu groß für rsync, du kannst kopieren das Daten mit Veeam, pro Backup.

 

Es tut mir leid für mein schlecht Deutsche.

Hello @MicoolPaul ,

first of all, thank you for your response 🙂 If we implemented the article, we would unfortunately have too much downtime, so we are not considering it at the moment.

Sounds like a good plan, but never attempted this type of migration before. You also need to take in to account the Tenant and changing their replication settings in VCC as well during this process. Keep that in mind, but there will be some downtime, regardless as you cannot do anything like data migration in real-time for Veeam.

Comment


Terms & Conditions