ProHoster > Blog > Administrim > Telepoint Data Mərkəzi

Telepoint Data Mərkəzi

Pritni! Pritni! Vërtet, kjo nuk është një tjetër artikull mbi llojet e kopjeve rezervë të SQL Server. Nuk do t'i flas asnjëherë ndarjeve të modeleve të rikuperimit dhe si të luftojmë me "log-un" që është zgjeruar.

Ndoshta (vetëm ndoshta), pas leximit të këtij postimi, do të jeni në gjendje të bëni që kopja rezervë, e cila merrni me mjetet standarde, nesër në mbrëmje të realizohet, mirë, 1.5 herë më shpejt. Dhe vetëm për faktin se po përdorni pak më shumë parametra të BACKUP DATABASE.

NĂ«se pĂ«r ju pĂ«rmbajtja e postimit ishte e qartĂ« — mĂ« vjen keq. Kam lexuar gjithçka qĂ« arrita tĂ« gjej nĂ« google mbi frazĂ«n "habr sql server backup", dhe nĂ« asnjĂ« artikull nuk e gjeta pĂ«rmendjen se nĂ« kohĂ«n e kopjimit rezervĂ« mund tĂ« ndikoni ndonjĂ«herĂ« me anĂ« tĂ« parametrave.

Menjëherë do të tërheq vëmendjen tuaj në komentarin e Aleksandër Gladchenko (@mssqlhelp):

Kurrë mos e ndryshoni parametrat BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE në prodhim. Ata janë bërë vetëm për të shkruar artikuj të tillë. Në praktikë do të hasni probleme me memorien plotësisht.

Do tĂ« ishte, sigurisht, shumĂ« mirĂ«, tĂ« isha mĂ« i mençur dhe tĂ« postoja pĂ«rmbajtje ekskluzive, por kjo, fatkeqĂ«sisht, nuk Ă«shtĂ« e vĂ«rtetĂ«. Ka artikuj dhe postime nĂ« anglisht dhe nĂ« rusisht (pĂ«rherĂ« konfuziohem si t’i quaj saktĂ«sisht), tĂ« dedikuara kĂ«saj teme. KĂ«tu Ă«shtĂ« njĂ« pjesĂ« e atyre qĂ« mĂ« ra nĂ« sy: njĂ«, dy, tre (nĂ« sql.ru).

Pra, për fillim do të përcjell disa sintaksë të shkurtuar të BACKUP nga MSDN (përfaqësisht, atje lart kam shkruar për BACKUP DATABASE, por gjithë kjo është e aplikueshme edhe për kopjen e regjistrit të transaksioneve, dhe për kopjen diferenciale, ndoshta me një efekt më pak të qartë):

BACKUP DATABASE { database_name | @database_name_var }
  TO  [ ,...n ]
  
  [ WITH { 
           |  [ ,...n ] } ]
[;]

 [ ,...n ]::=

--Media Set Options
 
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
   BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

— do tĂ« thotĂ«, se aty kishte diçka, por e kam hequr sepse tani kjo nuk ka lidhje me temĂ«n.

Si zakonisht bëni kopjen rezervë? Si "mësojnë" të bëjnë kopje rezervë në miliarda artikuj? Në përgjithësi, nëse duhet të bëj një kopje rezervë një herë për ndonjë bazë të vogël, do të shkruaja automatikisht diçka si kjo:

BACKUP DATABASE smth
TO DISK = 'D:Backupsmth.bak'
WITH STATS = 10, CHECKSUM, COMPRESSION, COPY_ONLY;
-- mirë, CHECKSUM e kam shkruar vetëm për t'u dukur më i mençur

Dhe, në përgjithësi, këtu janë përmendur, ndoshta 75-90% e të gjithë parametrave që zakonisht përmenden në artikujt rreth backup-eve. Ka INIT, SKIP e kështu me radhë. A keni shkuar në MSDN? A e keni parë se atje ka opsione që mbushin një ekran të gjysmë? Edhe unë e kam parë...

Ndoshta e keni kuptuar se tani do tĂ« flasim pĂ«r tre parametrat qĂ« mbetĂ«n nĂ« bllokun e parĂ« tĂ« kodit — BLOCKSIZE, BUFFERCOUNT dhe MAXTRANSFERSIZE. Ja pĂ«rshkrimet e tyre nga MSDN:

BLOCKSIZE = { blocksize | @ blocksize_variable } tregon madhësinë fizike të bllokut në byte. Mbështeten madhësi 512, 1024, 2048, 4096, 8192, 16 384, 32 768 dhe 65 536 byte (64 KB). Vlera e paracaktuar është 65 536 për pajisjet me kaseta dhe 512 për pajisjet e tjera. Zakonisht, nuk ka nevojë për këtë parametër, pasi komandat BACKUP zgjedhin automatikisht madhësinë e bllokut që i përshtatet pajisjes. Caktimi i shprehur i madhësisë së bllokut anashkalon zgjedhjen automatike.

BUFFERCOUNT = { buffercount | @ buffercount_variable } përcakton numrin e përgjithshëm të buferëve të hyrjes-daljes që do të përdoren për operacionin e rezervimit. Mund të caktoni çdo vlerë pozitive të plotë, megjithatë një numër i madh buferësh mund të shkaktojë një gabim për mungesë të memories për shkak të hapësirës së madhe virtuale të adresimit në procesin Sqlservr.exe.

Vëllimi i përgjithshëm i hapësirës së përdorur nga buferët përcaktohet nga formula e mëposhtme: BUFFERCOUNT * MAXTRANSFERSIZE.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable } tregon madhësinë maksimale të paketave të të dhënave në byte për shkëmbimin e të dhënave midis SQL Server dhe mediave të rezervave. Mbështeten vlera të shumfishit të 65 536 byte (64 KB), deri në 4 194 304 byte (4 MB).

Betohem — e kam lexuar kĂ«tĂ« mĂ« herĂ«t, por as nuk mĂ« ka shkuar nĂ« mendje se çfarĂ« ndikuan nĂ« performancĂ«. MĂ« shumĂ« se kaq, duket se duhet tĂ« bĂ«j njĂ« lloj "dalje" dhe tĂ« pranoj se edhe tani nuk e kuptoj plotĂ«sisht se çfarĂ« bĂ«jnĂ« ata. Ndoshta duhet tĂ« lexoj mĂ« shumĂ« rreth hyrjes-daljes tĂ« buferuar dhe punĂ«s me diskun e ngurtĂ«. NjĂ« ditĂ« do ta bĂ«j kĂ«tĂ«, por pĂ«r momentin mund tĂ« shkruaj thjesht njĂ« skenar qĂ« do tĂ« kontrollojĂ« se si kĂ«to vlera ndikojnĂ« nĂ« shpejtĂ«sinĂ« me tĂ« cilĂ«n bĂ«het backup-i.

Kam bërë një bazë të vogël, me një madhësi prej rreth 10 GB, e kam vendosur në SSD, ndërsa katalogu për backup-et e kam vendosur në HDD.

Po krijoj një tabelë të përkohshme për të ruajtur rezultatet (në të vërtetë nuk është e përkohshme, që të mund të shqyrtoj rezultatet më në detaje, por vendosni vetë):

DROP TABLE IF EXISTS ##bt_results; 

CREATE TABLE ##bt_results (
    id              int IDENTITY (1, 1) PRIMARY KEY,
    start_date      datetime NOT NULL,
    finish_date     datetime NOT NULL,
    backup_size     bigint NOT NULL,
    compressed_size bigint,
    block_size      int,
    buffer_count    int,
    transfer_size   int
);

Principi i funksionimit tĂ« skriptit Ă«shtĂ« i thjeshtĂ« — cikle tĂ« ndĂ«rlidhura, secili prej tĂ« cilave ndryshon vlerĂ«n e njĂ« parametri, kĂ«ta parametra i dĂ«rgoj nĂ« komandĂ«n BACKUP, ruaj regjistrimin e fundit me historinĂ« nga msdb.dbo.backupset, fshij skedarin e kopjes sĂ« sigurisĂ« dhe iteracioni i ardhshĂ«m. Duke qenĂ« se tĂ« dhĂ«nat mbi ekzekutimin e kopjes sĂ« sigurisĂ« merren nga backupset, saktĂ«sia paksa humbet (atje nuk ka pjesĂ« tĂ« sekondave), por do ta kalojmĂ« kĂ«tĂ«.

Së pari, duhet lejuar përdorimin e xp_cmdshell për të fshirë kopjet e sigurisë (më pas mos harroni ta çaktivizoni nëse nuk ju nevojitet):

EXEC sp_configure 'show advanced options', 1;  
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0;  
GO

Dhe tani, konkretisht:

DECLARE @tmplt AS nvarchar(max) = N'
BACKUP DATABASE [bt]
TO DISK = ''D:SQLServerbackupbt.bak''
WITH 
    COMPRESSION,
    BLOCKSIZE = {bs},
    BUFFERCOUNT = {bc},
    MAXTRANSFERSIZE = {ts}';

DECLARE @sql AS nvarchar(max);

/* Vlerat e BLOCKSIZE */
DECLARE @bs     int = 4096, 
        @max_bs int = 65536;

/* Vlerat e BUFFERCOUNT */
DECLARE @bc     int = 7,
        @min_bc int = 7,
        @max_bc int = 800;

/* Vlerat e MAXTRANSFERSIZE */
DECLARE @ts     int = 524288,   --512KB, default = 1024KB
        @min_ts int = 524288,
        @max_ts int = 4194304;  --4MB

SELECT TOP 1 
    @bs = COALESCE (block_size, 4096), 
    @bc = COALESCE (buffer_count, 7), 
    @ts = COALESCE (transfer_size, 524288)
FROM ##bt_results
ORDER BY id DESC;

WHILE (@bs <= @max_bs)
BEGIN
    WHILE (@bc <= @max_bc)
    BEGIN       
        WHILE (@ts <= @max_ts)
        BEGIN
            SET @sql = REPLACE (REPLACE (REPLACE(@tmplt, N'{bs}', CAST(@bs AS nvarchar(50))), N'{bc}', CAST (@bc AS nvarchar(50))), N'{ts}', CAST (@ts AS nvarchar(50)));

            EXEC (@sql);

            INSERT INTO ##bt_results (start_date, finish_date, backup_size, compressed_size, block_size, buffer_count, transfer_size)
            SELECT TOP 1 backup_start_date, backup_finish_date, backup_size, compressed_backup_size,  @bs, @bc, @ts 
            FROM msdb.dbo.backupset
            ORDER BY backup_set_id DESC;

            EXEC xp_cmdshell 'del "D:SQLServerbackupbt.bak"', no_output;

            SET @ts += @ts;
        END
        
        SET @bc += @bc;
        SET @ts = @min_ts;

        WAITFOR DELAY '00:00:05';
    END

    SET @bs += @bs;
    SET @bc = @min_bc;
    SET @ts = @min_ts;
END

NĂ«se ndonjĂ«herĂ« keni nevojĂ« pĂ«r shpjegime mbi atĂ« qĂ« po ndodh kĂ«tu — shkruani nĂ« komentet, ose nĂ« mesazhe private. Deri tani do tĂ« flas vetĂ«m pĂ«r parametrat qĂ« i dĂ«rgoj nĂ« BACKUP DATABASE.

Për BLOCKSIZE ne kemi një listë "të mbyllur" të vlerave, dhe s'kam qenë në gjendje të bëj backup me BLOCKSIZE < 4KB. MAXTRANSFERSIZE një numër i çdo shume prej 64KB - nga 64KB deri në 4MB. Në të kaluarën, sistemi im kishte 1024KB, und zgjodha 512 - 1024 - 2048 - 4096.

I vështirë ishte BUFFERCOUNT - ai mund të jetë çdo numër pozitiv, por kjo është shkruar në lidhje me si llogaritet në BACKUP DATABASE dhe sa rrezikojnë vlerat e mëdha. Aty është shkruar gjithashtu se si të merrni informacion mbi BUFFERCOUNT që përdoret për backup - në rastin tim është 7. Nuk kishte kuptim ta ulja atë, ndërsa kufiri i sipërm u zbulua përmes provave - me BUFFERCOUNT = 896 dhe MAXTRANSFERSIZE = 4194304, backup ra me një gabim (i cili është përshkruar në lidhjen e mësipërme):

Msg 3013, Level 16, State 1, Line 7 BACKUP DATABASE është duke përfunduar në mënyrë anormale.

Msg 701, Level 17, State 123, Line 7 Nuk ka mjaftueshmëri memorie sistemike në grupin e burimeve 'default' për të ekzekutuar këtë pyetje.

Për krahasim, fillimisht do të tregoj rezultatet e ekzekutimit të backup-it pa treguar asnjë parametër:

BACKUP DATABASE [bt]
TO DISK = 'D:SQLServerbackupbt.bak'
WITH COMPRESSION;

Pra, backup dhe backup:

Përpunuar 1070072 faqe për databazën 'bt', skedhë 'bt' në skedhën 1.

Përpunuar 2 faqe për databazën 'bt', skedhë 'bt_log' në skedhën 1.

BACKUP DATABASE përfundimisht përpunoi 1070074 faqe për 53.171 sekonda (157.227 MB/sec).

Vetë skripti që teston parametrat funksionoi për disa orë, të gjitha matjet janë në tabelën Google. Ja një përzgjedhje e rezultateve, duke pasur tri kohë më të mira të ekzekutimit (po përpiqesha të bëja një grafik të bukur, por, në postim, do të duhet të kaloj me një tabelë, dhe në komente @mixsture shtoi grafikët janë super të bukur).

SELECT TOP 7 WITH TIES 
    compressed_size, 
    block_size, 
    buffer_count, 
    transfer_size,
    DATEDIFF(SECOND, start_date, finish_date) AS backup_time_sec
FROM ##bt_results
ORDER BY backup_time_sec ASC;

Telepoint Data Mərkəzi

Kujdes, menjëherë një vërejtje shumë e rëndësishme nga @mixsture nga komenti:

mund të themi me siguri se lidhja midis parametrave dhe shpejtësisë së backup-it brenda këtyre kufijve është rastësore, nuk ka ndonjë zakon. Por devijimi nga parametrat e integruar, është e qartë, kishte një efekt të mirë në rezultatin

Kështu, vetëm duke menaxhuar parametrat standard të BACKUP arritëm një përfitim në kohën e marrjes së backup-it nga 2 herë: 26 sekonda, përballë 53 në fillim. E mirë, apo jo? Por duhet të shohim se çfarë ndodh me rikthimin. Mos ndoshta tani do të rikthehet 4 herë më gjatë?

Për të filluar, do të matim sa zgjasin rikthimet e backup-it me parametrat e parazgjedhur:

RESTORE DATABASE [bt]
FROM DISK = 'D:SQLServerbackupbt.bak'
WITH REPLACE, RECOVERY;

Këtë e dini edhe vetë, rrugët atje, replace-jo replace, recovery-jo recovery. Dhe unë e ekzekutoj kështu:

Përpunuar 1070072 faqe për databazën 'bt', skedhë 'bt' në skedhën 1.

Përpunuar 2 faqe për databazën 'bt', skedhë 'bt_log' në skedhën 1.

RESTORE DATABASE u përpunua me sukses 1070074 faqe në 40.752 sekonda (205.141 MB/sec).

Tani do të provoj të rikuperoj backup-et e bëra me BLOCKSIZE, BUFFERCOUNT dhe MAXTRANSFERSIZE të ndryshuara.

BLOCKSIZE = 16384, BUFFERCOUNT = 224, MAXTRANSFERSIZE = 4194304

RESTORE DATABASE u përpunua me sukses 1070074 faqe në 32.283 sekonda (258.958 MB/sec).

BLOCKSIZE = 4096, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 4194304

RESTORE DATABASE u përpunua me sukses 1070074 faqe në 32.682 sekonda (255.796 MB/sec).

BLOCKSIZE = 16384, BUFFERCOUNT = 448, MAXTRANSFERSIZE = 2097152

RESTORE DATABASE u përpunua me sukses 1070074 faqe në 32.091 sekonda (260.507 MB/sec).

BLOCKSIZE = 4096, BUFFERCOUNT = 56, MAXTRANSFERSIZE = 4194304

RESTORE DATABASE u përpunua me sukses 1070074 faqe në 32.401 sekonda (258.015 MB/sec).

Instruksioni RESTORE DATABASE gjatĂ« rikuperimit nuk ndryshon, kĂ«tu nuk specifikohen kĂ«to parametra, SQL Server i pĂ«rcakton vetĂ« nga backup-i. Dhe Ă«shtĂ« e qartĂ« se edhe gjatĂ« rikuperimit mund tĂ« ketĂ« njĂ« pĂ«rfitim — pothuajse 20% mĂ« i shpejtĂ« (nĂ« tĂ« vĂ«rtetĂ«, nuk kam kaluar shumĂ« kohĂ« nĂ« rikuperim, provova disa nga backup-et mĂ« "tĂ« shpejtĂ«" dhe u sigurua se nuk kishte pĂ«rkeqĂ«sim).

PĂ«r çdo rast, dua tĂ« sqaroj — kĂ«tu nuk janĂ« pĂ«rshkruar ndonjĂ« parametra optimal pĂ«r tĂ« gjithĂ«. Parametrat optimalĂ« pĂ«r veten tuaj mund t'i merrni vetĂ«m pĂ«rmes testimit. UnĂ« arrita kĂ«to rezultate, ju do tĂ« merrni tĂ« tjera. Por e shihni se backup-et tuaja mund tĂ« "optimizohen" dhe ato vĂ«rtet mund tĂ« krijohen dhe restorerohen mĂ« shpejt.

Gjithashtu, e rekomandoj ngulmë që të lexoni dokumentacionin e plotë, sepse për sistemin tuaj mund të ketë nuanca.

Pasi fillova të shkruaj për backup-et, dua menjëherë të shkruaj edhe për një "optimizim" tjetër, i cili ndodh më shpesh se "tuning" i parametrave (sa kuptoj, kështu e përdorin të paktën disa utilitarë për rezervë, ndoshta së bashku me parametrat e përshkruar më parë), por në Habrë nuk është përshkruar deri tani.

Nëse shikoni në rreshtin e dytë në dokumentacion, menjëherë poshtë BACKUP DATABASE, aty shohim:

TO  [, ...n]

ÇfarĂ« mendoni se do tĂ« ndodhĂ« nĂ«se specifikoni disa backup_device? Sintaksa lejon. Dhe do tĂ« jetĂ« njĂ« gjĂ« shumĂ« interesante — backup-i thjesht do tĂ« "shpĂ«rndahet" nĂ« disa pajisje. Pra, çdo "pajisje" e veçantĂ« do tĂ« jetĂ« e padobishme, humbĂ«t njĂ«, humbĂ«t tĂ« gjithĂ« backup-in. Por si do tĂ« ndikon shpĂ«rndarja e tillĂ« nĂ« shpejtĂ«sinĂ« e rezervimit?

Do të provojmë të bëjmë një backup në dy "pajisje", të cilat janë të vendosura afër njëra-tjetrës në të njëjtën dosje:

BACKUP DATABASE [bt]
TO 
    DISK = 'D:SQLServerbackupbt1.bak',
    DISK = 'D:SQLServerbackupbt2.bak'   
WITH COMPRESSION;

Zoti, çfarë është duke ndodhur këtu?

Përpunuar 1070072 faqe për databazën 'bt', skedhë 'bt' në skedhën 1.

PĂ«rpunuar 2 faqe pĂ«r databazĂ«n ‘bt’, skedari ‘btlog’ nĂ« skedarin 1.

BACKUP DATABASE u përpunua me sukses 1070074 faqe në 40.092 sekonda (208.519 MB/sec).

Backup-i u bë 25% më i shpejtë pa ndonjë arsyetim të qartë? E nëse shtojmë edhe disa pajisje të tjera?

BACKUP DATABASE [bt]
TO 
    DISK = 'D:SQLServerbackupbt1.bak',
    DISK = 'D:SQLServerbackupbt2.bak',
    DISK = 'D:SQLServerbackupbt3.bak',
    DISK = 'D:SQLServerbackupbt4.bak'
WITH COMPRESSION;

BACKUP DATABASE u përpunua me sukses 1070074 faqe në 34.234 sekonda (244.200 MB/sec).

Pra, fitimi Ă«shtĂ« rreth 35% mĂ« pak kohĂ« pĂ«r tĂ« marrĂ« backup-in thjesht nga fakti se backup-i shkruhet menjĂ«herĂ« nĂ« 4 skedarĂ« nĂ« njĂ« disk. Kam provuar njĂ« numĂ«r mĂ« tĂ« madh — nĂ« laptopin tim, fitimi mungon, optimal — 4 pajisje. PĂ«r ju — nuk e di, duhet tĂ« provohet. Cfare Ă«shtĂ« mĂ« e rĂ«ndĂ«sishme, nĂ«se kĂ«to pajisje — janĂ« tĂ« vĂ«rtetĂ« disqe tĂ« ndryshme, urime, fitimi duhet tĂ« jetĂ« edhe mĂ« i dukshĂ«m.

Tani do të flasim se si ta rikuperojmë këtë sallë. Për këtë do të duhet të ndryshoni komandën e rikuperimit dhe të listoni të gjitha pajisjet:

RESTORE DATABASE [bt]
FROM 
    DISK = 'D:SQLServerbackupbt1.bak',
    DISK = 'D:SQLServerbackupbt2.bak',
    DISK = 'D:SQLServerbackupbt3.bak',
    DISK = 'D:SQLServerbackupbt4.bak'
WITH REPLACE, RECOVERY;

RESTORE DATABASE u përpunua me sukses 1070074 faqe në 38.027 sekonda (219.842 MB/sec).

Pak mĂ« shpejt, por diku aty rreth, jo nĂ« mĂ«nyrĂ« tĂ« dukshme. NĂ« pĂ«rgjithĂ«si, backup-i merret mĂ« shpejt, ndĂ«rsa rikuperimi Ă«shtĂ« po ashtu — sukses? Sipas mendimit tim — njĂ« sukses i mirĂ«. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme, prandaj do tĂ« pĂ«rsĂ«ris — nĂ«se ju humbeni edhe njĂ« nga kĂ«to skedarĂ« — humbni tĂ« gjithĂ« backup-in.

Nëse shikoni informacionin në regjistrin e backup-it, i cili nxirret me anë të Trace Flag 3213 dhe 3605, mund të vëreni se kur bëhet backup në disa pajisje, rritet, të paktën, numri i BUFFERCOUNT. Ndoshta, mund të provoni të përshtatni parametra më optimalë edhe për BUFFERCOUNT, BLOCKSIZE, MAXTRANSFERSIZE, por unë nuk arrita ta bëj menjëherë, dhe të kryej një testim të tillë përsëri, por për një numër të ndryshëm skedarësh, ishte tepër ngarkesë. Madje edhe disqet i bej të shtrenjta. Nëse dëshironi të organizoni një testim të tillë për veten tuaj, nuk është e vështirë të rimarrë skriptin.

NĂ« fund do tĂ« flasim pĂ«r çmimin. NĂ«se backup-i merret paralelisht me punĂ«n e pĂ«rdoruesve — duhet tĂ« qaseni me shumĂ« pĂ«rgjegjshmĂ«ri ndaj testimit, sepse nĂ«se backup-i merret mĂ« shpejt — disqet ngarkohen mĂ« fort, ngarkesa nĂ« procesor rritet (duhet qĂ« tĂ« gjithĂ« kĂ«tĂ« ta kompresoni gjithashtu), sipas radhĂ«s, ulet pĂ«rgjigjshmĂ«ria e pĂ«rgjithshme e sistemit.

Shakat e shakatave, por unë e kuptoj gjithashtu se nuk kam bërë ndonjë zbulim të jashtëzakonshëm. Ajo që është shkruar më sipër është thjesht një demostrim i asaj se si mund të përcaktohen parametrat optimal për krijimin e backup-eve.

Kujtoni se gjithçka që bëni, e bëni me rrezikun tuaj. Kontrolloni kopjet tuaja rezervë dhe mos harroni për DBCC CHECKDB.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster