Tárhelyszolgáltató keresés

Szerverek

Sziasztok!

Tárhelyszolgáltatót keresek VPS-ek számára.

Feltételek:

- Magyarországon legyen a szerver

- Normális backup szolgáltatás ahol egy kattintással tudok backupolni, restorolni (pl. mint hetznernél)

- 99%+ rendelkezésre állás

- Minimum havi 20TB adatforgalom

 

Köszi előre is, ha tudtok ilyeneket!

( ghajmasi | 2024. 12. 04., sze – 07:45 )

Lehet, hogy elsőre meglepő, de pl. Telekom:

-profi adatközponti környezet ("Dataplex")

-opcionális VEEAM backup

-magas rendelkezésre állás (vmware környezet, hibatűrő cluster, nem stand alone hostok local diskekkel)

-nincs adatforgalmi korlát , nemzetközi irányba se

+1: lehet tetszőleges konfigurációt online összerakni,megrendelni

( gelei v | 2024. 12. 04., sze – 10:25 )

Szerkesztve: 2024. 12. 04., sze – 10:25

"Normális backup" a Hetznernél:

When creating Backups [...], we recommend that you power off your server to ensure data consistency on the disk. You can also create them from a running system. However, in this case, we cannot guarantee data consistency.

Értsd jól: egy nem az általad megválasztott időpontban készülő napi backuphoz le kell állítani a gépet, hogy konzisztens legyen. De legalább olcsó, és mivel 7 backup slot van, valamelyik csak konzisztens lesz. :)

Világos, csak megpróbáltam rámutatni, hogy a "normális backup" meglehetősen alulspecifikált :)

Offtopik, de képzeljünk el egy közepes forgalmú akármilyen webappot, mondjuk egy pgsql-lel mögötte - mekkora összegben mernél rá fogadni, hogy a hetzner-féle snapshotból garantáltan konzisztensen vissza tudsz állni? Főleg, hogy a fenti idézetből a [...] az a snapshot volt :)

Ohh, ez tény, meg azért érteni is kell a "normális backup"-hoz, mert pont azért amit írsz, a snapshot sem életbiztosítás, ha nem megfelelően csinálod:

Pl. nem random kell böködni a snapshot készítést a gui-n, hanem API-n keresztül miután konzisztensre húztad az állapotot (mysql alatt tudsz flush-t előidézni és lockolni, míg az api request elmegy, aztán feloldható). Feloldásig write lock lesz a db-n, de a snapshot elindul 2-3 másodperc alatt, ezt követően már oldható a dolog és legalább a db konzisztens lesz a snapshot image-ben

// Happy debugging, suckers
#define true (rand() > 10)

Mi tortenik azzal a db-vel, ami egy aramszunet eseten nem lockolt es flush-olt?

Mi a kulonbseg egy block device szintu snapshot es egy aramszunet kozott?

 

Amelyik db ettol paffra megy, az annyit is er. Persze vannak edge case-ek, de 2024-ben jellemzoen egy tisztesseges (ertsd: mai ertelemben veve teljesen atlagos) db es app konzisztens kell, h maradjon egy ilyen akcio utan.

értsd én így mentek a leggyakrabban

megkerdeznem ha a ptovidert a részletekről, valószínűleg hasonlo megfontolasbol irtak, amit, mint mas itt fent

felesleges tulgondolni

ha a szolgaltatoban nem bizol (ne bizz), akkor meg ugyis mind1 es csinálj olyat, amiben bizol

 

Szóval mire fel a hajciho?

Erről már parázs vita volt. A tetszőleges DB nem lesz minden pillanatban konzisztens a diszken, ezt mindenféle recovery loggal próbálják orvosolni (tehát az hogy visszajön egy konzisztens állapot, az recovery eredmény, és nem alapvető működésé), de biztosan lesz áramszünet esetén ilyen olyan okból elhagyott tranzakció. Normális adatbázis "appot" csak a saját dump tooljával tudsz normálisan menteni. Egy kivétel lehet, amikor a backup tool, pl. a Veeam, megkéri az OS-t (VSS) és az ismert DB szervert, hogy akkor legyen szíves a diszken konzisztens állapotot produkálni, és hopp gyorsan lementi. Nyilván ami után jön, az valami RAM vagy CoW cuccba halad be, és ha vége a VSS eseménynek, akkor összehúzza.

Például, de azért ehhez nem kell három diploma, hogy belátható legyen: https://www.veeam.com/blog/how-to-create-a-consistent-vm-backup.html

A "dehát eddig nekem eddig jó volt", az jellemzően a szerencse, és a rengeteget fejlődött FS-ek, és db szerverek okán van.

VPS mentésnél az adatbázist tessék dumpolni, és kezelgetni, azt lehet rendesen visszatölteni, akár önmagában. A filerendszer pedig majd lesz valamilyen állapotban a snapshotban.

Igen, ha már comitted, akkor legyen meg. Ez nem azt jelenti, hogy mindenképp az adatbázis file-ok állandóan konzisztensek, hanem azt, hogy valahogy legyen meg, akár egy recovery logból, és majd ezt megpróbálja visszahozni. Ugyanakkor a recovery log jellegűvel is lehet probléma, nem zárható ki. Nyilván egy valamilyen áramkimaradás elleni védelem (pl. datacenter SSD-ken a buffert menti áramkimaradáskor, és majd csinál valamit) és társai ezeket minimalizálják. Ugyanakkor mentést erre alapozni, hogy dehát ACID, és majd megcsinálja, ez szintén a "működni szokott" kategória.

Nézzük mit mond a Postgres doksi mondjuk: https://www.postgresql.org/docs/current/backup-file.html

"There are two restrictions, however, which make this method impractical, or at least inferior to the pg_dump method:

  1. The database server must be shut down in order to get a usable backup. Half-way measures such as disallowing all connections will not work (in part because tar and similar tools do not take an atomic snapshot of the state of the file system, but also because of internal buffering within the server). Information about stopping the server can be found in Section 18.5. Needless to say, you also need to shut down the server before restoring the data."

In database systems, durability is the ACID property that guarantees that the effects of transactions that have been committed will survive permanently, even in cases of failures,[1] including incidents and catastrophic events.

- Wikipedia

When creating Backups [...], we recommend that you power off your server to ensure data consistency on the disk. You can also create them from a running system. However, in this case, we cannot guarantee data consistency.

- a szóban forgó backup megoldás hivatalos doksija

Ha ennek a kettőnek az a szintézise, hogy tetszőleges ismeretlen futó alkalmazás alatt ha megcsinálom a snapshotot, az minden körülmények között konzisztens lesz, az nekem nem áll össze. Ettől még lehet ez egy valid backup stratégia, ha olyan az app, ha olyan a DB, ha olyan a HA setup, ha olyan a szervezet kockázattűrése, stb., de nem véletlenül léteznek app-aware backup megoldások.

Vagy hát máshogy fogalmazom: én ennyi információ alapján még nem merném satuba tenni a tudodmit, hogy ez biztosan jó megoldás lesz. :) Nem a VM snapshot létjogosultságát akartam vitatni, mert nyilván van neki.

OK, kozelitsuk meg a problemat mashogy.

 

Le tudnal irni egy egyszeru peldat, amikor nem fog mukodni ez a backup?

Legyen mondjuk MySQL 8 v. PSQL 16 (ezek a legutolso verziok)?

 

Az app meg legyen egy php webshop, egy keszletnyilvantarto v. vmi hasonlo cucc. Valassz kedvedre, ha cizallalni szeretned.

Az en allitasom az, h az esetek 95 (de lehet, h 99) %-aban a backup kielegito lesz. Ertsd, nem 100-bol 1 backup rossz, hanem 100-bol 1 olyan rendszert tudsz mutatni a gyakorltban, ahol nem ad kielegito backupot a snapshot es szukseg van egyebre.

 

ps.: Lehet mas strategia is, pl. replikat menteni.

( PunishR v | 2024. 12. 04., sze – 11:04 )

Szerintem a rackforest-nel talalsz erre megoldast.

Nemtom' kinek mi havi 6 ezer Ft, de manapság egy tank benzin közel 40 ezer Ft, egy ebéd két főre 20+ ezer Ft, egy fő havi bérköltsége pedig bőven 1 millió Ft fölötti költség.

Ahhoz képest, egy szerver adatainak biztonsága 6 ezer Ft-ért szerintem egy szabad szemmel alig látható költség, és ráadásul a Veeam még nem is egy nagyon olcsón licenszelt termék.

Ha sok a 6e/hó, akkor T-nél van pl. "adatparki mentés" (Comet) 2.120 Ft/hó áron+12,5 Ft/GB. De ha 2 évet aláírsz a VPS csomagra akkor a licensz+a bérelt VPS tárhelyének 1/4-ét megkapod grátisz.

Az általad is említett kisebb szolgáltatóknál nem tudom pontosan mit jelent a "napi mentés",mint a csomag része, de sokszor csak azt értik alatta, hogy a szolgáltató készít magának naponta egy mentést, hogy ha elköszön a host, akkor legyen miből visszaállni, de ezeket a mentéseket nem szokták kívülről ügyfél számára is elérhetővé tenni.

( dlaszlo | 2024. 12. 04., sze – 18:39 )

Szerkesztve: 2024. 12. 04., sze – 18:40

Őket kérdezd/nézd meg szerintem: SzerverPlex.

(Én több év alatt, meg vagyok elégedve a megbízhatóságukkal, rugalmasságukkal, szakértelmükkel, hozzáállásukkal.)

( Proci85 v | 2024. 12. 04., sze – 19:12 )

Mekkora méret kell? Mire megy el a havi 20TB?

( djsmiley v | 2024. 12. 06., p – 10:19 )

Tudom h. az volt a feltétel h. magyarországi legyen a szerver, de miért?

Nyakig benne vagyok mostanában mindenféle NIS2, GDPR történetben, de még az MNB auditon is lehet olyan cuccal menni, ami EGT-ben van. Így kapásból játszana az általad is írt Hetzner, de még az AWS megfelelő régiója is pl.

Ha meg ragaszkodsz az itthoni szolgáltatóhoz azzal kizárod az összes jobb/rosszabb EU-s szolgáltatót, így jelentősen kisebb a választék.

Itthon én a mögötte lévő céget nézném, árbevétel, létszám, eredmény stb., mert elég sok "kummantó" is van a piacon, aki vagy létezik még 2025-ben vagy nem.

Rackforest, rackhost vonalon nem lősz nagyon mellé, a backup meg hát olyan amilyen.

Úgy van. Mi lehet az oka annak, hogy Magyarroszágon kell legyen? Ezt én sem értem. Valszeg axiómáról van szó, de ez így meglehetősen kontraproduktív.

Ha szerverszobában akarsz fizikailag megjelenni, az inkább szerverhotel, de annak ma már szerintem semmi értelme nincsen.

Állami szerverknél van kikötés, hogy alap esetben csak magyarországi telephelyen tárolható az adat. De az NKI-tól lehet engedélyt kérni, hogy EGT-n belül lehessen az adat (pl. önkormányzat M365-ben levelezne), ha a szolgáltató tudja garantálni, hogy az EGT-n belül tárol. Viszont találkoztam már olyan adatvédelmi biztossal, aki erre azt mondta, hogy érti, olvasta, de nem, ő akkor nem írja alá a papírokat, ha nem magyarországi a tárhely... Ilyen oka lehet pl. a ragaszkodásnak. Vagy egyszerűen csak nem tudják még, hogy az NKI egy egyszerű eljárásban engedélyezheti az EGT-n belüli tárolást.

Ezt egyfajta helyes piaci magatartásként értem, de technikailag nem hiszem hogy az adatbiztonság szempontjából mérvadó lenne. Aki tudni akarja, hogy mi van az Asztalos utcai szerveren és tudnia is kell, az tudni fogja ugyanúgy, mintha az EU bármelyik országában lenne. (Rule of need to know)

( kruska v | 2024. 12. 06., p – 11:04 )

- Normális backup szolgáltatás ahol egy kattintással tudok backupolni, restorolni (pl. mint hetznernél)

Ez ephemeral snapshotként OK, még akkor is, ha backupnak hívják.

Ami backup, az minimum adatközpont- de inkább szolgáltatófüggetlen.