LuraHosting

Servidores dedicados

5 artigos João Guilherme Henrique Siqueira Matheus Alexandre Por João Guilherme, Henrique Siqueira, and Matheus Alexandre

Acesso, reinstalação, RAID, migração e proteção dos servidores dedicados.

VPS ou servidor dedicado: qual escolher?

Em uma frase - VPS: uma fatia de um servidor físico, com recursos garantidos, pronta em minutos, com snapshot e reinstalação pelo painel. - Dedicado: a máquina inteira só sua, CPU, RAM, discos e rede sem vizinhos. Comparativo | | VPS | Dedicado | |---|---|---| | CPU | vCores (compartilham o processador físico do node) | Processador físico completo, todos os núcleos | | Desempenho | Ótimo para a maioria dos usos; pode oscilar em pico | Constante e previsível | | RAM/disco | Até o limite do plano | Até o limite físico da máquina (muito maior) | | Rede | Porta compartilhada no node | Porta dedicada | | Virtualização dentro dele | Limitada | Livre (Proxmox, VMs, containers à vontade) | | Ativação | Minutos | Horas a dias (montagem física) | | Snapshot pelo painel | Sim | Depende da configuração (RAID/backup próprio) | | Reinstalação | Pelo painel, 1 clique | Pelo IPMI/KVM ou pela equipe | | Preço | A partir de poucos reais/mês | Centenas a milhares de reais/mês | Quando a VPS é a escolha certa - Sites, APIs, bots, n8n, painéis, bancos pequenos e médios. - Servidores de jogo para grupos de amigos. - Projetos que precisam crescer aos poucos (é só fazer upgrade). - Quem quer snapshot e reinstalação sem depender de ninguém. Quando vale o dedicado - Cargas pesadas e constantes: servidores de jogo com muitos jogadores/mods, renderização, bancos grandes, streaming. - Quando "oscilação" não é aceitável (você vende hospedagem para os seus clientes, por exemplo). - Quando você precisa de virtualização própria (Proxmox/Hyper-V) ou de muitos IPs. - Quando a conta de várias VPS grandes já passa do preço de um dedicado. Perguntas frequentes O processador da VPS é dedicado? Os vCores são garantidos, mas o processador físico é compartilhado entre as VPS do node. Para núcleos exclusivos, o produto é o dedicado. Consigo migrar da VPS para o dedicado depois? Sim, veja Como migrar da VPS para um servidor dedicado. Onde ficam os dedicados e qual é o processador? As especificações exatas (modelo do processador, datacenter, provedora de rede) constam na página de cada plano. Na dúvida, pergunte ao comercial antes de contratar, a resposta muda conforme a linha do produto.

Como acessar o IPMI e o console KVM do seu servidor dedicado

Todo dedicado tem uma "porta dos fundos" que funciona mesmo com o sistema operacional travado ou sem rede: o IPMI (também chamado iDRAC na Dell, iLO na HPE ou BMC). É por ele que você vê a tela do servidor, reinicia, instala um sistema do zero e olha sensores de hardware. Como acessar 1. Os dados de acesso ao IPMI (endereço, usuário e senha) são enviados na ativação do servidor. Se não tem, abra um chamado. 2. Por segurança, o IPMI normalmente só é alcançável por VPN ou a partir de IPs autorizados. 3. Abra o endereço no navegador e faça login. O que dá para fazer Console remoto (KVM): a tela do servidor no navegador (HTML5) ou via Java, com teclado e mouse. Use para acompanhar o boot, corrigir um sistema que não sobe ou configurar a rede. Energia: ligar, desligar (graceful ou forçado) e reiniciar. Um "power cycle" resolve travamentos que não respondem nem ao console. Mídia virtual: monte uma ISO (do seu computador ou de uma URL) como se fosse um pendrive conectado ao servidor. É assim que se reinstala o sistema: monte a ISO → reinicie → escolha o dispositivo virtual no menu de boot (geralmente F11) → siga a instalação pelo console. Sensores e logs: temperatura, ventoinhas, fonte, disco com falha, erros de memória. Se algo acusa problema, mande o print no chamado. Boas práticas - Troque a senha padrão do IPMI no primeiro acesso. - Não exponha o IPMI na internet sem VPN. - Antes de reinstalar, confira em qual disco/RAID você vai instalar, veja Como reinstalar o sistema e configurar RAID no dedicado.

Como reinstalar o sistema e configurar RAID no servidor dedicado

Atenção: reinstalar apaga todos os dados. Em dedicado não existe snapshot automático pelo painel, faça o backup antes (Object Storage é o destino mais prático). Duas formas de reinstalar 1. Pela equipe (recomendado): abra um chamado informando o sistema desejado (Ubuntu, Debian, AlmaLinux, Windows Server, Proxmox…) e a configuração de RAID. A reinstalação é agendada e você recebe a nova senha. 2. Por conta própria, pelo IPMI: monte a ISO na mídia virtual e instale pelo console. Veja Como acessar o IPMI. Você precisará configurar a rede manualmente com o IP, máscara e gateway informados na ativação. Qual RAID escolher | RAID | O que faz | Espaço útil | Se um disco falhar | Indicado para | |---|---|---|---|---| | 0 | Divide os dados entre os discos | 100% | Perde tudo | Só cache/temporário | | 1 | Espelha em 2 discos | 50% | Continua funcionando | Sistema e dados importantes (padrão mais comum) | | 10 | Espelho + divisão (4+ discos) | 50% | Continua funcionando | Bancos de dados e jogos com muita escrita | | 5/6 | Paridade (3+/4+ discos) | 67–80% | Continua (1 ou 2 falhas) | Muito armazenamento com custo menor | Regra prática: RAID 1 para 2 discos, RAID 10 para 4. RAID não substitui backup, ele protege contra disco queimado, não contra rm -rf, ransomware ou erro humano. Depois de reinstalar 1. Atualize o sistema e configure o firewall (o mesmo guia da VPS vale aqui: Como configurar o firewall). 2. Configure o monitoramento do RAID para receber alerta de disco com falha (mdadm --monitor no software RAID; utilitário do fabricante no RAID por hardware). 3. Agende o backup automático. Disco com falha Sinais: alertas do RAID, erros de I/O no dmesg, sensor no IPMI. Abra um chamado com o print, a troca do disco é feita pela equipe, e em RAID 1/10 o servidor continua no ar durante a troca.

Como migrar da VPS para um servidor dedicado sem perder dados

Antes de começar 1. Contrate o dedicado e aguarde a ativação (a VPS continua no ar nesse meio tempo). 2. Faça um inventário do que roda na VPS: serviços, portas, bancos, crons, domínios apontados. 3. Reduza o TTL dos registros DNS para 300 segundos com pelo menos 1 dia de antecedência, assim a troca de IP propaga rápido. Passo a passo (Linux) 1. Prepare o dedicado com o mesmo sistema (ou mais novo) e instale os mesmos serviços (Docker, Nginx, banco…). 2. Copie os dados com rsync (retoma se cair e só envia o que mudou): # rode no dedicado, puxando da VPS rsync -avz --progress root@IP-DA-VPS:/var/www/ /var/www/ rsync -avz --progress root@IP-DA-VPS:/opt/ /opt/ Bancos de dados: exporte e importe, não copie a pasta com o serviço rodando: # na VPS mysqldump -u root -p --all-databases > /root/dump.sql # no dedicado mysql -u root -p < dump.sql Docker: copie os docker-compose.yml e os volumes (/var/lib/docker/volumes/...) com o container parado. 3. Teste no dedicado antes de trocar o DNS: acesse pelo IP, ou edite o arquivo hosts do seu computador apontando o domínio para o IP novo. 4. Janela de troca (parada mínima): 1. Coloque a VPS em modo de manutenção (ou pare de aceitar escritas). 2. Rode o rsync final (só as diferenças, leva segundos/minutos). 3. Exporte o banco de novo e importe. 4. Troque o DNS para o IP do dedicado. 5. Suba os serviços no dedicado. 5. Mantenha a VPS ligada por alguns dias como fallback. Só cancele depois de conferir logs, e-mails e crons no dedicado. Windows Use o mesmo raciocínio: instale os aplicativos no dedicado, copie os dados via RDP/WinSCP ou robocopy, exporte/importe bancos e troque o DNS. Para migração completa de disco existem ferramentas de imagem (ex.: Clonezilla via ISO no IPMI), mas exigem parada maior. O que muda de IP Tudo que tinha o IP antigo: DNS, webhooks (n8n, gateways de pagamento), whitelists em APIs de terceiros, PTR/rDNS de e-mail, configurações de clientes de jogo.

Proteção anti-DDoS: como funciona e o que fazer durante um ataque

O que a proteção faz A mitigação atua na rede, antes de o tráfego chegar ao seu servidor: quando o volume de pacotes para o seu IP foge do padrão, o tráfego é desviado para os filtros, o lixo é descartado e o tráfego legítimo segue. Isso cobre os ataques volumétricos e de protocolo (UDP flood, SYN flood, amplificação DNS/NTP etc.). O que ela não faz - Ataques de aplicação (camada 7): milhares de requisições HTTP "normais", spam de login em jogo, bots em API. Para o filtro eles parecem tráfego legítimo. A defesa aqui é no seu servidor: rate limit no Nginx, Cloudflare na frente do site, plugins anti-bot no jogo, firewall liberando só o necessário. - Proteger um servidor invadido ou mal configurado. Como saber se estou sob ataque - Ping alto ou perda de pacotes de repente, com o servidor sem carga (CPU/RAM normais). - Gráfico de rede do painel com pico anormal de entrada. - Jogadores caindo ao mesmo tempo. - Durante a mitigação é normal ver latência um pouco maior: é o tráfego passando pelos filtros. O que fazer durante um ataque 1. Não reinicie o servidor (não resolve e você perde o estado). 2. Confira o firewall: libere só as portas em uso (guia). Portas fechadas descartam pacotes de graça. 3. Se o ataque é a um serviço específico (site), coloque-o atrás do Cloudflare ou ative rate limit. 4. Abra um chamado com IP, horário e portas afetadas, a equipe consegue ver a mitigação e ajustar filtros para o seu perfil de tráfego (ex.: portas UDP de jogo). Reduzindo a exposição - Não divulgue o IP direto do servidor quando puder usar um domínio com proxy (site). - Servidores de jogo: use plugins/anti-bot da comunidade e mantenha a versão atualizada. - Feche painéis administrativos para o seu IP apenas.