Gyakori kérdések – Azure Backup monitorozása és jelentése

Az Azure Backup több riasztási lehetőséget is támogat: beépített Azure Monitor-riasztásokat, metrikariasztásokat, egyéni naplóelemzés-alapú riasztásokat, egyéni ARG-alapú riasztásokat, tevékenységnapló-riasztásokat és klasszikus riasztásokat. Ha jelenleg klasszikus riasztásokat használ, javasoljuk, hogy kezdje el használni az Azure Monitor-alapú riasztásokat, mivel ezek több előnnyel járnak. A klasszikus riasztások elavultak lesznek, és az elkövetkező években nem támogatottak. További információ az Azure Backup által biztosított különböző riasztási lehetőségekről.

Beépített Azure Monitor-riasztások esetén a kritikus műveletekre/hibákra vonatkozó riasztások alapértelmezés szerint (amelyeket a portálon vagy a portálon kívüli felületeken tekinthet meg) további költségek nélkül generálnak. Ha azonban ezeket a riasztásokat egy értesítési csatornára (például e-mailre) szeretné irányítani, az az ingyenes szinten (havonta 1000 e-mailen) túli értesítések esetében is kisebb költséget von maga után. További információ az Azure Monitor díjszabásáról.

Az egyéni riasztások esetében a fent leírt értesítési költségek mellett riasztási szabályonkénti költség is szerepel. A riasztási szabály költsége a riasztási szabály részeként kiválasztott dimenziók számának arányában változik. További információ az Azure Monitor díjszabásáról.

A metrikariasztások esetében a fent ismertetett értesítési költségek mellett riasztási szabályonkénti költség is van. A riasztási szabály költsége a riasztási szabály részeként kiválasztott dimenziók számának arányában változik. További információ az Azure Monitor díjszabásáról.

Biztonsági mentési riasztások szerint:

• Riasztási szabály: Egy felhasználó által létrehozott szabályra hivatkozik, amely meghatározza a riasztás aktiválásának feltételét. További információ
• Riasztásfeldolgozási szabály (korábbi nevén Műveleti szabály):: Egy felhasználó által létrehozott szabályra hivatkozik, amely meghatározza azokat az értesítési csatornákat, amelyekhez egy adott aktivált riasztást kell irányítani. Riasztásfeldolgozási szabályokkal is letilthatja az értesítéseket egy ideig. További információ
• Műveletcsoport: Arra az értesítési csatornára hivatkozik (például e-mail, ITSM-végpont, logikai alkalmazás, webhook stb.), amelyre az aktivált riasztás irányítható. További információ

Beépített Azure Monitor-riasztások esetén, mivel a riasztások már alapértelmezés szerint generálnak, nem kell riasztási szabályt létrehoznia. Ha ezeket a riasztásokat egy értesítési csatornára szeretné irányítani, létre kell hoznia egy riasztásfeldolgozási szabályt és egy műveletcsoportot ezekhez a riasztásokhoz. Lásd a példát

Metrikariasztások esetén, mivel a riasztások alapértelmezés szerint nem jönnek létre, először létre kell hoznia egy riasztási szabályt annak a feltételnek a megadásához, amelyre a riasztást aktiválni kell. Ha ezeket a riasztásokat egy értesítési csatornára szeretné irányítani, közvetlenül csatolhatja a riasztási szabályt egy műveletcsoporthoz, vagy használhat riasztásfeldolgozási szabályt. Lásd a példát

Igen, metrikariasztások használatával konfigurálhatja a riasztásokat a sikeres biztonsági mentésekhez. További információ

Ha Azure Monitor-alapú riasztásokat használ, az értesítéseket (riasztásfeldolgozási szabályokat és műveleti csoportokat) programozott módon konfigurálhatja. Ha klasszikus riasztásokat használ, az értesítések programozott létrehozása nem támogatott.

Egy esemény bekövetkezése után 20–30 percbe telhet , amíg az adatok elérik a Log Analytics-munkaterületet. Ennek eredményeképpen a Log Analytics-alapú riasztások kissé késhetnek. Azonnali riasztások esetén használjon beépített Azure Monitor-alapú riasztásokat vagy metrikákon alapuló riasztásokat.

Lépjen a konfigurált Log Analytics-munkaterületre. Lépjen a Naplók menüelemre, és futtassa a lekérdezést CoreAzureBackup | take 1. Ha egy rekordot ad vissza, az azt jelenti, hogy az adatok elkezdtek a munkaterületre áramlani. A kezdeti adatküldés akár 24 órát is igénybe vehet.

A tároló diagnosztikai adatait a Rendszer némi késéssel a Log Analytics-munkaterületre pumpálja. Minden esemény 20–30 perccel azután érkezik meg a Log Analytics-munkaterületre, hogy leküldte a Recovery Services-tárolóból. Az alábbiakban további részleteket talál a késésről:

• Minden megoldás esetében a biztonsági mentési szolgáltatás beépített riasztásai a létrehozásuk után azonnal le lesznek küldve. Ezért általában 20–30 perc után jelennek meg a Log Analytics-munkaterületen.
• Minden megoldás esetében az igény szerinti biztonsági mentési és visszaállítási feladatok azonnal le lesznek küldve, amint befejeződnek.
• Az SQL-alapú biztonsági mentés kivételével minden megoldás esetében az ütemezett biztonsági mentési feladatok azonnal le lesznek küldve, amint befejeződnek.
• Sql-biztonsági mentés esetén, mivel a naplók biztonsági mentése 15 percenként történhet, a rendszer 6 óránként kötegeli és leküldi az összes befejezett ütemezett biztonsági mentési feladat adatait, beleértve a naplókat is.
• Minden megoldás esetében a rendszer naponta legalább egyszer leküldi az egyéb információkat, például a biztonsági mentési elemet, a szabályzatot, a helyreállítási pontokat, a tárterületet stb.
• A biztonsági mentés konfigurációjának módosítása (például a házirend módosítása vagy a szabályzat szerkesztése) az összes kapcsolódó biztonsági mentési információ leküldését váltja ki.

A Log Analytics-munkaterület létrehozása után dönthet úgy, hogy legfeljebb 2 évig őrzi meg az adatokat. A Log Analytics-munkaterület alapértelmezés szerint 31 napig őrzi meg az adatokat. További információ.

A diagnosztikai beállítások konfigurálása után az adatok a Log Analytics-munkaterületen kezdenek áramlani. A rendszer a konfiguráció napjától megőrzi az adatokat a munkaterületen a megadott megőrzési időszakra vonatkozóan. A folyamatban lévő feladatok nem lesznek leküldve a munkaterületre. Az események a befejezéskor le lesznek küldve a munkaterületre (sikeres vagy sikertelen). A Log Analytics-munkaterületen elérhető összes adat elérhető lesz a jelentésekben.

Igen, megtekintheti a jelentéseket a tárolók és előfizetések, valamint a régiók között. Az adatok egyetlen Log Analytics-munkaterületen vagy a Log Analytics-munkaterületek egy csoportjában lehetnek.

Ha Ön Azure Lighthouse-felhasználó , delegált hozzáféréssel rendelkezik az ügyfelek előfizetéseihez vagy a Log Analytics-munkaterületekhez, a Biztonsági mentési jelentések segítségével megtekintheti az összes bérlő adatait.

Az Azure Portal akár 15 percet is igénybe vehet, hogy tükrözze az Azure Backup-ügynök feladatának állapotát.

Az Azure Backup meghibásodása után 20 percen belül riasztás jön létre.

Igen. Az alábbi helyzetekben a rendszer nem küld értesítéseket:

• Ha az értesítések óránként vannak konfigurálva, és a rendszer egy órán belül riasztást küld és old fel
• Feladat megszakítása esetén
• Ha egy második biztonsági mentési feladat meghiúsul, mert az eredeti biztonsági mentési feladat folyamatban van

Következő lépések

További gyakori kérdéseket is áttekinthet:

• Gyakori kérdések az Azure-beli virtuális gépek biztonsági mentéséről.
• Gyakori kérdések az Azure Backup-ügynökről