Kulcs-Soft backup

Offtopic

Egy érdekes helyzetbe kerültem a hétvégén és gondoltam megosztom veletek. Tanulság és egyéb gyanánt.

Adott volt egy kb 10 éves szerver (Server 2003 op.rend) egy HDDn és még anno én tettem bele 2 db backup hddt, hogy legyen valami mentés is. Nos ez a szerver 2015be lett üzembe állítva és a Kulcs-soft integrált könyvelési rendszer futott/fut rajta.
Anno mikor telepítve lett, az automatikus backup be lett állítva, ütemezve ami minden éjszaka el is végezte a mentéseket szépen. Keletkezett ugye 4 db backup file (egyszeres, fokony, hazi, targyi) ezeket raktároztam a backup HDDkre is, hogy minden meg legyen ha beütt a halál.
4100 backup file, 160GB (2015 óta)

Ez a szépséget elterveztük, hogy felszámoljuk. Kap új vasat , redundás SSDvel, új backup HDDkel.

Szombaton kezdődött az akicó, amint elkezdtük lemásolni az adatokat kifagyott a rendszer, újraindítás után HDD kattog.
PUFF, ok nem gond backup HDDk bekött másik gépre, szombat hajnali mentések királyul megvannak. Ebből lehet dolgozni.

Új vas beállít minden helyére kerül , adatbázis visszatöltés sikeres. Adatok meg vannak.
OK

Első munkanap kapom a jelzést, hogy kb 8 cég hiányzik az adatok közül.

Az hogy lehet ? Végig nézem a backupokat egész 2017 évit minden nap és tényleg hiányoznak az adott cégek.

Felhívom a szoftver gyártóját és backup beállítóját, hogy miért ? és hogy ? és mivan ?

Kedves Hölgy telefonba jelzi, a cégek amik hiányoztak lehetséges , hogy új cégek voltak nem régen felvéve ?
Mondom igen lehetséges.

MINDEN ÚJ CÉG FELVÉTELÉNÉL ÚJRA KELL ÁLLÍTANI A BACKUP SCRIPTET MERT NEM MENTI CSAK A LÉTREHOZÁS PILLANATI ADATOKAT.

Ezzel le is zárták a témát.

Én ilyet még életemben nem hallotam , hogy egy backup válogat.
De legalább mikor nyitunk egy új céget egy párbeszéd panel ugrana fel, hogy figyelj te barom állítasd újra a backupot mert nem kerülök bele !!!

A kattogó HDD ment adatmentőkhöz , hátha vissza tudna valamit kaparni belőle és meg lesz az elveszett 8 cég. 155+áfa
Kulcs-soft kifizeti ? Biztos, hogy nem!

Csak okulás képp

P

  • 2065 megtekintés

( pike.killer v | 2018. 01. 16., k – 09:17 )

Sajnos ez nem egyedi eset. Nevesebb gyártónál is van, hasonló probléma amikor riportot készítesz. Gyártó azt mondta, hogy az a riporthoz szükség elkérdezéseket jobb elkészítésekor aktuálisan legenerálja és azt futtatja az ütemezett feladatban. Gondolom itt is erről lehet szó.

Mentéssel kapcsolatban annyi megjegyzésem van, hogy sokan elfelejtik a mentést nem csak beállítani kell, hanem rendszeres időközönként ellenőrizni. Esetlegesen visszaállítási tesztet végezni, hogy ilyenek nem forduljanak elő. Egy migrálás/átalakítás/frissítés előtt ildomos egy teljes mentést készíteni és ellenőrizni ennek a sikerességét, hogy egy esetleges hiba esetén legyen miből visszaállni.

( uid_395 v | 2018. 01. 16., k – 09:32 )

A Kulcs-Szoft-tól csak menekülni szabad.. Borzasztó a hozzáállásuk bármiről is legyen szó... :/ (tapasztalat)

( Crayon | 2018. 01. 16., k – 10:03 )

elkezdhetünk azon morfondírozni, hogy mennyire sz*r a ks adatmentő csodája, de sok értelme nincs. Köszi, hogy megosztottad!

Általános tanulságok:
1. nem menteni kell tudni, hanem visszaállítani (magyarul ki kell probálni néha egy restore-t is és akkor ezek nem élesben jönnek elő)
2. az adatbázis motorhoz (ami a ks-nél most talán firebird ha jól rémlik) van "kézi" módszer az exportálásra/importálásra, érdemesebb azt használni mentésre (vagy írni rá egy pársoros saját scriptet)

2. tehát azt javaslod, hogy egy komplett könyveléssel és egyéb más pénzügyi dolgokkal kapcsolatos SW gyártó cég (KS) szoftveréhez, amiért a user kifizet egy rakás pénzt, még kelljen "kis scripteket" írogatni, hogy tuti jó legyen a mentés? Amit a cég nem tud a saját SW-n belül normálisan megoldani?

Welcome 2018* :)

Na igen workaround egy pénzügyi szoftvernél :/

Ezért is kerülöm a KS-t mindenhol ahol lehet.. Van helyette sokkal jobb alternatíva, olcsóbban és rendes supporttal. :) (direkt nem írok nevet, nem akarok reklámozni)

De amúgy igen, abban egyetértünk hogy illene nekik ezt "házon belül" megoldani :)

ez egy nagy igazság!

és ráadásul , ha vissza is töltöm 50 cég és +/- nem tudom kibogozni.

de egy olyan cég akinek éves díjat fizetünk a szoftveréért, kb 380.000 + áfa / év , legalább annyit írjon ki, az új cég nyitásánál hogy szólj a rendszergazdának b+ csinálja újra a mentést :D

( joco01 v | 2018. 01. 16., k – 11:30 )

Én is vettem részt KS üzemeltetésben, volt egy dedikált MSSQL példánya és azt mentettük DPM-mel. Csak egy cég volt, de ha lett volna másik, a DPM észrevette volna.

Mivel ez fizetős szoftver, én simán végigjárnám a hivatalos eszkalációs szinteket, mert ez eléggé kimeríti a "szarul működik" fogalmát.

Igen, mert nem azt írja a scriptbe például, hogy Cégek= *, hanem simán felsorolja. Meg még a darabszámot is beleírja, ha jól emlékszem.
Anno próbáltam nekik jelezni a problémát, de mikor 10 perc alatt nem jutottak túl azon, hogy mi a termékszámom és melyik cégtől vagyok, akkor feladtam. Akit csak tudok, próbálom lebeszélni a kulcsos csodákról. Mondjuk amit eddig láttam, egyik kutya...

10 cég veszett el , ha az adatmentősők nem tudják visszaállítani akkor sztem a főnökasszony megkérdezi Kulcsot, aztán ki tudja , hogy mennyire szarják le az egészet.
Amúgy igen, csomó havi/éves díjat fizetünk és pont az a rész nincs rendesen megcsinálva a programban ami a legfontosabb.

cpeter

Ez is súlyos: "Az adatmentési művelet akkor lesz sikeres, ha a mentés időtartama alatt egyetlen felhasználó sem csatlakozik az adatbázishoz"

Egy MSSQL backup garantáltan konzisztens, nem? Mindegy is, ahogy írtam, az egész MSSQL-t vagy az egész VM-et kell menteni, a szar scriptjüket meg hagyjuk.

igen, sok súlyos dolog van

mostantól már közvetlenül mentek, de ez nem vigasztalja az informatikához laikus könyvelőket, akiknek (ha adatmentő nem tudja visszahozni) újra kell könyvelni adott cégeket. aminek persze díja van stb stb stb
és biztos vagyok benne, hogy kucssoft ezt a díjat nem fogja téríteni...

cpeter

Van. Volt pár hét erős túlóra.
azóta is történt már pár érdekes dolog hasonló cégnél, szóval nem lepődök meg semmin sem.

Olyat is láttam, hogy minden hét adott napján később kezdték a munkát, mert akkor reggel csinálták a mentést. A szervert éjszakára nem hagyják bekapcsolva, minden este off, tehát rendes mentést sem tudok csinálni.
Egyszer a leállítás kiadása után valamit még csinált a gép (a következményekből feltételezem, hogy némi adatbázis piszkálás is volt a dologban), majd vártak annyit, amennyi idő alatt ki szokott kapcsolni a gép, majd ekkor ups power off. Elvégre sietünk haza. Másnap volt meglepi, mert semmi sem ment, ami az adatbázist használta volna. :) Ekkor kiderült, hogy fél évig hiába indultak később, mert nem volt mentés. Szerencsére sikerült gatyába rázni a dolgot, de voltak következmények.

( dj | 2018. 01. 17., sze – 08:29 )

Igen, sajnos, nem sajnos a kulcssoft mentése így működik. Amíg én is felügyeltem egy könyvelő cégnél, ki volt adva mindenkinek, hogy új cégnél szóljanak, mert bele kell rakni a mentésbe.

Csak amíg régen volt egy cégnek IT-sa, aki ott élt, tudott a dolgokról (ő rendelte meg a programokat és beírta a szoftverleltárba), ismerte a környezetet (csak ez volt a dolga), gyakrna csinált kis python/php/mono scriptetek, amivel gyorsabb a napi munka ... addig a ma divatos "távoli" IT-sok parancsokat teljesítenek (üzemeld be a nyomtatót, mappeld a meghajtót). Az ügyfél viszont nem ad olyan parancsot, hogy "tedd be a mentésbe az új céget is" :)

Ez szabályzás kérdése. Ha a mentés beállításkor jelzed az ügyfélnek, hogy a mentés beállítás megtörtént, de a jövőben az ilyen és ilyen esetek alkalmával ezt módosítani kell, akkor ezzel megelőzhető ez a helyzet. Persze nem utolsó sorban a felelősség is az ügyfélé lesz. Az üzemeltető lehet pro-aktív és felírja a feladati közé és időközönként rákérdez/ellenőrzi.

Miért is kellene jelezni? Persze eltekintve attól, hogy (mint fent is írtam) az ember csak belenéz a scriptbe. Ha egyszer beikszeltem, hogy minden céget menteni szeretnék, akkor nem érzem jogosnak azt, hogy ezt minden új cég után újra meg kell tennem.
Az ügyféltől sem várható el az, hogy minden egyes új cég felvételénél eszébe jusson, hogy szóljon a rendszergazdának, hogy új cég van, azt is menteni kell.
Sokkal egyszerűbb lenne, ha normális terméket csinálnának ennyi pénzért.

Értem, hogy le van írva, de mennyire életszerű, hogy egy könyvelőiroda, akihez mondjuk 1-2-5-akárhány hónap után jön egy új kuncsaft, megnyitják a céget, akkor eszébe jut akár az tulajnak, irodavezetőnek, 42.könyvelőnek, hogy szólni kellene?
Tapasztalatból mondom, semennyire. Ha a rendszergazda nem gondol erre, és nem nézi meg mondjuk havonta, akkor nem lesz mentve.
Ha már rendes mentést nem tudnak/akarnak csinálni, akkor legalább egy figyelmeztetés dobhatna új cég nyitásánál.

Annyira volt életszerű, hogy működött. Nem volt adatvesztés soha. Egy ilyen szoftvert egyébként nem az IT-sek választanak, hanem a könyvelők és/vagy a vezetők és ha nekik tetszik ez a szoftver, akkor ez el kell viselned. Az IT-nek az a feladata, hogy alkalmazkodjon a szoftver követelményeihez. Ha fejreállsz és hepciáskodsz, hogy így szar meg úgy szar, attól még neked kell az üzemeltetésről gondoskodnod és alkalmazkodnod kell. Ha ezt nem teszed, akkor úgy jársz, mint cpeter kolléga. A lényeg, hogy találj valamilyen megoldást, mert a felelős te vagy nem pedig a szoftver. A felettesed nem fogja érdekelni, hogy szerinted ez úgy szar, ahogy van, mert van leírás, hogyan kell csinálni, ha nem követed te vagy a hunyó.

2018 van. Olyan megoldások kellenek ahol senki nem jelez semmit minden működik a lehető legkevesebb emberi munkával és beavatkozással.

Ha Kulcs lennék adnék felhős tárhelyet a mentésnek, ahová az SW ment és vissza is tud állni. Szednék érte pénzt is, "nem kellene" rendszergazda.

Azért ezzel óvatosan, van ahol kizárt hogy 3. félnél legyenek ilyen adatok tárolva. Főleg ha ilyen a szoftverjük.... milyen lehetne náluk tárolni érzékeny adatokat a felhőjükben :)) <- Inkább csinálják meg normálisra a Kulcsosok a saját SWjüket hogy ne ilyen sz.r legyen. :)

Titkosított állományok? Hm? Ha pedig nem bízunk meg az SW gyártóban,akkor ne használjuk az SW-t. Azon pedig a felhasználó már a megvásárlásával túljutott, hogy bízik-e.

Ha pedig a könyvelés érzékeny, akkor jobb, ha a sem a könyvelő sem a NAV nem látja. :) Mondjuk azt, hogy korlátosan érzékeny.

Troll: :) nyilván ahol ilyen feltételekkel szembesülhet és kötelező, akkor a cég megoldja hogy legyen offsite-backup. Akárhol. Akár berakat egy saját szervert X internetszolgáltatóhoz a BIXben és kész. Vagy bérel telephelyet, stb. stb. Ezer féle lehetőség van off-site backupra, úgy hogy az megfeleljen pl adott jogszabálynak és mégis cégen belül maradjon az a backup is, de nyilván totál más helyen / helyeken.

Troll x2: de nyilván atomtámadásellen nem véd! :)

( gelei v | 2018. 01. 17., sze – 10:24 )

valaki mondja hogy ez komoly, mert viccnek nagyon durva lenne

ugyanitt van eladó fejlesztési tanácsadási mérnökidő, nem olcsó de ahogy látom, a felhasználói elégedettségen nagyon tudna lökni

( flatline | 2018. 01. 17., sze – 12:48 )

Már bocs, de a kulcs alapkoncepciója egy nagy gané. Tovább nem is kommentálnám, mert nem lenne szalonképes szavam.

( hnsz2002 v | 2018. 01. 17., sze – 16:05 )

Mivel egy sima firebird van alatta, gbak-kal menthető. Jobb ha csinálsz rá saját scriptet.

Egyébként nekem egy régi cég licencével volt probléma ami előtt teljesen értetlenül állt a support, és hetekig vakaróztak hogy mi legyen... Az a helyzet egyébként, hogy tipikus kívülről mézes-mázas szoftver, ami belülről meg szar és rohad.
--
"Sose a gép a hülye."

Na most, az hogy kaki az egész, az egy dolog. De attól még az, hogy a mentés elkészül-e, arról készül-e, ami tényleg kell, megvan-e visszamenőleg, visszaállítható-e, az neked, mint üzemeltetőnek a felelőssége. Nekik semmi közük ehhez. Akkor sem, hogy adnak hozzá egy toolt, amivel amúgy lehet mentést készíteni. Nem lenne kötelező. De használni sem kötelező.
A szoftver használatáért, a supportért (ami olyan, amilyen), meg a jogi követések miatti fejlesztésért és jogszabály szerinti működésért fizetsz. Egyébként a saját scripted is azt menti le, amit beállítasz.
--
"Sose a gép a hülye."

értem, akkor veszünk még egy szervert ahová időnként visszatöltöm a backupot és egy csaj mind a 50 céget végignézi , hogy minden megvan e. mert ne legyen már kötelességem követni kit mikor merre hogyan könyveltek

nem életszerű

akkor ne adjon toolt és akkor tudom, hogy írok egy scriptet és az tuti lementi. mostantól amúgy ez lesz.

cpeter

Nekünk nem véletlen van saját rendszerünk a mentések követésére, és nem véletlen napi rutin a mentések ellenőrzése. Ez van, hogy 2 perc, mert ránézel, és minden zöld. Van hogy 20-30, mert egy vagy több valami nem ment le (kellhet destination check, miért nem ment le, mi volt a baj, kijavítani, esetleg ráindítani még délelőtt kézzel, ha már éjszaka nem ment le, stb), de olyan is van, hogy az egész délelőtt azzal megy el, mert kijött valami hiba, elértünk valami limitet, bugba futottunk, vagy bármi, ami nem 2 perc. És ezt javítani kell, hogy másnap lehetőleg már jó legyen. Rutinpróba szerűen ellenőrizni is szoktuk, mert OK hogy zöld, de lehet hogy a követési rendszerben a feltétel szar, vagy mondjuk a script, ami a mentést csinálja, és egyszerűen rossz visszatérési érteket ad, stb. És bár ritkán (mondjuk évente) bizony olyat is csinálunk, hogy ok, nézzük végig egy ügyfélnek az összes mentését, aminek a legjobb tesztje az, hogy húzzuk vissza valamelyik szervert nulláról, kompletten mentésből. Ha megy, OK. Ha nem, akkor gáz van. Itt nem csak arra kell gondolni feltétlenül, hogy rossz a mentés, hanem arra is, hogy mondjuk az adott backupból hogy veszel ki csak egy valamit. Vagy hogy veszel ki mindent. Az is kérdés lehet, hogy mennyi idő alatt megy le... Szóval nagyon sok dolog van itt.

Volt már, hogy ilyen ellenőrzéssel bukott ki, hogy hopp, nem is jó könyvtárat mentünk. Vagy hogy valamiről nincs mentés. Ami lehet akár egy 3KB-os config is, de ha nulláról kell újra előállítani, kiguglizni egy komplett visszaállítás esetén, vagy neadj isten emiatt több más dolgot újrakonfigrálni, akkor mindjárt plusz pár óráról beszélünk. Továbbá amiatt sem volt még soha bajunk, ha valami kiderült hogy nem jó, és ezt jeleztük az ügyfélnek. De abból már igencsak lenne (szerencsére még nem volt), ha mindez akkor derülne ki, ha szükség lenne rá.

Akár tetszik, akár nem, ez is az üzemeltetés része. Nagyon fontos része, talán az egyik legfontosabb. Ezt hívják rendszerfelügyeletnek, többek közt. Ha nem tetszik, akkor nem neked való. De, baromira életszerű.

Neked nem a könyvelést kell követni, hanem a mentést. Meggyőződni arról, hogy egyrészt elkészült, másrészt pedig amit mentesz, az jó és ép. Neked kell belőle visszaállni. Ha egy adatbázis dump sikeres, te pedig vissza tudod állítani, akkor biztos hogy Gizike felrögzített számlája, vagy akármije is ott lesz és úgy, ahogy ő csinálta. Az hogy jó főkönyv alá kontírozta-e, vagy adótörvény szerint helyes-e, már nem a te dolgod.

Nem kell feltétlen másik szerver sem, pont jó egy virtuális gép, vagy akár ugyanarra a gépre egy másik teszt adatbázisba, másik instance-ba, stb. ha nagyon nincs más.

Ad egy toolt, ami menti amit beállítottál. Nem értem ezzel mi a probléma. Ennyi erővel perelheted a hdd gyártót, hogy miért ment tönkre a diszk, vagy a windowst, mert széthajtott, elkoptatta a merevlemezedet, vagy a firebird-öt, hogy mit képzel, hogy egy kattogó szektorhibás diszkről miért nem tud adatot olvasni.

Egyébként, ha már itt tartunk, az üzemeltetés része mondjuk a monitoring is, és bár a smart sem mindenható, és nem is 100%-os, de az esetek jó részében azért jelzi a problémát. Az, hogy neked nem volt erre monitoring, egy dolog, de az sokkal gázabb, hogy 10 év alatt, mióta a mentés be lett állítva, egyszer sem nézted meg hogy mit ment, nemcsak visszaállítást, még ennyit sem, hogy legalább a zip-et kibontod és megnézed mi van benne - mert történetesen itt már abból szemre látszott volna, hogy nincs benne minden DB.

Szóval ezt fogadd el, és ez szar lehet, de ha te üzemeltetsz ott, és ezért vállaltál felelősséget, akkor ezt az adatmentés költséget sajna neked kell fizetni.
--
"Sose a gép a hülye."

természetesen a felelőség kérdés körbém benne vagyok , főleg HDD körül. ezen nincs is vita.
a backup pedig volt ellenőrizve, volt is belőle cég visszaállítva , pechre pont az amivel most nincs is gond.

igen, ahogy előttem is írták, ha ott ülnék minden nap, és csak ezzel az egy céggel foglalkoznék. tuti lenne mindenre idő. de sajnos nincs és a toolba nem kételkedtem mert hát mentett , millió cég benne volt, vissza is állítottunk már sérült céget.

ebből is tanult az ember

cpeter

( zsolna | 2018. 01. 20., szo – 14:48 )

Szerintem van még egy érdekessége a storynak.

A kulcsos cuccoknál uj cég, év és frissités utáni db update csak admin jogokkal hajtható végre.

Na az "admin" az aki az admin. Mielött/miután felvette a céget nyomja a backupot és frissiti a scriptet. ☺

Hogy technikailag ez milyen... ha valamiért ez van ezt kell adminolni.