Capacity Tier (edo Vim barruan deitzen diogun bezala - captir) Veeam Backup and Replication 9.5 Update 4-ren garaian agertu zen Archive Tier izenarekin. Horren atzean dagoen ideia da leheneratzeko leiho operatiboa deritzonetik eroritako babeskopiak objektuen biltegira eramatea posible egitea. Honek diskoko lekua garbitzen lagundu zuen gutxi zuten erabiltzaileentzat. Eta aukera horri Mugitu modua deitzen zitzaion.

Ekintza sinple hau (dirudien bezala) burutzeko, nahikoa zen bi baldintza betetzea: mugitutako babeskopiaren puntu guztiak aipatutako leheneratze-leiho operatiboaren mugetatik kanpo egon behar dira, hau da, UI-n esplizituki ezarrita dagoena. Eta bigarrena: kateak "forma zigilatua" deritzonean egon behar du (bereziko kate itxia edo babeskopia inaktiboa). Hau da, kate honetan ez da aldaketarik gertatzen denboran zehar.

Baina VBR v10-n, kontzeptua funtzio berriekin osatu zen - Kopiatzeko modua, Sealed Mode eta ahoskatzeko zaila den Immutabilitatea izena duen gauza bat agertu zen.

Hauek dira gaur hitz egingo ditugun gauza liluragarriak. Lehenik eta behin, VBR9.5u4-n nola funtzionatu zuen, eta gero hamargarren bertsioan izandako aldaketei buruz.

Eta hizkuntza hutsaren txapeldunek barka diezadatela, baina hitz gehiegi daude itzuli ezin direnak.
Beraz, anglizismo mordoa egongo da hemen.
Eta gif asko.
Eta irudiak.

• Damu txikienik gabe. Artikuluaren egilea.

zen bezala

Tira, has gaitezen leheneratzeko leiho operatiboa eta babeskopia zigilatua (edo babeskopia inaktiboen katearen dokumentazioan deitzen den bezala) aztertzen. Haiek ulertu gabe, ezin izango da azalpen gehiago eman.

Irudian ikusten dugunez, datu-blokeekin babeskopia-kate moduko bat dugu, Kapazitate-maila konektatuta dagoen biltegiko Performance-tier SOBR-n kokatuta dagoena. Gure babeskopien leiho operatiboa hiru egunekoa da.

Horren arabera, astelehenean sortutako .vbk-ak aurreko katea zigilatzen du, zeinaren leihoa hiru egunetan ezarrita baitago. Eta horrek esan nahi du segurtasunez has zaitezkeela hiru egun hauek baino zaharragoak tiro eremura garraiatzen.

Baina zer esan nahi zuen zehatz-mehatz kate zigilatu batek eta zer bidali zitekeen 4. eguneratzean tiro-gaitasunera?

Forward Incremental-entzat, katea zigilatzeko seinalea babeskopia osoa sortzea da. Eta berdin du nola lortzen den babeskopia osoa: babeskopia osoa sintetikoak zein aktibo osoak kontuan hartzen dira.

Alderantzizko kasuan, leiho eragilean erortzen ez diren fitxategi guztiak dira.

Aurrera gehikuntzaren kasuan, atzerapenekin, hauek guztiak atzera bota eta .vbk dira, errendimenduaren hedapenean beste .vbk bat badago.

Orain kontuan hartu dezagun Backup Copy kateekin lan egiteko aukera. GFS atxikipenean dauden elementuak bakarrik garraiatu dira hona. Azken kopia-kopia kateetan gordetako guztia era batera edo bestera alda daitekeelako.

Orain begira dezagun kanpaiaren azpian. Bertan, deshidratazioa izeneko prozesu bat gertatzen da: babeskopia fitxategi hutsak hedaduran utziz eta fitxategi horietatik blokeak arrastatuz filmatzeko ahalmenera. Prozesu hori optimizatzeko, deshidratazio-indizea deritzona erabiltzen da, eta horri esker, dagoeneko kopiatuta dauden blokeak kopiatzea saihestu daiteke filmatzeko gaitasun-eremuan.

Ikus dezagun nolakoa den hau adibide batekin: Demagun transakzio-leihotik ateratako .vbk bat dugula eta kate zigilatu batekoa dela. Horrek esan nahi du eskubide osoa dugula tiro-ahalmeneko eremura eramateko. Mugitzeko unean, metadatu fitxategi bat sortzen da transferitutako fitxategiaren edukiera marra eta blokeetan. Esteka-mailako metadatuen fitxategiak gure fitxategia zer blokek osatzen duten deskribatzen du. Irudiko kasuan, gure lehen fitxategia a, b, c blokeek osatzen dute eta metadatuek bloke horietarako estekak dituzte. Bigarren .vbk fitxategi bat dugunean, mugitzeko prest eta a, b eta d blokeez osatua, guk, deshidratazio-indizea aztertuta, d blokea bakarrik transferitu behar dela ulertzen dugu. Eta bere metadatuen fitxategiak aurreko bi bloke eta berri bat estekak izango ditu.

Horren arabera, hutsune horiek datuekin betetzeko prozesuari birhidratazioa deritzo. Dagoeneko bere birhidratazio-indizea erabiltzen du, tokiko errendimenduaren hedapeneko .vbk fitxategi zaharrenean oinarrituta. Hau da, erabiltzaileak edukiera errodatzeko barrutitik fitxategi bat itzuli nahi badu, lehenik eta behin babeskopia osoa zaharrenaren blokeen indizea sortzen dugu eta falta diren blokeak soilik transferituko ditugu edukiera filmatzeko galeriatik. Irudian aurkezten den kasuan, FullBackup1.vbk rehidratazio-indizearen arabera birhidratatzeko, C blokea besterik ez dugu behar, tiro-ahalmenetik hartzen duguna. Biltegiratze hodei-objektu batek tiro-eremu gisa balio badu, horrek diru kopuru izugarria aurrezteko aukera ematen du.

Hemen badirudi teknologia hau WAN azeleragailuetan erabiltzen denaren berdina dela, baina hala dirudi. Azeleragailuetan, desduplicazioa globala da; hemen, tokiko deduplicazioa fitxategi bakoitzaren barruan erabiltzen da desplazamendu zehatz batean. Konpontzen ari diren zereginen desberdintasunagatik gertatzen da hori: hemen kopiatu behar ditugu segurtasun-kopia osoko fitxategi handiak, eta gure ikerketen arabera, haien artean denbora tarte luzea igaro arren, desduplicazio algoritmo honek ematen du emaitzarik onena.

Baina aurkibide gehiago indizeen jainkoarentzat! Datuak berreskuratzeko indize bat ere badago! Ahalmenaren marratxoan kokatutako makina bat leheneratzen hasten garenean, errendimenduko marratxoan ez dauden datu-bloke bakarrak irakurriko ditugu.

Nola gertatu zen?

Hori guztia sarrerarako. Nahiko zehatza da, baina goian esan bezala, xehetasun horiek gabe ezin izango da azaldu funtzio berriek nola funtzionatzen duten. Hori dela eta, gehiago luzatu gabe, goazen lehenengora.

Kopiatzeko modua

Dauden teknologietan oinarritzen da neurri handi batean, baina erabilera logika guztiz ezberdina du. 

Modu honen helburua tokiko hedaduran kokatutako datu guztiek edukieraren martxoan kopia bat dutela ziurtatzea da.

Mugitu eta Kopiatu moduak aurrez aurre alderatzen badituzu, itxura hau izango du:

• Zigilatutako katea bakarrik mugitu daiteke. Kopiatzeko moduaren kasuan, dena transferitzen da, babeskopia-lanean gertatzen dena kontuan hartu gabe.
• Mugimendua abiarazten da fitxategiak babeskopia operatiboaren leihoaren mugetatik haratago doazenean, eta kopiatzea abiarazten da babeskopia fitxategia agertu bezain laster.
• Kopiatzeko datu berrien jarraipena etengabe gertatzen da, eta mugitzeko 4 orduz behin abiarazten zen.

Modu berria kontuan hartuta, adibide sinpleetatik konplexuetara pasatzea proposatzen dut.

Kasurik ohikoenean, gehikuntzak dituzten fitxategi berriak besterik ez ditugu eta, besterik gabe, kopiatuko ditugu filmatzeko gaitasunaren eremura. Backup-lanean zer modu erabiltzen den kontuan hartu gabe, katearen zati zigilatuari dagokion ala ez, gure leiho operatiboa iraungi den kontuan hartu gabe. Hartu eta kopiatu besterik ez zuten egin.

Honen atzean dagoen prozesua oraindik deshidratazioa da goian azaldu bezala. Kopiatu moduan, dagoeneko gure biltegian dauden blokeak ez ditugula kopiatzen ziurtatzen du. Ezberdintasun bakarra da film moduan fitxategi errealekin ordezkatzen baditugu, hemen ez ditugula inola ere ukitzen eta dena dagoen bezala uzten dugu. Bestela, deshidratazio-indize bera da, kontu handiz zure dirua eta denbora aurrezten saiatzen dena.

Galdera sortzen da: UI-ra begiratzen baduzu, aukera dago bi aukerak aldi berean hautatzeko. Nola funtzionatuko du halako modu konbinatu batek?

Irudikatu.

Hasiera estandarra da: babeskopia fitxategi bat sortu eta berehala kopiatzen da. Gehikuntza bat sortzen da eta kopiatzen da. Hau gertatzen da fitxategiak gure leiho operatiboa utzi eta kate itxi bat agertu dela konturatzen garen unera arte. Une honetan deshidratazio-eragiketa bat egiten dugu eta fitxategi horiek fitxategi finkoekin ordezkatzen ditugu. Noski, ez dugu ezer kopiatzen berriro edukiera tiro eremura.

Logika liluragarri hori guztia interfazearen kontrol-lauki bakarraren erantzule da: kopiatu babeskopiak objektuen biltegian sortu bezain pronto.

Zergatik behar dugu Kopiatu modu hau?

Are hobea da galdera honela birformulatzea: zein arriskutatik babesten gaitu haren laguntzarekin? Zein arazo konpontzen laguntzen digu?

Erantzuna begi-bistakoa da: noski, hau datuak berreskuratzea da. Objektuen biltegian tokiko datuen kopia osoa badugu, gure produktuarekin zer gertatzen den, beti berreskura ditzakegu Amazon baldintzapean dauden fitxategietatik datuak.

Goazen, beraz, eszenatoki posibleak, sinpleenetik konplexuagoetara.

Gure buruetara eror daitekeen zorigaitz sinpleena segurtasun-kopia kateko fitxategietako baten eskuraezintasuna da.

Istorio tristeagoa da gure SOBR biltegiaren hedaduraren bat hautsi zela.

Are okerragoa da SOBR biltegi osoa eskuraezin bihurtu denean, baina tiro-eremua funtzionatzen ari da.
Eta dena oso txarra da - hau da, babeskopia zerbitzaria hiltzen denean eta zure lehen nahia hamar minututan Kanadako mugara korrika egiten saiatzea da.

Orain ikus ditzagun egoera bakoitza bereizita.

Babeskopia-fitxategi bat (eta are gehiago) galdu dugunean, egin behar dugun guztia biltegiaren berrikusketa-prozesua abiaraztea da, eta galdutako fitxategia fitxategi finko batekin ordezkatuko da. Eta birhidratazio-prozesua erabiliz (artikuluaren hasieran eztabaidatu zena), erabiltzaileak datuak deskargatu ahal izango ditu tiro-eremutik tokiko biltegira.

Orain egoera konplikatuagoa da. Demagun gure SOBR Errendimendu moduan exekutatzen diren bi neurriz osatuta dagoela, hau da, gure .vbk eta .vib haien gainean geruza irregular samarrean banatuta daudela. Eta uneren batean, hedapenetako bat erabilgarri geratzen da, eta erabiltzaileak premiazkoa du makina leheneratu, datuen zati bat neurri horretan baitago hain zuzen.

Erabiltzaileak berreskuratzeko morroia abiarazten du, leheneratu nahi duen puntua hautatzen du eta morroiak, lanean ari den bitartean, konturatzen da ez dituela lokalean berreskuratzeko beharrezkoak diren datu guztiak eta, beraz, filmatzeko gaitasunetik deskargatu behar dela. galeria. Aldi berean, biltegiratze lokalean geratzen diren blokeak ez dira hodeitik deskargatuko. Aintza berreskuratu indizeari (bai, artikuluaren hasieran ere aipatu zen).

Kasu honen azpimota bat da SOBR biltegi osoa eskuraezin bihurtu zela. Kasu honetan, ez dugu tokiko biltegiratzetik kopiatzeko ezer, eta bloke guztiak hodeitik deskargatzen dira.

Eta egoera interesgarriena babeskopia zerbitzaria hil dela da. Hemen bi aukera daude: administratzailea bikaina da eta konfigurazioen babeskopiak egin zituen, eta administratzailea Pinotxo gaiztoa bera da eta ez zuen konfigurazioen babeskopiak egin.

Lehenengo kasuan, nahikoa izango da VBR-ren instalazio garbia nonbait ezartzea eta bere datu-basea babeskopia batetik berreskuratzea bitarteko estandarrak erabiliz. Prozesu honen amaieran, dena normaltasunera itzuliko da. Edo leheneratu egingo da goiko eszenatokietako baten arabera.

Baina administratzaileak bere etsaia bada, edo konfigurazioaren babeskopiak ere porrot epiko bat jasan badu, hemen ere ez dugu patuaren menpe utziko. Kasu honetarako, Inportatu Objektuen Biltegiratzea izeneko prozedura berri bat sartu dugu. SOBR biltegi bat eskuz birsortzeko prozesua saltatzeko eta hari errodatze-eremu bat eransteko aukera ematen du, ondoren berriro eskaneatuz, eta, besterik gabe, biltegiratze-objektu bat gehitu Vim interfazean eta inportatu biltegiratze-biltegia prozedura exekutatu. Zure eta zure babeskopien artean oztopa daitekeen gauza bakarra zure babeskopiak enkriptatuta egonez gero pasahitz bat sartzeko eskaera da.

Hau seguruenik Kopiatu moduari buruzkoa da eta aurrerago joango gara

Zigilatu modua

Ideia nagusia da babeskopia berriak ezin direla agertu biltegiaren SOBR hedaduran. v10 baino lehen, Mantentze modua bakarrik genuen, biltegiarekin edozein lan guztiz debekatuta zegoenean. Biltegiratzea ixteko gogor modu moduko bat, non Ebakuatu botoia bakarrik dagoen eskuragarri, babeskopiak beste neurri batera garraiatzen dituena.

Eta Sealed modua aukera "bigun" moduko bat da: babeskopia berriak sortzea debekatzen dugu eta zaharrak pixkanaka ezabatzen ditugu hautatutako atxikipenaren arabera, baina prozesuan ez dugu biltegiratutako puntuetatik leheneratzeko gaitasuna galtzen. Gauza oso erabilgarria da hardware pieza bat bere bizitzaren amaierara hurbiltzen denean eta ordezkatu behar dugunean, edo zerbait garrantzitsuagorako askatu behar dugunean, baina ez dago inon hartu eta dena aldi berean mugitzeko. Edo ezin da ezabatu.

Horren arabera, funtzionamendu-printzipioa nahiko sinplea da: beharrezkoa da idazketa eragiketa guztiak (datu berrien agerpena) debekatu behar dira, irakurtzen utzi (berreskuratu) eta ezabatu (erretentzioa).

Bi moduak aldi berean erabil daitezke, baina kontuan izan Mantentze-lanak lehentasun handiagoa duela.

Adibide gisa, kontuan hartu bi hedaduraz osatutako SOBR bat. Demagun lehen lau egunetan babeskopiak sortu ditugula Aurrera Betiko Inkrementale moduan, eta gero neurria zigilatzen dugula. Honek bigarren hedadura erabilgarrietan aktibo berri bat sortzeari ekiten diola dakar. Gure atxikipena laukoa bada, zigilatutako hedaduran kokatutako kate osoa bere mugak gainditzen dituenean, kontzientzia garbiarekin ezabatzen da.

Ezabatzea lehenago gertatzen den egoerak daude. Adibidez, hau Aurrera inkrementala da aldizkako betetzeekin. Lehen bi egunetan babeskopia osoak sortu baditugu, eta ostegunean biltegia zigilatzea erabakitzen badugu, ostiralean, segurtasun kopia berri bat sortzen denean, asteleheneko fitxategia ezabatu egingo da. ez dago menpekotasunik puntu honetaraino. Eta puntua bera ez dago inoren menpe. Ondoren, erabilgarri dagoen hedaduran lau puntu sortu arte itxarongo dugu eta gainerako hirurak ezabatzen ditugu, ezin baitira bata bestearengandik independentean ezabatu.

Gauzak errazagoak dira Reverse Incremental-ekin. Bertan, puntu zaharrenak ez dira ezerren menpekoak eta segurtasunez ezaba daitezke. Beraz, .vbk berri bat neurri berri batean sortu bezain laster, .vrbs zaharrak banan-banan ezabatuko dira.

Bide batez, zergatik sortzen dugu .vbk berri bat aldi bakoitzean: sortu ez bagenu, baina gehikuntza-kate zaharrarekin jarraituz gero, .vbk zaharra denbora infinitu batean izoztuko litzateke edozein modutan, ezabatzea eragotziz. Hori dela eta, neurria zigilatu bezain laster, neurri librean babeskopia osoa sortzea erabaki zen.

Gauzak konplikatuagoak dira tiro-eremuarekin.

Lehenik eta behin, ikus dezagun kopiatzeko modua. Demagun lau egunez aktiboki babeskopiak sortzen ari ginela eta, ondoren, tiro-eremua zigilatu zela. Ez dugu ezer ezabatzen, baina apaltasunez jasaten dugu atxikipena, eta ondoren datuak ezabatzen ditugu tiro-eremuko edukiera.

Gutxi gorabehera, gauza bera gertatzen da mugitzeko moduan: ukipenaren zain gaude, zaharra ezabatzen dugu tokiko biltegian eta ezabatu objektuen biltegian gordeta dagoena.

Adibide interesgarri bat Forever forward incremental-ekin. Erretenzioa hiru puntutan instalatzen dugu eta astelehenean hasten gara babeskopiak egiten, aldizka hodeian kopiatzen direnak. Biltegiratzea zigilatu ondoren, babeskopiak sortzen jarraitzen dute, hiru puntu mantenduz, baina edukieraren marratxoan gordetako datuak menpe geratzen dira eta ezin dira ezabatu. Hori dela eta, ostegunera arte itxarongo dugu, gure .vbk atxikipenetik haratago doanean, eta orduan bakarrik ezabatzen dugu gordetako kate osoa lasaitasunez.

Eta oharra txiki bat: hemen adibide guztiak makina batekin erakusten dira. Horietako hainbat babeskopian badituzu, haien ukipena desberdina izango da Active Full egin den ala ez.

Hori da funtsean dagoen guztia. Beraz, goazen funtziorik gogorrenera -

Aldaezintasuna

Aurreko puntuetan bezala, lehenengo gauza da funtzio honek zein arazo ebazten duen. Gure babeskopiak nonbait gordetzeko kargatu bezain laster, haien segurtasuna bermatzeko gogo handia dago, hau da, gordetze batean ezabatzea eta edozein aldaketa fisikoki debekatzea. Administratzaileak barne, beren root kontuetan barne. Horrek ustekabeko edo nahitako kalteetatik babesteko aukera ematen du. AWS-rekin lan egiten duen edonork Object Lock izeneko antzeko eginbide batekin topo izan dezake.

Orain ikus ditzagun modua termino orokorrean, eta gero xehetasunetan sakondu. Gure adibidean, aldaezintasuna gaituko da gure gaitasuneko tiro eremuan lau eguneko atxikipenarekin. Eta kopia modua gaituta dago babeskopian.

Aldaezintasunak ez du inolaz ere elkarreragina atxikipen orokorrarekin. Adibidez, ez du puntu gehigarririk edo horrelakorik gehitzen. Pertsona batek ezin dituela babeskopia fitxategiak ezabatu lau eguneko epean. Astelehenean babeskopia egiten baduzu, ostiralean soilik ezabatu ahal izango duzu bere fitxategia.

Aurretik azaldutako deshidratazioari, indizeei eta metadatuei buruzko kontzeptu guztiek berdin jarraitzen dute funtzionatzen. Baina baldintza batekin: blokea datuetarako ez ezik, metadatuetarako ere ezartzen da. Hori egiten da erasotzaile maltzur batek gure metadatuen datu-basea ezabatzea erabakitzen badu eta datu-blokeak alferrikako birrindu bitar bihurtzea saihesteko.

Orain momentu bikaina da gure blokeak sortzeko teknologia azaltzeko. Edo blokeen sorrera. Horretarako, kontuan hartu bere agerpena ekarri duen egoera.

Har dezagun sei eguneko denbora-eskala eta beherago aldaezintasunaren espero den iraungipenaren denbora markatuko dugu. Lehenengo egunean a datu-blokeaz eta bere metadatuz osatutako fitxategi bat hartu eta sortzen dugu. Aldaezina hiru egunetan ezartzen bada, logikoa da laugarren egunean datuak desblokeatu eta ezabatuko direla pentsatzea. Bigarren egunean fitxategi berri bat gehituko dugu2, ezarpen berdinekin b blokez osatua. Blokea oraindik kendu behar da laugarren egunean. Baina hirugarren egunean zerbait izugarria gertatzen da - File3 fitxategi bat sortzen da, d bloke berri batek eta a bloke zaharrerako estekak osatua. Horrek esan nahi du bloke baterako eta aldaezina den bandera data berri batera berrezarri behar dela, hau da, seigarren egunera igarotzen dena. Eta hemen arazo bat sortzen da - benetako babeskopietan horrelako bloke ugari daude. Eta haien aldaezintasun epea luzatzeko, eskaera ugari egin behar dituzu aldi bakoitzean. Eta, hain zuzen ere, eguneroko prozesu ia amaigabea izango da, izan ere, probabilitate handiarekin kopia bakoitzean deduplicatutako bloke pila handiak aurkituko baititugu. Zer esan nahi du objektuak biltegiratzeko hornitzaileen eskaera kopuru handi batek? Ondo! Hilaren amaieran faktura handia.

Eta zure bezero gogokoenak diru askoren truke modu hutsean ez erakusteko, blokeak sortzeko mekanismoa asmatu zen. Ezarritako aldaezintasun-aldiari gehitzen diogun aldi gehigarria da. Beheko adibidean, epe hori bi egunekoa da. Baina hau adibide bat besterik ez da. Egia esan, euren formula propioa erabiltzen dute, gutxi gorabehera hamar egun gehiago ematen baitituzte hileroko blokeo batean.

Jarrai dezagun egoera bera kontuan hartzen, baina blokeen sorrerarekin. Lehenengo egunean fitxategia1 sortzen dugu bloketik a eta metadatuak. Sorkuntza-aldia eta aldaezintasuna batzen ditugu; horrek esan nahi du fitxategia ezabatzeko aukera seigarren egunean izango dela. Bigarren egunean File2 sortzen badugu, b blokez eta a blokeatzeko estekaz osatua, ez da ezer gertatzen espero den ezabatze-datarekin. Seigarren egunean bezala gelditu zen. Eta horrela, eskaera kopuruan dirua aurrezten saiatzen ari gara. Epea alda daitekeen egoera bakarra belaunaldi-aldia amaitu bada. Hau da, hirugarren egunean File3 berriak a blokeatzeko esteka badu, 2. belaunaldia gehituko da Gen1 dagoeneko iraungi baita. Eta blokea a ezabatzeko aurreikusitako data zortzigarren egunera aldatuko da. Horri esker, deduplicatutako blokeen bizitza luzatzeko eskaera kopurua nabarmen murrizten dugu, eta horrek bezeroei diru asko aurrezten du.

Teknologia bera eskuragarri dago S3 eta S3-rekin bateragarria den hardwarearen erabiltzaileentzat, eta haien fabrikatzaileek bermatzen dute haien ezarpena ez dela Amazonenarekin desberdina. Beraz, Azure zergatik ez den onartzen duen galderari erantzuna - antzeko ezaugarria dute, baina edukiontzien mailan funtzionatzen du, ez objektu indibidualetan. Bide batez, Amazonek berak objektuen blokeoa du bi modutan: betetzea eta gobernantza. Bigarren kasuan, aukera dago administratzaileen gainetik administratzaile handienak eta erroen gainetik erroak, objektuen blokeoa izan arren, datuak oraindik ezabatzeko. Betearen kasuan, dena ondo iltzatuta dago eta inork ezin ditu babeskopiak ezabatu. Baita Amazoneko administratzaileak ere (beren adierazpen ofizialen arabera). Hau da onartzen dugun modua.

Eta, ohi bezala, esteka erabilgarri batzuk:

• Про Blokeen Sorkuntza xehetasun guztietan.
• buruzko informazio guztia Veeam Backup & Replication 10 bere onenean
• О Edukiera Maila xehetasunez

Iturria: www.habr.com