One place for hosting & domains

      Service

      How to Defeat Ransomware With Disaster Recovery as a Service


      Given the eye-catching headlines and high-profile disasters, ransomware’s ability to wreak havoc probably needs no introduction.

      Case in point: The government of Jackson County, Georgia, was recently forced to pay $400,000 in cryptocurrency to a criminal gang that had taken over the network and encrypted their environment, making it completely unusable. Numerous stories like this can be found in headlines across the globe, taken from the experiences of hospitals, universities and businesses alike.

      In 2017, the FBI’s Internet Crime Complaint Center received 1,783 complaints from U.S. organizations that were infected with ransomware. These attacks cost millions of dollars in losses. Yet these numbers represent only a fraction of the total number of attacks, as the vast majority are never reported to the FBI.

      Certainly, ransomware can be devastating, but here’s a secret: It doesn’t have to be.

      Disaster Recovery as a Service (DRaaS) allows you to invalidate the threat of ransomware by creating redundancy in your environment. This blog will cover how that works, but first, let’s take some time to understand ransomware.

      What Is Ransomware?

      Ransomware comes in many forms, but two main varieties have emerged: locker-ware and crypto-ware. Locker-ware involves a hacker taking control of a specific computer or network and then changing passwords so that systems cannot be accessed. Crypto-ware uses encryption techniques to mask all data, rendering it unreadable or unusable.

      In both types of ransomware attacks, the criminals extort the organization, offering to unlock the system only after receiving payment (usually in the form of cryptocurrency).

      In 2017, ransomware program WannaCry made headlines, infecting an estimated 200,000 computers and netting its creators roughly $300 every time someone chose to pay to decrypt their computers. The real cost, however, is far greater when you include lost productivity and the work required to recover systems impacted by WannaCry. Estimates ranged from hundreds of millions of dollars, even into the billions.

      Disaster Recovery as a Service (DRaaS): The Silver Bullet for Ransomware

      The first line of defense against any cyberattack or phishing attempt is proper security training for all employees. Foundational security measures include training employees to validate links before clicking them and verifying the identity and legitimacy of senders. For example, a common trick of hackers involves replacing or switching letters in email addresses to make them appear legitimate (e.g., lnap.com vs. inap.com). Every organization should have strong group policy objects set for their end users, such as enforcing unique passwords, limiting the installation of software and disabling forced system restarts.

      One of the best ways to protect your organization from ransomware is to put in place Disaster Recovery as a Service (DRaaS) for your critical applications and infrastructure. DRaaS comes in different flavors, and which option you go with will depend on your recovery needs: i.e., Recovery Point Objectives and Recovery Time Objectives. Read our blog on RPO and RTO to learn about what these mean.

      Regardless of how often you need to back up (RPO) or how quickly you need your applications to be online (RTO), DRaaS is a straightforward, effective way to neutralize the threat of ransomware.

      Here’s how: DRaaS safeguards your physical and virtual systems by creating a functionally redundant environment that you can switch on in the case of any disaster. This minimizes downtime and its impact on your business, while ensuring that you have a “clean” environment that is safe from any malware—ransomware or otherwise.

      If attackers do gain control of your systems, all you have to do is contact your DRaaS service provider to begin the recovery process. As an INAP customer, you can call, email or log in to your portal to immediately let us know what’s happened. We will work with you to verify what systems or files need to be recovered, confirm the recovery point you need, then begin a full recovery to overwrite the compromised environment. This process will usually follow a detailed runbook that is collaboratively designed when the DRaaS solution was first implemented as part of our white glove onboarding.

      Learn More About INAP Disaster Recovery as a Service

      INAP offers two kinds of Disaster Recovery as a Service: On-Demand DRaaS and Dedicated DRaaS. Both offer redundancy and protection from ransomware—built on our secure, high-performance private cloud. We also offer disaster recovery testing to evaluate your DRaaS solution’s efficacy in a realistic scenario, in addition to a white glove onboarding service.

      With a DRaaS solution in place, you can feel confident that your environments are safe from would-be hijackers and, most importantly, costly downtime—whether caused by ransomware, natural disaster, human error or anything else.

      Explore INAP Disaster Recovery as a Service.

      LEARN MORE

      Allan Williamson
      • Technical Account Manager


      READ MORE



      Source link

      Uma Introdução aos Service Meshes


      Introdução

      Um service mesh é uma camada de infraestrutura que permite gerenciar a comunicação entre os microsserviços da sua aplicação. À medida que mais desenvolvedores trabalham com microsserviços, os service meshes evoluíram para tornar esse trabalho mais fácil e mais eficaz consolidando tarefas administrativas e de gerenciamento comuns em uma configuração distribuída.

      Aplicar uma abordagem de microsserviço à arquitetura de aplicações envolve dividir sua aplicação em uma coleção de serviços fracamente acoplados. Essa abordagem oferece certos benefícios: as equipes podem iterar projetos e escalar rapidamente, usando uma variedade maior de ferramentas e linguagens. Por outro lado, os microsserviços representam novos desafios para a complexidade operacional, consistência de dados e segurança.

      Service meshes são projetados para resolver alguns desses desafios, oferecendo um nível granular de controle sobre como os serviços se comunicam uns com os outros. Especificamente, eles oferecem aos desenvolvedores uma maneira de gerenciar:

      • Descoberta de serviço
      • Roteamento e configuração de tráfego
      • Criptografia e autenticação/autorização
      • Métricas e monitoramento

      Embora seja possível executar essas tarefas de forma nativa com orquestradores de containers como o Kubernetes, essa abordagem envolve uma maior quantidade de tomadas de decisão e administração antecipadas quando comparada com o que as soluções de service mesh como o Istio e o Linkerd oferecem por fora. Nesse sentido, service meshes podem agilizar e simplificar o processo de trabalho com componentes comuns em uma arquitetura de microsserviço. Em alguns casos, eles podem até ampliar a funcionalidade desses componentes.

      Por que Service Meshes?

      Service meshes são projetados para resolver alguns dos desafios inerentes às arquiteturas de aplicações distribuídas.

      Essas arquiteturas cresceram a partir do modelo de aplicação de três camadas, que dividia as aplicações em uma camada web, uma camada de aplicação e uma camada de banco de dados. Ao escalar, esse modelo se mostrou desafiador para organizações que experimentam um rápido crescimento. Bases de código de aplicações monolíticas podem se tornar bagunçadas, conhecidas como “big balls of mud”, impondo desafios para o desenvolvimento e o deployment.

      Em resposta a esse problema, organizações como Google, Netflix e Twitter desenvolveram bibliotecas “fat client” internas para padronizar as operações de runtime entre os serviços. Essas bibliotecas forneceram balanceamento de carga, circuit breaker , roteamento e telemetria — precursores para recursos de service mesh. No entanto, eles também impuseram limitações às linguagens que os desenvolvedores poderiam usar e exigiram mudanças nos serviços quando eles próprios foram atualizados ou alterados.

      Um design de microsserviço evita alguns desses problemas. Em vez de ter uma base de código grande e centralizada de aplicações, você tem uma coleção de serviços gerenciados discretamente que representam um recurso da sua aplicação. Os benefícios de uma abordagem de microsserviço incluem:

      • Maior agilidade no desenvolvimento e no deployment, já que as equipes podem trabalhar e fazer deploy de diferentes recursos de aplicações de forma independente.
      • Melhores opções para CI/CD, já que microsserviços individuais podem ser testados e terem deploys refeitos independentemente.
      • Mais opções para linguagens e ferramentas. Os desenvolvedores podem usar as melhores ferramentas para as tarefas em questão, em vez de se restringirem a uma determinada linguagem ou conjunto de ferramentas.
      • Facilidade de escalar.
      • Melhorias no tempo de atividade, experiência do usuário e estabilidade.

      Ao mesmo tempo, os microsserviços também criaram desafios:

      • Sistemas distribuídos exigem diferentes maneiras de pensar sobre latência, roteamento, fluxos de trabalho assíncronos e falhas.
      • As configurações de microsserviço podem não atender necessariamente aos mesmos requisitos de consistência de dados que as configurações monolíticas.
      • Níveis maiores de distribuição exigem designs operacionais mais complexos, particularmente quando se trata de comunicação de serviço a serviço.
      • A distribuição de serviços aumenta a área de superfície para vulnerabilidades de segurança.

      Service meshes são projetados para resolver esses problemas, oferecendo controle coordenado e granular sobre como os serviços se comunicam. Nas seções a seguir, veremos como service meshes facilitam a comunicação de serviço a serviço por meio da descoberta de serviços, roteamento e balanceamento interno de carga, configuração de tráfego, criptografia, autenticação e autorização, métricas e monitoramento. Vamos utilizar a aplicação de exemplo Bookinfo do Istio — quatro microsserviços que juntos exibem informações sobre determinados livros — como um exemplo concreto para ilustrar como os service meshes funcionam.

      Descoberta de Serviço

      Em um framework distribuído, é necessário saber como se conectar aos serviços e saber se eles estão ou não disponíveis. Os locais das instâncias de serviço são atribuídos dinamicamente na rede e as informações sobre eles estão em constante mudança, à medida que os containers são criados e destruídos por meio do escalonamento automático, upgrades e falhas.

      Historicamente, existiram algumas ferramentas para fazer a descoberta de serviços em uma estrutura de microsserviço. Repositórios de chave-valor como o etcd foram emparelhados com outras ferramentas como o Registrator para oferecer soluções de descoberta de serviços. Ferramentas como o Consul iteraram isso combinando um armazenamento de chave-valor com uma interface de DNS que permite aos usuários trabalhar diretamente com seu servidor ou nó DNS.

      Tomando uma abordagem semelhante, o Kubernetes oferece descoberta de serviço baseada em DNS por padrão. Com ele, você pode procurar serviços e portas de serviço e fazer pesquisas inversas de IP usando convenções comuns de nomenclatura de DNS. Em geral, um registro A para um serviço do Kubernetes corresponde a esse padrão: serviço.namespace.svc.cluster.local. Vamos ver como isso funciona no contexto do aplicativo Bookinfo. Se, por exemplo, você quisesse informações sobre o serviço details do aplicativo Bookinfo, poderia ver a entrada relevante no painel do Kubernetes:

      Details Service in Kubernetes Dash

      Isto lhe dará informações relevantes sobre o nome do serviço, namespace e ClusterIP, que você pode usar para se conectar ao seu serviço, mesmo que os containers individuais sejam destruídos e recriados.

      Um service mesh como o Istio também oferece recursos de descoberta de serviço. Para fazer a descoberta de serviços, o Istio confia na comunicação entre a API do Kubernetes, o próprio plano de controle do Istio, gerenciado pelo componente de gerenciamento de tráfego Pilot, e seu plano de dados, gerenciado pelos proxies sidecar Envoy. O Pilot interpreta os dados do servidor da API do Kubernetes para registrar as alterações nos locais do Pod. Em seguida, ele converte esses dados em uma representação canônica Istio e os encaminha para os proxies sidecar.

      Isso significa que a descoberta de serviço no Istio é independente de plataforma, o que podemos ver usando o add-on Grafana do Istio para olhar o serviço details novamente no painel de serviço do Istio:

      Details Service Istio Dash

      Nossa aplicação está sendo executada em um cluster Kubernetes, então, mais uma vez, podemos ver as informações relevantes do DNS sobre o Serviço details, juntamente com outros dados de desempenho.

      Em uma arquitetura distribuída, é importante ter informações atualizadas, precisas e fáceis de localizar sobre serviços. Tanto o Kubernetes quanto os service meshes, como o Istio, oferecem maneiras de obter essas informações usando convenções do DNS.

      Configuração de Roteamento e Tráfego

      Gerenciar o tráfego em uma estrutura distribuída significa controlar como o tráfego chega ao seu cluster e como ele é direcionado aos seus serviços. Quanto mais controle e especificidade você tiver na configuração do tráfego externo e interno, mais você poderá fazer com sua configuração. Por exemplo, nos casos em que você está trabalhando com deployments piloto (canary), migrando aplicativos para novas versões ou testando serviços específicos por meio de injeção de falhas, ter a capacidade de decidir quanto tráfego seus serviços estão obtendo e de onde ele vem será a chave para o sucesso de seus objetivos.

      O Kubernetes oferece diferentes ferramentas, objetos e serviços que permitem aos desenvolvedores controlar o tráfego externo para um cluster: kubectl proxy, NodePort, Load Balancers, e Ingress Controllers and Resources. O kubectl proxy e o NodePort permitem expor rapidamente seus serviços ao tráfego externo: O kubectl proxy cria um servidor proxy que permite acesso ao conteúdo estático com um caminho HTTP, enquanto o NodePort expõe uma porta designada aleatoriamente em cada node. Embora isso ofereça acesso rápido, as desvantagens incluem ter que executar o kubectl como um usuário autenticado, no caso do kubectl proxy, e a falta de flexibilidade nas portas e nos IPs do node, no caso do NodePort. E, embora um Balanceador de Carga otimize a flexibilidade ao se conectar a um serviço específico, cada serviço exige seu próprio Balanceador de Carga, o que pode custar caro.

      Um Ingress Resource e um Ingress Controller juntos oferecem um maior grau de flexibilidade e configuração em relação a essas outras opções. O uso de um Ingress Controller com um Ingress Resource permite rotear o tráfego externo para os serviços e configurar o roteamento interno e o balanceamento de carga. Para usar um Ingress Resource, você precisa configurar seus serviços, o Ingress Controller e o LoadBalancer e o próprio Ingress Resource, que especificará as rotas desejadas para os seus serviços. Atualmente, o Kubernetes suporta seu próprio Controlador Nginx, mas há outras opções que você pode escolher também, gerenciadas pelo Nginx, Kong, e outros.

      O Istio itera no padrão Controlador/Recurso do Kubernetes com Gateways do Istio e VirtualServices. Como um Ingress Controller, um gateway define como o tráfego de entrada deve ser tratado, especificando as portas e os protocolos expostos a serem usados. Ele funciona em conjunto com um VirtualService, que define rotas para serviços dentro da malha ou mesh. Ambos os recursos comunicam informações ao Pilot, que encaminha essas informações para os proxies Envoy. Embora sejam semelhantes ao Ingress Controllers and Resources, os Gateways e os VirtualServices oferecem um nível diferente de controle sobre o tráfego: em vez de combinar camadas e protocolos Open Systems Interconnection (OSI), Gateways e VirtualServices permitem diferenciar entre as camadas OSI nas suas configurações. Por exemplo, usando VirtualServices, as equipes que trabalham com especificações de camada de aplicação podem ter interesses diferenciados das equipes de operações de segurança que trabalham com diferentes especificações de camada. Os VirtualServices possibilitam separar o trabalho em recursos de aplicações distintos ou em diferentes domínios de confiança e podem ser usados para testes como canary, rollouts graduais, testes A/B, etc.

      Para visualizar a relação entre os serviços, você pode usar o add-on Servicegraph do Istio, que produz uma representação dinâmica da relação entre os serviços usando dados de tráfego em tempo real. A aplicação Bookinfo pode se parecer com isso sem qualquer roteamento personalizado aplicado:

      Bookinfo service graph

      Da mesma forma, você pode usar uma ferramenta de visualização como o Weave Scope para ver a relação entre seus serviços em um determinado momento. A aplicação Bookinfo sem roteamento avançado pode ter esta aparência:

      Weave Scope Service Map

      Ao configurar o tráfego de aplicações em uma estrutura distribuída, há várias soluções diferentes — de opções nativas do Kubernetes até service meshes como o Istio — que oferecem várias opções para determinar como o tráfego externo chegará até seus recursos de aplicação e como esses recursos se comunicarão entre si.

      Criptografia e Autenticação/Autorização

      Um framework distribuído apresenta oportunidades para vulnerabilidades de segurança. Em vez de se comunicarem por meio de chamadas internas locais, como aconteceria em uma configuração monolítica, os serviços em uma arquitetura de microsserviço transmitem informações, incluindo informações privilegiadas, pela rede. No geral, isso cria uma área de superfície maior para ataques.

      Proteger os clusters do Kubernetes envolve uma variedade de procedimentos; Vamos nos concentrar em autenticação, autorização e criptografia. O Kubernetes oferece abordagens nativas para cada um deles:

      • Autenticação: As solicitações de API no Kubernetes estão vinculadas a contas de usuário ou serviço, que precisam ser autenticadas. Existem várias maneiras diferentes de gerenciar as credenciais necessárias: Tokens estáticos, tokens de bootstrap, certificados de cliente X509 e ferramentas externas, como o OpenID Connect.
      • Autorização: O Kubernetes possui diferentes módulos de autorização que permitem determinar o acesso com base em funções como papéis, atributos e outras funções especializadas. Como todas as solicitações ao servidor da API são negadas por padrão, cada parte de uma solicitação da API deve ser definida por uma política de autorização.
      • Criptografia: Pode referir-se a qualquer um dos seguintes: conexões entre usuários finais e serviços, dados secretos, terminais no plano de controle do Kubernetes e comunicação entre componentes worker do cluster e componentes master. O Kubernetes tem diferentes soluções para cada um deles:

      A configuração de políticas e protocolos de segurança individuais no Kubernetes requer investimento administrativo. Um service mesh como o Istio pode consolidar algumas dessas atividades.

      O Istio foi projetado para automatizar parte do trabalho de proteção dos serviços. Seu plano de controle inclui vários componentes que lidam com segurança:

      • Citadel: gerencia chaves e certificados.
      • Pilot: supervisiona as políticas de autenticação e nomenclatura e compartilha essas informações com os proxies Envoy.
      • Mixer: gerencia autorização e auditoria.

      Por exemplo, quando você cria um serviço, o Citadel recebe essa informação do kube-apiserver e cria certificados e chaves SPIFFE para este serviço. Em seguida, ele transfere essas informações para Pods e sidecars Envoy para facilitar a comunicação entre os serviços.

      Você também pode implementar alguns recursos de segurança habilitando o TLS mútuo durante a instalação do Istio. Isso inclui identidades de serviço fortes para comunicação interna nos clusters e entre clusters, comunicação segura de serviço para serviço e de usuários para serviço, e um sistema de gerenciamento de chaves capaz de automatizar a criação, a distribuição e a rotação de chaves e certificados.

      Ao iterar em como o Kubernetes lida com autenticação, autorização e criptografia, service meshes como o Istio são capazes de consolidar e estender algumas das melhores práticas recomendadas para a execução de um cluster seguro do Kubernetes.

      Métricas e Monitoramento

      Ambientes distribuídos alteraram os requisitos para métricas e monitoramento. As ferramentas de monitoramento precisam ser adaptativas, respondendo por mudanças frequentes em serviços e endereços de rede, e abrangentes, permitindo a quantidade e o tipo de informações que passam entre os serviços.

      O Kubernetes inclui algumas ferramentas internas de monitoramento por padrão. Esses recursos pertencem ao seu pipeline de métricas de recursos, que garante que o cluster seja executado conforme o esperado. O componente cAdvisor coleta estatísticas de uso de rede, memória e CPU de containers e nodes individuais e passa essas informações para o kubelet; o kubelet, por sua vez, expõe essas informações por meio de uma API REST. O servidor de métricas obtém essas informações da API e as repassa para o kube-aggregator para formatação.

      Você pode estender essas ferramentas internas e monitorar os recursos com uma solução completa de métricas. Usando um serviço como o Prometheus como um agregador de métricas, você pode criar uma solução diretamente em cima do pipeline de métricas de recursos do Kubernetes. O Prometheus integra-se diretamente ao cAdvisor através de seus próprios agentes, localizados nos nodes. Seu principal serviço de agregação coleta e armazena dados dos nodes e os expõe através de painéis e APIs. Opções adicionais de armazenamento e visualização também estão disponíveis se você optar por integrar seu principal serviço de agregação com ferramentas de backend de armazenamento, registro e visualização, como InfluxDB, Grafana, ElasticSearch, Logstash, Kibana, e outros.

      Em um service mesh como o Istio, a estrutura do pipeline completo de métricas faz parte do design da malha. Os sidecars do Envoy operando no nível do Pod comunicam as métricas ao Mixer, que gerencia políticas e telemetria. Além disso, os serviços Prometheus e Grafana estão habilitados por padrão (embora se você estiver instalando o Istio com o Helm você precisará especificar granafa.enabled=true durante a instalação). Como no caso do pipeline completo de métricas, você também pode configurar outros serviços e deployments para opções de registro e visualização.

      Com essas ferramentas de métrica e visualização, você pode acessar informações atuais sobre serviços e cargas de trabalho em um local central. Por exemplo, uma visão global do aplicativo BookInfo pode ter esta aparência no painel Grafana do Istio:

      Bookinfo services from Grafana dash

      Ao replicar a estrutura de um pipeline completo de métricas do Kubernetes e simplificar o acesso a alguns de seus componentes comuns, service meshes como o Istio agilizam o processo de coleta e visualização de dados ao trabalhar com um cluster.

      Conclusão

      As arquiteturas de microsserviço são projetadas para tornar o desenvolvimento e o deployment de aplicações mais rápidos e confiáveis. No entanto, um aumento na comunicação entre serviços mudou as práticas recomendadas para determinadas tarefas administrativas. Este artigo discute algumas dessas tarefas, como elas são tratadas em um contexto nativo do Kubernetes e como elas podem ser gerenciadas usando service mesh – nesse caso, o Istio.

      Para obter mais informações sobre alguns dos tópicos do Kubernetes abordados aqui, consulte os seguintes recursos:

      Além disso, os hubs de documentação do Kubernetes e do Istio são ótimos lugares para encontrar informações detalhadas sobre os tópicos discutidos aqui.



      Source link

      The Linode Backup Service


      Updated by Linode

      Written by Alex Fornuto

      The Linode Backup Service

      The Linode Backup Service is a subscription service add-on that automatically performs daily, weekly, and biweekly backups of your Linode. It’s affordable, easy to use, and provides peace of mind. This guide explains how to enable and schedule your backups, make a manual backup snapshot, restore from a backup, and disable the Backup Service.

      Pricing

      Pricing is per Linode and varies depending upon your Linode’s plan:

      Standard Plans

      Service Backups Hourly Rate Backups Monthly
      Linode 1GB $0.003/hr $2/mo
      Linode 2GB $0.004/hr $2.50/mo
      Linode 4GB $0.008/hr $5/mo
      Linode 8GB $0.016/hr $10/mo
      Linode 16GB $0.03/hr $20/mo
      Linode 32GB $0.06/hr $40/mo
      Linode 64GB $0.12/hr $80/mo
      Linode 96GB $0.18/hr $120/mo
      Linode 128GB $0.24/hr $160/mo
      Linode 192GB $0.36/hr $240/mo

      High Memory Plans

      Service Backups Hourly Rate Backups Monthly
      Linode 24GB $0.0075/hr $5/mo
      Linode 48GB $0.015/hr $10/mo
      Linode 90GB $0.03/hr $20/mo
      Linode 150GB $0.06/hr $40/mo
      Linode 300GB $0.12/hr $80/mo

      Enable the Backup Service

      Use the Linode Cloud Manager to enable the Backup Service on a Linode. Here’s how:

      1. Log in to the Linode Cloud Manager.

      2. From the Linodes page, select the Linode you want to back up.

      3. Click the Backups tab.

        Enable Linode Backups by navigating to to the individual Linode's backup menu.

      4. Click Enable Backups.

      The Linode Backup Service is now enabled for the selected Linode.

      Auto Enroll New Linodes in the Backup Service

      You can automatically enroll all new Linodes in the Backup Service. To do so, click the Account link in the sidebar, then select the Global Settings tab.

      In the Backup Auto Enrollment panel, click on the switch to enable backups on all new Linodes.

      Auto enroll all new Linodes in the Backup Service by navigating to the Global Settings tab in the Account settings and enabling Backups.

      Note

      Enabling this setting does not retroactively enroll any previously created Linodes in the Backup Service.

      Manage Backups

      You’ll manage your backups with a simple web interface in the Linode Cloud Manager. There’s no software to install, and there are no commands to run. Just log in to the Linode Cloud Manager, navigate to the Linodes page by clicking on the link in the sidebar, select a Linode, and then click the Backups tab. The backups interface is shown below.

      The Linode Backup Service interface

      1. A list of available backups. Listed in this view are the date created, the label, how long the backup took to be created, the disks imaged, and the size of the resulting image.

      2. Manually create a backup by taking a manual snapshot. For more information, see the Take a Manual Snapshot section.

      3. Configure backup schedule settings. For more information, see the Schedule Backups section.

      4. Cancel backups. After cancelling your backups you will have to wait 24 hours before you can re-enable them again.

      How Linode Backups Work

      Backups are stored on a separate system in the same data center as your Linode. The space required to store the backups is not subtracted from your storage space. You can store four backups of your Linode, three of which are automatically generated and rotated:

      • Daily backup: Automatically initiated daily within the backup window you select. Less than 24 hours old.
      • Current week’s backup: Automatically initiated weekly within the backup window, on the day you select. Less than 7 days old.
      • Last week’s backup: Automatically initiated weekly within the backup window, on the day you select. Between 8 and 14 days old.
      • Manual Snapshot: A user-initiated snapshot that stays the same until another snapshot is initiated.

      The daily and weekly backups are automatically erased when a new backup is performed. The Linode Backup Service does not keep automated backups older than 8 – 14 days.

      Schedule Backups

      You can configure when automatic backups are initiated. Here’s how:

      1. From the Linodes page, select the Linode.

      2. Click the Backups tab.

      3. Under Settings, select a time interval from the Time of Day menu. The Linode Backup Service will generate all backups between these hours.

      4. Select a day from the Day of Week menu. This is the day whose backup will be promoted to the weekly slot. The back up will be performed within the time period you specified in step 3.

      5. Click Save Changes.

      The Linode Backup Service will backup your Linode according to the schedule you specified.

      Take a Manual Snapshot

      You can make a manual backup of your Linode by taking a snapshot. Here’s how:

      1. From the Linodes page, select the Linode.

      2. Click the Backups tab.

      3. Under Manual Snapshot, give your snapshot a name and click Take Snapshot.

        Note

        Taking a new snapshot will overwrite a previously saved snapshot.

      The Linode Backup Service initiates the manual snapshot. Creating the manual snapshot can take several minutes, depending on the size of your Linode and the amount of data you have stored on it. Other Linode Cloud Manager jobs for this Linode will not run until the snapshot job has been completed.

      Restore from a Backup

      This section shows how to restore a backup to a new Linode, or to an existing Linode.

      Restoring a backup will create a new configuration profile and a new set of disks on your Linode. The restore process does not restore single files or directories automatically. Restoring particular files can be done by completing a normal restore, copying the files off of the new disks, and then removing the disks afterward.

      Note

      The size of the disk(s) created by the restore process will only be slightly larger than the total size of the files restored. This means that the disk(s) created will be ‘full’.

      Some applications, like databases, need some amount of free unused space inside the disk in order to run. As a result, you may want to increase your disk(s) size after the restore process is completed.

      To restore a backup to a different data center, first restore to a Linode in the same data center, creating a new one if necessary. Once the restore is complete, use the Clone tab to copy the disk(s) to a Linode in a different data center.

      Restore to a New Linode

      This section covers how to restore a backup to a new Linode that does not have any disks deployed to it. The new Linode will be located in the same data center. If you instead wish to restore your backup to an existing Linode, see the next section.

      1. From the Linodes page, select the Linode whose backups you intend to restore, and then click on the Backups tab. Select the more options ellipsis next to the backup you would like to restore, and click Deploy New Linode.

        Click on the ellipsis menu icon to restore to a new Linode.

      2. You will be taken to the Create New Linode screen. The Create from Backup tab will already be selected for you, as will the fields corresponding to the Linode and backup that you are restoring from. Choose a Linode plan, enter a label for the new Linode, select any other options you prefer, and click Create. The new Linode will be created with the same password and SSH keys (if any) as the original.

        The backup disks and configuration profiles will be restored to the Linode you selected. Watch the notifications area for updates on the process. Restoring from a backup can take several minutes depending on the size of your Linode and the amount of data you have stored on it.

      Restore to an Existing Linode

      You can restore a backup to any Linode located in the same data center, even if the target does not have the Backup Service enabled. To restore a backup to an existing Linode, you will need to make sure that you have enough storage space that is not currently assigned to disk images.

      Note

      If you are attempting to restore a disk to the same Linode the backup was created from, the restoration process will not delete the original disk for you. Manually delete the original disk to make room for the backup, if desired.

      1. From the Linodes page, select the Linode whose backups you intend to restore, and then click on the Backups tab. Observe the size of the backup you would like to restore, which is visible in the Space Required column. You will need at least this amount of unallocated disk space on the target Linode to complete the restore.

      2. Select the more options ellipsis next to the backup you would like to restore, and click Restore to Existing Linode.

        Click on the ellipsis menu icon to restore to an existing Linode.

      3. A menu will open with the Linodes that you can restore to. Select a Linode and click Restore.

        Select the Linode you would like to restore your backup to.

        You will be notified if you do not have enough space on your Linode to restore your backup. Optionally, you can choose to overwrite the Linode you are restoring to.

      4. If the amount of unallocated space available is greater than the size of the backup, you can proceed with restoring. If the amount of unallocated space is less than the size of the backup, you can stop the restoration workflow, resize your existing disks on the target Linode to make room for it, and then come back to the restore page after the disk resize operation has finished.

        Note

        In some cases, you will not be able to shrink your disks enough to fit the restored backup. As an alternative, you can change your Linode’s plan to a higher tier that offers more disk space.
      5. From the Restore to Existing Linode menu, click Restore.

        Your backup will begin restoring to your Linode, and you can monitor its progress in the notifications area. Note that the time it takes to restore your backup will vary depending upon the restore size, and the number of files being restored.

      Boot from a Backup

      After the backup has been restored, the disks and configuration profiles will be available to the destination Linode you selected. Select the restored configuration profile and reboot your Linode to start up from the restored disks:

      1. From the Linodes page, select the Linode that you restored the backup to. Navigate to the Settings tab and open the Advanced Configurations panel.

      2. Select the more options ellipsis next to the configuration profile that was restored and select Boot This Config.

        Navigate to the Advanced Configurations section of your Linode's Settings tab.

      The Linode will start from the backup disks. Monitor the notifications area for progress.

      Cancel the Backup Service

      You can cancel the Backup Service at any time. From your Linode’s details page, choose the Backups tab and click the Cancel Backups link at the bottom of the page. Cancelling the service will remove your saved backups from the Linode platform.

      Limitations

      There are some limitations to what the Linode Backup Service can back up. Here are some things you should be aware of:

      • The Backup Service must be able to mount your disks. If you’ve created partitions, configured full disk encryption, or made other changes that prevent us from mounting the disk as a filesystem, you will likely not be able to use the Linode Backup Service. The backup system operates at the file level, not at the block level.
      • Because the Backup Service is file-based, the number of files stored on disk will impact both the time it takes for backups and restores to complete, and your ability to successfully take and restore backups. Customers who need to permanently store a large number of files may want to archive bundles of smaller files into a single file, or consider other backup services.

        Note

        The percentage of customers who may run into this limitation is low. If you are not sure if this limitation applies to you, please contact Linode Support.
      • Backups taken of ext4 or ext3 filesystems will be restored as ext4. Backups taken of other mountable filesystem types will have their contents restored using ext4.

      • Files that have been modified but have the same size and modify time will not be considered “changed” during a subsequent backup. ACLs and extended attributes are not tracked.

      • The Backup Service uses a snapshot of your disks to take consistent backups while your Linode is running. This method is very reliable, but can fail to properly back up the data files for database services like MySQL. If the snapshot occurs during a transaction, the database’s files may be backed up in an unclean state. We recommend scheduling routine dumps of your database to a file on the filesystem. The resulting file will then be backed up, allowing you to restore the contents of the database if you need to restore from a backup.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.



      Source link