Как се врши пренос сервера (миграција)? Пренос веб сајта без губитка података

Пренос сервера (миграција) представља процес планираног преноса фајлова веб сајта, базе података, е-поштанских налога, DNS записа и подешавања апликација са постојећег сервера на нови сервер. Основна метода за пренос веб сајта без губитка података је следећа: прво се прави комплетна резервна копија, нови сервер се подешава са истим или новијим верзијама софтвера, преносе се фајлови и база података, тестира се помоћу hosts фајла или привременог URL-a, DNS пренос се мења на ниски TTL, а након преноса се проверавају логови, формули, токови плаћања, испорука е-поште и SEO сигнализирање.

Процес преноса сервера није једноставан копирај и стави. Посебно за предузећа која користе WordPress, WooCommerce, Laravel, специјалне PHP апликације, високо-трафичне вести или корпоративне е-поште, погрешан пренос може довести до губитка наруџбина, покварених српских карактера, 500 грешака, SSL упозорења, прекида у испоруци е-поште и пада видљивости на претраживачима. Због тога, план миграције треба спровести уз техничку контролну листу и план повратка.

У овом водичу ћемо корак по корак обрадити како да промените хостинг или сервер у складу са SEO и перформансама 2026. године. Такође ћемо се осврнути на различите сценарије као што су cPanel, Plesk, VPS, облачни сервер и ручни пренос; делићемо применљиве предлоге за DNS време, обим резервних копија, компатибилност базе података, SSL инсталацију и SEO контроле након преноса.

Када је потребан пренос сервера?

Пренос веб сајта на нови сервер обично произлази из потребе за перформансама, безбедношћу, ценом или скалабилношћу. На пример, корпоративни сајт са 5.000 посетилаца месечно може несметано радити на деленом хостингу, док сајт за е-трговину који дневно има 20.000 посетилаца може имати проблема са CPU лимитом, спорим упитима и истеком времена на страници за плаћање. У овом тренутку, боље је изабрати јачи хостинг пакет, VPS или облачну инфраструктуру.

Уобичајени знаци који указују на потребу за преносом сервера укључују:

• Време учитавања странице прелази 3 секунде и метрике Core Web Vitals су нарушене.
• У хостинг панелу, лимити за CPU, RAM, inode или коришћење диска често су достижу.
• Потреба за ажурирањем компоненти као што су PHP, MySQL, MariaDB, Node.js или ionCube.
• Чести проблеми у вези са обнављањем SSL-а, испоруком е-поште или управљањем DNS-ом.
• Неприхватљан квалитет подршке, резервне копије или ниво безбедности код тренутног провајдера.
• Изненада повећање саобраћаја на сајту током кампања, реклама или сезонских периода.

Ако ваш сајт расте и приближава се границама актуелног пакета, много је сигурније направити контролисан план миграције него на брзину прелазити у кризним тренуцима. У зависности од ваших потреба, можете упоредити пакети веб хостинга, VPS серверска решења или корпоративни хостинг опције.

Припрема пре преноса: Најкритичнија фаза

Већи део пројеката преноса у којима дође до губитка података не пропадне током преноса, већ због недостатка припреме. Пре него што пренос почне, треба извршити инвентар постојећег сајта и јасно утврдити које податке требате пренети и које услуге су осетљиве на прекид.

1. Извршите инвентар сајта

Први корак је креирање техничке карте веб сајта. Треба забележити коришћени CMS или фрејмворк, верзију PHP-а, тип базе података, величину диска, е-поштанске налоге, cron задатке, DNS записе, SSL сертификат, посебне преносе и интеграције трећих страна. На пример, за WordPress сајт, само пренос wp-content фасцикле није довољан; правила .htaccess, подешавања wp-config.php, префикси табела базе података, кеширање и медијски фајлови такође требају бити проверени.

На е-трговинском сајту, платна инфраструктура, интеграција доставе, синхронизација складишта, ERP веза, SMTP услуга и webhook URL адресе такође се морају испитати. Ако након преноса не пристиже наруџбина, проблем је често у преносу фајлова, али у заборављеној IP ограничењу API-а или безбедносном правилима дефинисаним на старом серверу.

2. Направите потпуну резервну копију и потврдите

У процесу преноса сервера, самостално прављење резервне копије није довољно; такође се мора потврдити да је резервна копија могућа за повратак. Потпуна резервна копија треба да обухвати:

• Фајлови веб сајта: public_html, фасцикле апликација, upload директоријуми, фајлови тема и додатака.
• Базе података: MySQL, MariaDB, PostgreSQL или друге базе података које апликација користи.
• Податке о е-пошти: поштанске кутије, преноси, филтри, подешавања аутореспондера.
• DNS записи: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC записи.
• Конфигурације: .htaccess, nginx.conf, php.ini, cron посао, environment фајлови.
• SSL сертификати и посебна безбедносна правила.

Практичан приступ би био да се пре преноса направе најмање две резервне копије: једна на постојећем серверу, а друга на различитој локацији. За велике сајтове, за резервне копије фајлова може се користити rsync, за базу података mysqldump или алати за резервне копије у панелу. За базе података веће од 10 GB, компримоване и подељене резервне копије могу бити сигурније од једног великог dump-а.

3. Смањите DNS TTL вредност унапред

Да би се промена DNS-а брже ширила, добро је смањити TTL вредност 24 сата пре преноса. На пример, ако је TTL вредност 14400 секунди, неки корисници могу и даље ићи на стари сервер сатима. Смањење TTL вредности на 300 секунди пре преноса чини прелазак DNS-а контролисанијим. Након што се пренос заврши и све потврди, TTL се може поново повећати на 3600 или 14400 секунди.

Редовно управљање DNS-ом вашег домена директно утиче на успех миграције. За управљање именом домена и DNS конфигурацију можете погледати проверу домена и управљање именом домена водиче.

Поређење метода преноса сервера

Најбоља метода преноса није иста за сваку веб страницу. Мали корпоративни сајт може се лако пренети преко панела, док високо-трафични веб сајт за е-трговину може захтевати постепену синхронизацију и режим одржавања.

Када бирате нову инфраструктуру, само гледање на просторе диска може бити обмањујуће. Критеријуми као што су број PHP радника, CPU језгра, RAM, NVMe диск, учесталост резервних копија, локација дата центра, подршка за LiteSpeed или Nginx, WAF и DDoS заштита такође одређују перформансе. Због тога, прелазак на најјефтинији пакет без анализе потреба може довести до нове потребе за преносом у кратком року.

Корак по корак: Како се преноси сервер?

Корак 1: Припремите нови сервер

На новом серверу треба инсталирати оперативни систем, веб сервер, верзију PHP-а, услугу базе података и потребне модуле. За WordPress се препоручује PHP 8.2 или 8.3, актуелна MariaDB, OPcache и одговарајућа memory_limit вредност. У фрејмворцима као што је Laravel, Composer, cron, queue worker и дозволе за складиште такође требају бити подешене. Ако стари сервер има PHP додатке које нови сервер нема, након преноса се могу појавити беле екране или 500 грешке.

На безбедносној страни, треба подесити политику порта SSH, јаке лозинке, ватрозид, скенирање малвера и аутоматске упдате. Постављање основа безбедности на новом серверу док је још празан је лакше него интервенисати касније. Ако вам је потребан SSL, тему подешавање SSL сертификата обавезно укључите у план миграције.

Корак 2: Пренесите фајлове

За пренос фајлова, у зависности од величине сајта, можете користити FTP, SFTP, SSH, rsync или алат за резервне копије у панелу. За мале сајтове, прављење компримоване архиве и отварање на новом серверу је довољно. За велике сајтове, препоручује се прва копија да се узме са rsync, а затим извршити другу синхронизацију непосредно пре промене DNS-а. Ова метода штеди време, посебно код сајтова где се upload фасцикла непрестано мења.

Након преноса фајлова, проверите дозволе. Уопштено, фасцикле функционишу са дозволама 755, а фајлови са 644; али свакој апликацији могу бити потребне различите. Фајлови као што су wp-config.php, .env или слични осетљиви фајлови не би требали бити доступни свима. Такође, уверите се да су копирани тајни фајлови као што су .htaccess и .user.ini.

Корак 3: Пренесите базу података

Пренос базе података је најосетљивији део у превенци губитка података. Прво се узима dump са старог сервера, а затим се на новом серверу креира база података и корисник. Сет карактера треба поставити на utf8mb4 ако је могуће. Да би се избегло покварење српских карактера, структура collation треба бити очувана током извоза и увоза.

На сајтовима који генеришу тренутне податке, као што су WooCommerce или системи чланства, може се користити режим одржавања током преноса. У супротном, током ширења DNS-а, неки корисници могу писати податке на стари сервер, а неки на нови. Ово може створити несагласности у наруџбинама, коментарима, записима формула или информацијама о чланству. На критичним сајтовима, последњи dump базе података треба да се узме након укључивања режима одржавања.

Корак 4: Ажурирајте конфигурационе фајлове

Име базе података, корисничко име, лозинка, хост информације и путеви фајлова треба да буду прилагођени новом серверу. За WordPress проверите wp-config.php, за Laravel .env, а за специјалне апликације config.php или сличне фајлове. Ако старе апсолутне путеве фајлова, IP адресе, SMTP подешавања или директорији кеша остану, сајт се може видети, али у позадини ће се јавити грешке.

Такође, PHP memory_limit, upload_max_filesize, post_max_size и max_execution_time вредности треба подесити у складу са потребама ваше апликације. На пример, ако се у управљачком панелу постави лимит за upload на 32 MB, а требате да отпремите слику производа од 200 MB, иако је пренос успешан, операција неће моћи да се настави.

Корак 5: Тестирајте пре промене DNS-а

Најсигурнија пракса преноса је тестирање новог сервера пре него што промените DNS. За то можете повезати домен на IP адресу новог сервера у hosts фајлу на вашем рачунару. На тај начин, док посетиоци и даље виде стари сервер, ви тестирајте нови сервер са правим доменом.

Тест листа треба да укључује следеће контроле:

• Да ли се отварају главна страница, категорије, производи, блог и контакт странице?
• Да ли функционише слање форма, логовање чланова, ресетовање лозинки и ток плаћања?
• Да ли се визуели, CSS и JavaScript фајлови учитавају без пропуста?
• Да ли се управљачка табла отвара без грешака?
• Да ли је SSL сертификат инсталиран на правом домену?
• Да ли постоје грешке 404, 500, mixed content или цикличне редирекције?
• Да ли су robots.txt, sitemap.xml и канонски етикети исправни?

Корак 6: Инсталирајте SSL сертификат

У модерним веб страницама SSL није само безбедност, већ је и обавезан за SEO и поверење корисника. Ако се DNS промени пре инсталације SSL на новом серверу, корисници могу видети упозорење о несигурности. Зато, SSL сертификат треба припремити непосредно пре промена DNS-а или истовремено са прелазком. Бесплатни сертификати као што је Let’s Encrypt могу бити довољни за многе сајтове; за корпоративне пројекте који обрађују плаћања, могу се одабрати сертификати са вишим нивоом верификације.

Након инсталације SSL, уверите се да су HTTP адресе пренете на HTTPS путем 301 редирекције, да не постоји mixed content грешка, и да су HTTPS URL-ови укључени у мапу сајта. За производе и опције инсталације SSL можете погледати SSL сертификати страницу.

Корак 7: Промените DNS записи

Након успешних тестова, A запис на DNS-у се преусмерава на IP адресу новог сервера. Ако се е-пошта преноси на исти сервер, MX, SPF, DKIM и DMARC записи такође требају бити ажурирани. Ако ће е-пошта остати код другог провајдера, не треба мењати MX записи. Једна од најчешћих грешака је променити е-поштанске записи погрешно, само желећи преносити веб сајт, што доводи до прекида у саобраћају е-поште.

Ширење DNS-а обично траје од неколико минута до 24 сата. Ако је TTL раније смањен, већина корисника ће убрзо стићи до новог сервера. У овом процесу, не затварајте стари сервер одмах. Безбедно је држати стари сервер активним најмање 48 сати, а ако је могуће, 72 сата.

Корак 8: Извршите последњу синхронизацију и проверу логова

Након промене DNS-а, треба проверити да ли постоје нови подаци написани на старом серверу. Посебно треба упоредити наруџбе, контакне формуле, записи корисника и коментаре. Логови веб сервера, access log и error log, помажу у разумевању које IP адресе су послале захтеве на који сервер.

Током првих 24 сата након преноса, треба пратити 500 грешке, повећање 404, споре упите, скокове CPU-а и редове е-поште. Ако се ове контроле не обаве, сајт може изгледати активан, али у позадини може доћи до губитка конверзије.

Контролна листа за професионалну миграцију без губитка података

Следећа контролна листа обухвата најчешће проблематичне тачке у пракси. Проверите ову листу пре и после преноса како бисте значајно смањили ризик од миграције.

• Планиран је пренос у време ниског саобраћаја.
• Направљена је комплетна резервна копија фајлова, базе података, е-поште и DNS-а.
• Тестирано је да ли резервна копија може бити враћена.
• DNS TTL вредност је смањена најмање 24 сата пре преноса.
• На новом серверу су припремљени PHP, база података и потребни модули.
• Фајлови су пренесени без пропуста и проверене су дозволе.
• Проверена је компатибилност карактера и collation базе података.
• Конфигурациони фајлови су ажурирани према информацијама о новом серверу.
• Тестирано је пре него што се иде уживо уз hosts фајл.
• Инсталиран је SSL, проверене су HTTPS редирекције.
• DNS A, AAAA, MX, TXT записи су исправно ажурирани.
• Стар сервер је држан активан најмање 48 сати.
• Пратиле су се Google Search Console, Analytics и логови.

Контроле након миграције да се избегне губитак SEO-а

Пренос сервера теоретски не би требало да доведе до губитка SEO-а, под условом да се структура URL-а не мења. Међутим, у пракси, спорост, 404 грешке, погрешан robots.txt, недостајући SSL или грешке у редирекцији могу утицати на позиције. Зато је SEO контрола након преноса једнако важна као и техничка миграција.

Контрола URL и редирекција

Ако не мењате структуру URL-а при преносу, потреба за 301 редирекцијом је минимална. Међутим, ако истовремено мењате име домена, структуру перма линка или структуру фасцикле, стари URL-ови треба да буду усмерени на нове одговарајуће 301. 302 привремена редирекција није погодна за пренос SEO сигнала. На пример, ако је стара страница /urun/abc премештена на нову адресу /magaza/abc, мора се направити директна редирекција; усмеравање свих старих URL-ова на главну страницу негативно утиче на корисничко искуство и SEO перформансе.

Контрола robots.txt и sitemap

Ако је током тестирања у robots.txt коришћен Disallow за блокирање претраживача, то треба уклонити када се иде уживо. Ова грешка је један од најкласичнијих разлога за губитак индекса након миграције. У мапи сајта треба укључити нове HTTPS URL-ове и поново их послати преко Google Search Console.

Перформансе и Core Web Vitals

Иако нови сервер може бити моћнији, погрешна подешавања кеширања могу смањити перформансе. LiteSpeed Cache, Redis, OPcache, CDN и оптимизација слика требају бити исправно конфигурисани. Првих недељу дана после преноса, треба пратити PageSpeed Insights, Chrome UX Report и логове сервера како бисте проверили да ли постоји погоршање LCP, INP и CLS метрика. За побољшање перформанси хостинга можете искористити оптимизацију брзине WordPress-a информације.

Ствари које треба имати на уму током преноса е-поште

У многим преносима веба, док се веб фајлови преносе без проблема, е-пошта се често занемарује. Ако се е-поште чувају на постојећем серверу, поштанске кутије, лозинке корисника, преноси и филтри морају бити пренети. IMAP синхронизација је поуздан метод за пренос е-поште из старе у нову поштанску кутију.

На DNS страни, MX запис одређује сервер е-поште, SPF ауторизацију за слање, DKIM потписивање, а DMARC одређује политику домена. Ако се ови записи погрешно конфигуришу, е-поште могу завршити у спам фолдеру или могу бити потпуно одбијене. Након преноса, треба тестирати слање на Gmail, Outlook и корпоративне е-поштанске рачуне; треба проверити податке о заглављу е-поште.

Честе грешке у преносу сервера

Успешни пројекти миграције имају заједничку тачку, а то је спречавање једноставних грешака унапред. Следеће грешке су најчешће проблематичне:

• Извршити пренос без прављења резервне копије или тестирања резервне копије.
• Променити IP без смањења DNS TTL вредности.
• Затворити стари сервер пре него што се заврши ширење DNS-а.
• Погрешно преносити сет карактера базе података и покварити српске карактере.
• Заборавити правила редирекције у .htaccess или nginx.
• Упутити HTTPS саобраћај на нови сервер без SSL-а.
• Погрешно ажурирати MX и TXT записи е-поште.
• Оставити кеш додатак путем старог сервера.
• Не пратити Search Console и логове након преноса.

Посебно за сајтове који активно продају, пренос треба извршити у време радне недеље када је саобраћај и обим наруџби најмањи. У великим пројектима е-трговине, планирање 15-30 минута одржавања помаже у спречавању могућих несагласности у подацима.

Када треба да се обратите професионалној подршци за миграцију?

Могуће је ручно пренети једноставан промотивни сајт; међутим, у неким ситуацијама је боље добити професионалну подршку, што може бити економичније и сигурније. Е-трговински сајтови са високим месечним приходима, компаније са много е-поштанских налога, портали са специјалним софтвером, медијски сајтови са високим саобраћајем и предузећа која чувају податке под регулативом спадају у ову групу.

Процес професионалне подршке за пренос обично обухвата пред-анализу, прављење резервне копије, постављање тестне средине, пренос, промену DNS-а, верификацију и праћење. Тако, не само да се преносе фајлови, већ и континуитет пословања. Ако планирате прелазак на инфраструктуру Hostragons, можете погледати Hostragons хостинг решења страницу како бисте заједно оцењивали хостинг, домене и SSL опције у складу са вашим потребама.

Закључак: Планирани пренос сервера спречава прекиде и губитак података

Пренос сервера није процес којег се треба бојати ако се правилно планира. Кључ успеха је: комплетна резервна копија, правилна припрема сервера, план DNS TTL, тестна средина, инсталација SSL-а, контрола е-поште и кораци праћења после преноса. Посебно у случајевима где база података непрестано варира, последња синхронизација и режим одржавања играју критичну улогу.

Укратко, не журите са преносом веб сајта без губитка података, проверавајте сваки корак и не затварајте стари сервер одмах. Ако желите да обновите своју инфраструктуру и пружите брже и сигурније веб искуство, можете погледати хостинг, домене и SSL решења на Hostragons и мирно и контролисано креирати план прелаза у складу са вашим потребама.

Често постављана питања

Колико траје пренос сервера?

Време трајања зависи од величине и сложености сајта. Мали WordPress сајт може се пренети за 30-60 минута, док велики пројекти е-трговине или корпоративни пројекти са много е-поште могу трајати 1-3 дана, укључујући припрему, тестирање и ширење DNS-а.

Да ли ће мој сајт бити затворен током преноса сервера?

Ако се правилно планира, прекид може бити смањен на неколико минута или корисници можда неће осетити прекид. За то, TTL DNS-а треба да буде смањен унапред, нови сервер треба тестирати пре него што постане активан, а стари сервер треба остати активан све док се ширење DNS-а не заврши.

Који је најважнији корак за избегавање губитка података?

Најважнији корак је верификована комплетна резервна копија. Фајлови, база података, е-пошта и DNS записи морају бити резервисани; посебно на сајтовима који генеришу податке о наруџбинама или чланствима, последња резервна копија базе података треба да се узме након укључивања режима одржавања.

Да ли пренос сервера утиче на SEO позиције?

Ако се структура URL-а одржава, сајт ради брзо, SSL и редирекције су исправне, пренос сервера не би требало да доведе до губитка SEO-а. Међутим, 404 грешке, погрешан robots.txt, спор сервер или неисправне 301 редирекције могу негативно утицати на позиције.

Да ли се е-поштански налози преносе током преноса сервера?

Ако се е-поште чувају на старом хостингу, морају бити пренете. Поштанске кутије, преноси, филтри и MX, SPF, DKIM, DMARC записи морају бити проверени. Ако е-пошта остаје код другог провајдера, MX записи не треба мењати.