Napi mentés ellenőrzése

#!/bin/bash
FILE=/etc/resolv.conf
if [ -f "$FILE" ]; then
    echo "$FILE exists."
else 
    echo "Szar van babám!" | mail -s "Ajjaj" user@domain.tld
fi

Mivel "teszed el" fájlszerverre? Ha script, akkor nézheted a dátumát: ma készült-e? Ha igen, másolsz, ha nem, akkor e-mail. Ehhez nyilván kell SMTP szerver, viszont curl van windowsra is és a curl egy svájci bicska, tud levelet is küldeni.
Ami itt necces lehet: ha a mentés megszakad, akkor a fájl ugyan "elkészült", de hiányos/hibás - az ellen nem véd, azt máshogy kell ellenőrizni.

Hát alapvetően a megközelítés szar. Mert pl. a visszatérési értékét kéne figyelned, ami általában 1 jól meghatározott érték esetén jó, minden más szar.

OMFG!!! A google-t nem tudod használni, de windows és MSSQL szervereket üzemeltetsz.

Mi csinálja a mentést? Saját script vagy valamilyen mentőszoftver? Utóbbi 99%, hogy tud riportot generálni és küldeni. Egy scriptbe - akár PS, akár Bash - 10 perc max. belereszelni a levélküldést.

PS: Send-MailMessage

Ha elegáns megoldást akarsz, akkor feltelepíted Windowsra a helyi SMTP szolgáltatást, bekonfigurálod relaynek és azon keresztül küldöd ki a leveleket. Így még a szinkron működés se elvárás, késhetnek a levelek, de nem vesznek el (elvileg). IIS 6.0 Manager konzolon keresztül tudod konfigurálni.

Alapvetően én is visszatérési értéket figyelek, de az nem minden esetben megbízható.

Kicsit továbbmenve: a backup önmagában kevés lehet. Kell néha egy szúrópróba szerű restore test. Láttam már olyat, hogy valahol évekig mentettek mysql DB-t, és mikor kellett a backup kiderült hogy a visszatöltés nem, vagy csak szopóágon működik (mariadb verzió, userek, jogosultságok stb. ...). Persze ehhez infrastruktúra is kell, mert drága dolog éles rendszerrel egyenértékű HW-t fenntartani csak azért, hogy néha restore test legyen.
De megeshet, hogy meghálálja magát. :)

Nehéz meghatározni a gazdasági és technikai szempontok között az optimális egyensúlyt.

Szerintem is a mentés meglétét kell ellenőrizni, illetve egy sanity checket érdemes lehet futtatni rá: például, hogy a mérete nem csökkent, nem változott sokat az előzőhöz képest, ilyesmit.

A monitorozást pedig úgy kell csinálni, hogy ne az a rendszer riasszon, amelyik nem működött. Mert simán lehet, hogy a riasztás sem fog működni. Hanem egy olyan rendszer kell, ami független attól amit mentesz meg amire mentesz és akkor riaszt, ha _nem_ jön meg a jelzés, hogy minden lefutott rendben.

Petersonnal is egyetértek.

Persze csak akkor, ha tényleg fontos amiről szó van.

Nem ismertek tökéletesen a körülmények, de én mindig azt mondom, hogy ilyen custom dolgoknál az ellenőrző script az teljesen külön legyen az eredetitől, ne legyenek egymás futására hatással.  Plusz olyan daemon vagy service kell ami megbízható. Van erre vélhetően több is, de a legegyszerűbb egy cronjob.

Ha tudod, hogy a mentés elindul hajnal 1 órakor és legtöbbször 2 óráig végez, akkor belövöd a cront, hogy 2 óra 10 perckor csekkolja le a fájlt és szóljon ha nincs ott. Ennyi.

Finomhangolni valszeg kell, lehet állítgatni kellaz időkön.

Megjegyzem, ez csak a fájlt csekkolja, de annak tartalmi helyességét nem. Az külön sztori.

Az is lehet gond, ha a scripted túl gyorsan lefut.

Egyébként ha nagyon gagyiztok, és rá tudtok szánni pár dodót, akkor betolhatjátok az ilyen mentős cron scriptekek cronitorba. Az figyel egy csomó dolgot, exit code-t, lehet bele tenni elvileg alerteket is, stb.

Bár én nagyon sajnálnám rá a pénzt, van akinek jól jöhet.

(nem a kérdésedre válasz, de hátha segítség)

Ha osql-ből indítod az mssql mentést, és megadod a -b opciót, akkor az errorlevel értéket beállítja hibás futás esetén, ezt tudod csekkolni.

-b
Specifies that osql exits and returns a DOS ERRORLEVEL value when an error occurs. The value returned to the DOS ERRORLEVEL variable is 1 when the SQL Server error message has a severity of 11 or greater; otherwise, the value returned is 0. Microsoft MS-DOS batch files can test the value of DOS ERRORLEVEL and handle the error appropriately.

Előkerestem régi MSSQL backup scriptjeimet, küldök néhány részletet, ha esetleg saját backup scripteket akarsz írni.

Ez kilistázza az összes adatbázist (be kellett építenünk egy ilyet, mert a fejlesztők rendre elfelejtettek szólni, hogy új adatbázist hoztak létre, amihez kellett volna beállítanunk mentést):

OSQL.exe -E -Slocalhost -h-1 -Q"SET NOCOUNT ON;SELECT LTRIM(RTRIM(name)) FROM sysdatabases WHERE name NOT IN ('master','tempdb','model','msdb');"

Újabb mssql szerveren lehet simán TRIM(name).

Ez pedig végiggyalogol a fenti alapján listázott adatbázisokon, és lementi:

set BACKUP_DIR=D:\backup
set BACKUP_LAST_LOG=D:\backup\backup.last.txt
set BACKUP_FILE=sqlbackup_%date:~0,4%-%date:~5,2%-%date:~8,2%.bak

For /f %%G IN ('C:\tools\scripts\listdb.bat') do (
	osql -b -E -Q "BACKUP DATABASE [%%~nG] TO DISK = N'%BACKUP_DIR%\%BACKUP_FILE%' WITH COMPRESSION" -w 120 -o %BACKUP_LAST_LOG%
)

Mivel mssql nem szeret hálózati meghajtóra menteni, lokális diszkről egyből mirrorozni kell egy hálózati meghajtóra is, onnan mehet pull backup rendes backup médiára.

Nyilván ettől függetlenül magát a script futását is ellenőrizni kell egy független eszközzel.

Jól eldumálunk, de  srác idejött, kérdezett, majd eltűnt. :) Lehet máskor nem kellene ilyen lelkesnek lennünk. Főleg, hogy 17 éves reggel kérdezte amit.

A szkriptes mentéseket én elegedném ahogy van. Ha windows server és napi mentés kell róla, akkor pénzt keresnek vele, ha pénzt keresnek vele akkor legyen pénz egy megfelelő mentési megoldásra is.

Egy havi fizetős Azure Backup vagy egyéb felhős megoldás eleve offsite és online lenne. Ha helyileg kell tárolni akkor pedig valamilyen backup szoftverrel.