Ja, nu största problemet med SnapCenter löst 🙂

Supporten har inte kunnat få fram samma fel. Har du skapa cluster och tagit AG frågade jag. Fick inget svar. Så jag tolkar det som nej.

Han ville att jag ska ändra värdet på MaxRetryForUninitializedHosts från 10 till 40. Det hjälpte förstås inte!

Kan du utöka värdet? Visst satte det till 80. Tog jävla tid för att få samma resultat = jobbet antingen inte startar på AG maskiner, eller skiter det i AG och ta backup på de databaser som inte ingår i AG.

Ta du ta databasbackup istället för AG backup? Ta backup på varenda databas replica i samtliga kluster noderna, även om de är läskopior?! 😮
Vi vill ha och det ska vara AG backuperna. Det skulle innebära 2-3 gånger så mycket diskåtgång. Men visst jag testar.

Skapade nytt jobb (Resource Group/RG) i labbmiljön. Pluginen på en av servrarna i klustert kraschade och vi fick mycket larm på de servrarna. Jag avbröt jobbet.

Men, sen kom jag på det jag borde ha kommit på tidigare, ta bort icke-AG databaserna (databaser som inte ingår i någon AG) från jobben. Jobbet startade på samtliga servrar och tog backup som den skulle 🙂

Alltså, version 4.1.1 av SnapCenter klarar inte längre att starta på en server som har AG, om jobbet ska backa icke-AG databaser som finns på samma server! Jobbet startar och backar AG databaser om icke-AG databaser, om de icke-AG databaser tillhör annan host (server).

Jobbet funkar dock om det startas utifrån SnapCenter = kickas igång från SQL Server, Orchestrator, via PowerShell på min burk, eller om jag startar jobbet manuellt i SnapCenter. Då klarar det av att backa AG och icke-AG databaser som tillhör samma host!

Det funkade att mixa RG (jobbet) med AG och icke-AG databaser i version 3.0, 4.0 & 4.0P2, men inte i version 4.1.1. De andra 4.x versionerna hade andra problem, som är lösta, men nu är det som gick i de versionerna funkade inte i denna version.

Han skulle öppna internt ärende skrev han. Jag får öppna ärenden på de andra felen skrev jag. Har inte orkat göra det.

Har sen suttit och tagit bort gamla backuper med.
Backuperna namnsätts med RG:s namn. Så för varenda test, eller anpassning vi gjort för att kringgå fel i de andra versionerna genererat backup med olika namnstandard och när samma RG inte finns längre så rensas inte de gamla backuperna.
Fick t ex skapa RG som tar fullbackup på databaser som har Simple Recovery Model och RG som tar fullbackup på databaser som har Full Recovery Model, då version 4.0P2 helt plötsligt inte klarade av att backa dessa i samma RG!
Alla dessa (och de andra varianterna på RG som inte finns kvar) låg kvar i systemet.
Får sitta och få fram PowerShell skript som gör det jag gjorde manuellt. Förhoppningsvis slipper vi skapa nya RG, men man vet aldrig!