Mostrando postagens com marcador Backup. Mostrar todas as postagens
Mostrando postagens com marcador Backup. Mostrar todas as postagens

terça-feira, 24 de janeiro de 2023

Tutorial e Dica: FreeFileSync para MacOS

Pessoal,


Resolvi aqui a melhor forma para fazer os meus backups. Conheçam o FreeFileSync (daqui pra frente FFS para facilitar).

Recapitulando: eu costumava usar CarbonCopyCloner para fazer meus backups. Usei por anos. Até que inventei de comprar um Synology e descobri que, uma vez que ele usa uma formatação diferente de disco, o CCC não funcionará direito lá. As permissões dos arquivos ficam inoperantes e o CCC refaz o backup a cada gravação. O problema é que tenho uma pasta de mídias com mais de 01TB de dados. Se ele ficar regravando isso toda vez, vai estragar os HD (o de leitura e o de gravação) e perde completamente o propósito da coisa.

Assim, tive que procurar outras soluções.

Achei o ChronoSync, que faz tipo o que o CCC faz, funciona para o NAS. Só que é pago.

O Synology tem duas opções: Hyper Backup e Active Backup for Business. O primeiro copia todo o MacMini para o Synology. É ótimo, mas não é o que eu quero fazer, uma vez que não permite escolher pasta a pasta. É meio tudo ou nada. O segundo é mais ou menos a mesma coisa.

Procurei vários e vários programas mas só encontrei um que resolveu: o FreeFileSync.

Ele permite escolher pastas ou discos, faz a sincronização das pastas ou o backup incremental e é de graça.

Para criar uma tarefa é bem simples: clique em Novo, arraste ou digite o endereço de origem (lado esquerdo) e arraste ou digite o endereço do destino (lado direito).


Clicando na "roda dentatda" azul você escolhe como que comparar os arquivos da origem e do destino (por data e tamanho, por conteúdo ou apenas pelo tamanho) e na "roda dentada" verde você escolher o que fazer na cópia (coloca todas as modificações dos dois lados em ambos os lodos, espelha um lado no outro, só atualiza - esse é o 'incremental' - ou personaliza o que quer fazer). Existe ainda um filtro onde é possivel excluir alguns arquivos e pastas do backup.


Após isso, basta salvar e dar o nome que quiser para a sua tarefa de backup.


Se você reparar bem, há três opções para salvar: "Salvar" e duas de "Salvar Como". A primeira não tem dúvidas e o programa grava com um nome padrão. As outras duas permitem a escolha do nome. Só que a opção da esquerda salva apenas a configuração do seu backup. Já a da direita salva um arquivo em lote (batch, se estivessemos no Windows seria .bat) que será utilizada para criar o agendamento do backup. Explico mais a frente.


Após isso, clique em "Sincronizar" e ele começará as cópias (apesar de estar escrito "sincronizar", o programa fará o que você escolheu na "roda dentada" verde). Aí é deixar o backup ser feito, às vezes demorando algumas horas...


O interessante vem para fazer o agendamenteo dos backups. A primeira coisa é criar uma tarefa em lote, um "batch". Para isso selecione uma tarefa que você já tinha salvado antes e, após clicar nela, salve como "Tarefas em Lote", clicando no icone do disquete com caixa de DOS (eita coisa véia...).


Marque as opções como aparecem acima. Se você usa Windows, precisará criar uma tarefa como o Windows Task Scheduler (veja como fazer isso aqui). Para o MacOS, usaremos o Automator. Abra ele em Aplicativos ou procure por ele no Spotlight ou Launchpad.


Escolha "Novo Documento" e, na tela que se abrirá, escolha "Alarme do Calendário":


Agora você precisa ir na pasta onde salvou o arquivo batch (a pasta "Documentos" é o padrão de salvamento, caso você não tenha escolhido nenhuma; eu escolhi "Documentos -> FreeFileSync", para deixar mais organizado). Agora, arraste o arquivo como o final "ffs_batch", ou seja, o arquivo batch para o Automator:


No Automator, clique na opção "Arquivos e Pastas" em Bibliotecas e depois arraste a opção "Abrir Ítens do Finder" para o seu workflow.


E agora salve em "Arquivo -> Salvar...". Assim que salvar, o aplicativo "Caelendário" irá abrir automaticamente. Clique na tarefa que você criou e escolha o dia, hora e frequência de backups.


Pronto! Simples, efetivo e de graça!

Vamos agora procurar outro problema para resolver!

Por enquanto é isso, pessoal!

quarta-feira, 11 de janeiro de 2023

Tutorial: Instalando o Duplicati pelo Docker no Synology.

Pessoal,


Spoiler: Deu certo, mas deu errado... Leia o post e no final você entenderá :(

Dando continuidade ao post anterior onde falei dos problemas que tive com o Carbon Copy Cloner para backupear o Mac para o Synology e comecei a usar o ChronoSync.

Como disse, o ChronoSync custa U$50,00. Tá fácil não. Assim, optei por tentar com o Duplicati.

O Duplicati tem opção para instalar no Mac (e vários outros SOs, veja as opções aqui) e tem opção de instalar pelo Docker no Synology (e no Mac também, mas não tenho Docker no Mac). Faz backup incremental e é gratuito. Confira a página deles no GitHub (aqui) também! Pelo GitHub também é possível fazer o download para as várias plataformas (veja aqui a última versão, a v2.0.6.104, até a data de publicação deste post).

A idéia é instalar a versão de MacOS para evitar ter que mapear um HD externo que está no Mac através do Synology. Sei que isso vai dar um bom trabalho e prefiro evitar, indo direto para o Mac "empurrando" os arquivos para o Synology do que o Synology "puxando" os arquivos do Mac.

A instalação do Duplicati no Mac não está tão fácil. Parece que há um problema após a atualização do Mac para Monterey e o Duplicati está sofrendo para funcionar. Na verdade funciona, mas dá um trabalhinho para aparecer.

O macete (passado aqui no fórum do Duplicati) é instalar a última versão do Duplicati e ir neste site do GitHub e baixar o arquivo "net.duplicati.server.plist" e colocá-lo em uma pasta específica. Para baixar, clique em "Download ZIP", depois descompacte a pasta (terá dois arquivos) e depois copie para a outra pasta:


Agora, vá ao Finder -> Downloads e descompacte o ZIP baixado. Copie o arquivo com Command + C.

Para a pasta de destino, deixe a tela do Finder ativa (clique nela apenas) e pressione junto as teclas "Shift + Command + "." "(Shift + Command + "ponto"). Os arquivos e pastas ocultos irão aparecer.


Agora navegue até a pasta "Biblioteca -> LaunchAgents" e coloque o arquivo copiado lá. Depois volte para outra pasta (como Downloads e pressione Shift + Command + "ponto" para esconder de novo as pastas e arquivos e evitar de fazer merda...


Se você fez tudo certo, vai digitar esse endereço no navegador e vai abrir o Duplicati rodando no seu Mac: "127.0.0.1:8200/ngax/index.html#". Esse é o famoso "localhost", ou seja, o serviço está hospedado localmente no sua máquina. Depois, quando instalarmos o Duplicati no Docker no Synology, ele será acessado pelo endereço "<IP-do-seu-servidor>:8200/ngax/index.html#".

Na página de login ("First run setup") eu escolhi a opção de não colocar senha, uma vez que tem apenas um usuário. Eu, no caso.

Agora crie um backup:


Escolha o nome do backup e a criptografia (eu escolhi sem criptografia para este backup):


No próximo passo, você escolhe o local de destino. Pode ser local, em vários serviços de nuvem (Box, Dropbox, Google Drive, etc) ou no seu servidor local. Eu vou "roubar" e fazer do jeito fácil. Escolha "Pasta ou Unidade Local". Vai aparecer uma opção para navegar nos diretórios e uma para exibir pastas ocultas. Escolha essa, uma vez que, no nosso caso, a pasta destino é remota. Assim, navegue até a pasta "Volumes" e depois até "Livros"(que eu já havia criado no Synology). Depois clique em "Testar Conexão" e deve aparecer "Conexão estabelecida!".


Agora vamos configurar a pasta de origem. É só navegar. No meu caso, como a pasta também é remota (está num HD externo), é só clicar em "Exibir pastas ocultas" e navegar até a origem. Ao final, clique em próximo.


O próximo passo é agendar a tarefa e definir se você quer apagar ou não os arquivos. Eu prefiro não apagar. Salve e siga em frente para executar!


Funcionou perfeito! Só que...

Descobri que o Duplicati entende que essa função de copiar para outra pasta é "sincronização" e ele não faz isso. Segundo os autores (só vi depois dessa trabalheira toda), o Duplicati compacta e criptografa os arquivos por razões como "segurança, espaço e eficiência".

Ok, mas não é o que estou procurando. Nem vou instalar no Synology. Continuo na luta.

É isso, pessoal!

Dica: Fazendo o Backup do Mac para o Synology do jeito certo!

Pessoal,


Fui começar a fazer o backup para o Synology e descobri uma coisa interessante.

Percebi que algo estava errado quando o backup ficava repetindo eternamente. Melhor dizendo, cada backup era um novo backup, o Carbon Copy Cloner, por algum motivo, não estava fazendo o backup incremental mas estava começando um backup novo a cada vez que era solicitado. A cada novo processo de backup, os horários e datas eram atualizados no destino. Obviamente algo estava errado.

Isso tem várias problemas: dano aos discos de leitura e gravação, perda de tempo, gasto de energia, não garantia do backup efetuado. Ou seja, fria!

Assim, fui olhar as configurações do CCC e não encontrei nada para mudar. Quer dizer, mudei várias coisas, quase todas as configurações, mas o problema persisitiu.

Fui procurar nos fóruns e não achei nenhum relato desse tipo.

Achei estranho porque no NAS anterior, o OMV, isso funcionava bem. Talvez pelo modo de montagem dos discos (lá estava tudo dentro de um disco virtual no Proxmox, no Synology os discos são "reais", sei lá).

Procurei então direto na fonte, na documentação no site do CCC. E lá está escrito (veja aqui) que sistemas de arquivos que não sejam os do padrão MacOS (APFS e HFS+) podem não funcionar bem no CCC, uma vez que o software é exclusivo para MacOS. Ainda, há problemas com propriedades e permissões. O DSM, na versão 7, formata os discos em EXT4 ou BTRFS.

A forma como tanto o TrueNAS e o OMV tratam com as permissões dos usuários também é diferente no DSM.

Assim, a conclusão que cheguei é que o CCC, pelo menos a versão que eu tenho, não permite fazer backup adequadamente no Synology...

Solução? Procurar outro software para isso.

O meu backup é simples: escolho uma pasta de origem no HD externo (formatado em HFS+) e envio para uma pasta com o mesmo nome no Synalogy. Claro que o primeiro backup é super demorado, mas os próximos são rápidos porque o software analisa se o arquivo já existe e, caso positivo, não grava e vai para o próximo. Isso é backup incremental.

Então fui procurar outro software. Não encontrei nenhum no Synology que fizesse isso :( Devo ter tentado uns 10 programas no Mac e só um resolveu o meu problema. Vários faziam backup para cloud services ou imagem de disco e nada disso era o que eu precisava.

Achei um, open source, que faz (quase) tudo que eu preciso: FreeFileSync. A cópia é bem rápida, você escolhe as pastas de origem e destino, criptografa se quise, tem opção para sincronizar e apenas copiar o que for novo da pasta origem na destino (e nesse caso você pode optar por apagar o que estiver diferente na pasta de destino ou manter os arquivos), etc.

O FileFreeSync tem dois problemas. O primeiro, irrelevante, mas típico de várias ferramentas opensource do mundo Linux: é feio pra caramba!


Esse é um problema de menos. Tolero a feiura dele porque ele é extremamente competente no que faz.

O segundo problema é o complicado: não tem função para agendar as sincronizações / backups... :(   Aí é de lascar! Quer dizer, tem. Mas é complicado. Usa o Automator e o calendário.

Só o ChronoSync resolveu o problema. Ele faz o backup bem parecido com o CCC, permitindo escolher as pastas de origem e destino e agendar os backups. E o melhor, sem dar o problema com as permissões que o CCC estava dando.

Ainda vou testar mais uma: Duplicati, via Docker, porque o ChronoSync custa 50 Bidens, uns 250 a 300 petralhas, na conversão atual. É pouco não...  Mas essa vai para o próximo post.

Vou tentar o FreeFileSync novamente com esse agendamento. Afinal de contas, a concorrência tá pedindo 50 doletas...

Por enquanto é isso!

terça-feira, 18 de janeiro de 2022

Erro total no OMV - Perdi todos os meus backups?

 Pessoal,

O caos se instalou aqui no meu NAS.


Os HDs, TODOS ELES! estão dando pau!!


Os discos sumiram do OMV, apesar de fisicamente conectados.

Num momento de desespero, eu já estava começando a pensar se valia a pena retornar para o TrueNAS, arriscar o XPEnology ou tentar o UnRaid. Dando uma procurada (veja aqui um resumo dos principais sistemas para NAS), até fiquei conhecendo o XigmaNAS (antigo NAS4Free, um fork do FreeNAS).

Até cheguei a começar esse post falando que iria apagar o OMV para nunca mais usar e por aí vai.

Antes de surtar completamente fui dar uma olhada mais cuidadosa nos discos e notei que o disco defeituoso que havia comentado anteriormente neste post estava conectado ao computador... Acho que fui tentar ver se realmente tinha dado pau e esqueci de desconectar. 😒

Ou seja, a porcaria ficou conectada e começou a travar todo o acesso do Proxmox, OMV e cópias. Foi só desconectar o maldito HD, desligar as VMs, reiniciar o PVE e as VMs e pronto, tudo voltou ao normal!

quinta-feira, 13 de janeiro de 2022

Disco com erro no OMV5 / Proxmox

 Pessoal,

Há alguns dias comecei a ter problemas com os backups pelo CCC. Comecei a receber a seguinte mensagem de erro:


Fui dar uma procurada no Google e encontrei que pode ser que o CCC não conseguiu certificar-se que o disco utilizado para destino (JBC-NAS) é o mesmo disco que eu já estava usando para fazer backup. Mas pode ser, na pior das hipóteses, erro no disco de destino (o JBC-NAS, no caso).

Fiz as alterações sugeridas pelo criador do CCC (veja aqui) e... nada.

Outro erro que também aparece é esse aqui:


Agora erro com permissões. Todos esses erros relacionados no mesmo disco, esse JBC-NAS.

Às vezes acontece do nó inteiro cair:


Enfim, algo de ruim está acontecendo. E a impressão que eu tenho é que esse disco está zebrado.

Esse é um WD My Passport de 04TB. Ele estava em RAID 1 com um Samsung de 04TB quando eu usava o TrueNAS. O TrueNAS falava que um dos discos do array estava com problema e eu, não me lembro porque, achei que era o Samsung (que é bem mais velho que esse WD).

Enfim, esse problema está acontecendo há alguns dias. Aí fui tentar alterar as permissões no OMV e começou a aparecer esse erro aqui:


A causa? Erro no JBC-NAS. Repare nesse erro aí: "A estrutura necessita de limpeza chown".

E agora, com a última travada, liguei o server no monitor e apareceu isso aqui para justificar o travamento do Proxmox:


Confirmado: erro no dev/sde. Esse sede é o JBC-NAS.

Vou ter que substituir esse disco pelo Samsung 04TB e refazer os backups que vão para ele (e o CCC provavelmente vai substituir os backups que saem dele) :-/

Pelo Shell do PVE, tentei rebootar o sistema, mas travou bonito nessa tela aí de cima. Tirei o disco do Server e aí ele conseguiu reiniciar. Engasgou um pouco no começo mas foi em frente. E aí apareceu isso:


Repare que o WD-Pass-04TB (o nosso dev/sde ou JBC-NAS) está interrogado e o S-04TB (o Samsung) também está. O primeiro porque o PVE não encontrou (claro, está desconectado). O segundo porque o PVC não sabe que disco é esse. Vamos formatar e iniciar esse disco e ver o que fazer.

* Aprender a fazer a limonada com os limões que a vida dá pra gente: se realmente der pau nesse disco, vou aproveitar que irei refazer os backups e vou separar as pastas dos arquivos de mídia (filmes, séries, programas de TV, etc) para organizar o Bazarr, o Sonarr e o Radarr, além do Plex.

Bom, tentei reiniciar o OMV e deu esse erro aqui:


Então fiz o seguinte: recoloquei o disco e reiniciei o OMV. Aí vou tirar esse disco. Outra coisa interessante que reparei: esse disco nunca é montado automaticamente no OMV...


Os outros são todos montados automaticamente. Não sei o porque, mas deve ser consequência de algum erro que ele já descobriu e ainda não tinha me contado 😂😂

Bom, antes de apelar para apagar o disco, vou tentar uma última coisa: repara o disco com o fsck usando esses comandos aqui:

Sudo umount /dev/sdd1

Sudo fsck.ext4 /dev/sdd1

Eu sei que é /dev/sdd1 porque o OMV mostrou isso pra mim, veja a figura acima. O fsck vai sugerir algumas correções. Aceitei todas até porque a outra opção é persistir com o erro e o erro não tá deixando o negócio funcionar.



Após vários minutos e centenas de erros, remontei o disco no OMV e fui direto para tentar o backup no CCC, uma vez que o principal objetivo do meu NAS é esse. Ao final do backup do CCC, os erros continuaram :(

Esses erros começaram após uma tentativa de apagar uns arquivos nesse disco que deu um monte de erro. Estava considerando um erro "lógico" e não "físico", só que o histórico desse HD não é dos melhores (lembram dos erros no TrueNAS?). Vou ter que trocar o disco mesmo :(

Colocar o disco no OMV já foi falado aqui e aqui. Nada de novo nessa parte.

Agora é refazer os backups para esse disco novo. 😫😫😫

terça-feira, 7 de setembro de 2021

Proxmox - Instalando discos externos via USB

Pessoal,

No último post, falei sobre a instalação do Proxmox e a criação de uma VM onde rodam algumas coisas fundamentais, "estruturais",  como atualização do IP e VPN.

Agora o passo é incluir os discos externos (um de 8TB e dois de 4TB para rodarem como RAID 1 (veja aqui e aqui o que significa RAID e quais os tipos disponíveis). Ainda tenho um outro HD de 4TB rodando "por fora", onde o MacMini faz alguns backups e um outro de 3TB só para rodar o TimeMachine.

Bom, a minha primeira dúvida era se os discos deveriam estar disponíveis apenas para a VM do TrueNAS ou se deveriam estar no Proxmox e a VM utilizar esse pool criado. Acho que essa segunda opção é a melhor. Acho, de achar mesmo.

Bom, vamos lá.



Dentro de "Datacenter -> pve" vá em Disks. Repare que vários discos aparecem. O /dev/sda é o disco onde está instalado o Proxmox. É como se fosse o disco "c:" do Windows. Os discos /dev/sdb (4TB), /dev/sdc (8TB) e o /dev/sdd (4TB) farão parte do pool para backup do TrueNAS. O último disco, o /dev/sde, de 3TB, será o disco só para TimeMachine.

Dentro de "Datacenter -> pve -> Disks -> LVM", aparecerá apenas o /sda, ou seja, os outros discos estão conectados mas não estão acessíveis. Para isso é necessário ir ao Shell e formatar e montar esses discos com:

    # fdisk /dev/sdb (para escolher o disco)

    # d (para deletar a partição; dentro desta opção, você poderá escolher a partição que será deletada)

    # w (para escrever a ordem, ou seja, deletar a partição)

Após fazer isso com todas as partições / discos escolhidos, os discos ainda não estarão disponíveis. Para isso, ainda no Shell, faça o seguinte (para cada disco):

    # mkfs.ext4 /dev/sdb (para criar a partição em formato ext4)

Se você não sabe o que é o formato ext4, recomendo que assista dois vídeos muito bons, esse primeiro e esse depois. São longos, mas contam, bem explicados, sobre os tipos de formatos para formatação de discos, vantagens e desvantagens. Recomento muitíssimo. Aqui, do Wikipedia, também explica bem esses tipos de formatos.

Tome cuidado apenas para não apagar o disco /dev/sda, uma vez que ele é o disco onde está instalado o Proxmox.

Agora os discos estão assim no Proxmox:


Estranhamente, o disco /dev/sdb não aparecia de jeito nenhum para ser adicionado em diretórios. Assim, fiz uma coisa "bruta": criei partição em todos eles e depois apaguei a partição. Aí, tão estranhamente, ele (e todos os outros) estavam disponíveis para trabalhar.

Repare que os discos estão sem partição. Para resolver isso, volte ao Shell e entre no fdisk novamente, agora escolhendo "g" para criar uma tabela de partição GPT (veja mais aqui), depois "n" para criar uma partição e por fim "w" para gravar e sair do fdisk.

Agora ficará assim:


Agora o Proxmox consegue enxergar e montar todos os discos.

Para apagar as partições, volte ao fdisk (escolhendo o disco que você vai apagar a partição), escolha "d" para deletar a partição e "w" gravar e sair.

No próximo post, vou mostrar como instalar o TrueNAS, adicionar os discos para criar os storages e configurar o TrueNAS.

sexta-feira, 2 de abril de 2021

Novo NAS - Open Media Vault

Pessoal,

Já contei em vários posts aqui do blog sobre o NAS que eu fiz utilizando o FreeNAS (aqui sobre o próprio OpenMediaVault - OMV - quando fiz um teste no RP3, aqui quando fiz um dual boot no MacWhite para instalar o Ubuntu Server e instalar o NextCloud via Docker, aqui sobre a tentativa frustrada de abrir o roteador para acessar a minha rede fora de casa, aqui sobre a VPN com o OpenVPN e NoIP - solução que vou manter no OMV também -, aqui onde falo das minhas impressões sobre o OMV, XPEnology e FreeNAS e porque tinha decidido a usar o FreeNAS e, por último, aqui onde falo do FreeNAS e utilização para PlexServer e backup - incluindo o TimeMachine).

O FreeNAS é derivado do FreeBSD e o OMV é derivado do Debian (Linux). Ambos são derivados do Unix, mas cada um com uma proposta um pouco diferente. O BSD (que origina o FreeBSD) é a base, inclusive, para o MacOS (sim, o MacOS é derivado do BSD e, assim, do Unix! Linux e MacOS são, de certo modo, primos!).

Quando tinha optado pelo FreeNAS, eu vi e gostei muito da forma de instalar "plugins" nele, pelos Jails. Eu não sabia, todavia, que o OMV também tinha essa opção (OMV Extras). Pelo que percebi, o FreeNAS é um pouco mais complexo devido aos jails, que tem um sistema de permissões mais complexos. O OMV, ao contrário, parece ser um pouco mais flexível.

Como exemplo, não adianta simplesmente instalar um jail do NextCloud ou instalar o Docker no FreeNAS e instalar o NextCloud nele. Para acessar o pool de arquivos, é uma luta. Parece (digo parece porque ainda não instalei isso no OMV) que o sistema de instalação e compartilhamento no OMV é bem mais simples.

Outra coisa que havia me direcionado ao FreeNAS era o suporte à VM. O problema é que o FreeNAS usa toda a RAM que eu coloquei como cache. PQP! Haja RAM! Assim, as VM ficam leeeennnntttttaaaaassss! Inutiliza toda a ideia do negócio. Óbvio que tem solução: colocar um SSD para cache, por exemplo, mas não vou gastar nada com isso.

Aí vi que o o OMV tem suporte a VM também, utilizando o Virtual Box. Acho que aí eu resolvo minha questão com VM.

Além disso, outras coisas motivaram essa troca toda.

Uma delas foi a esdrúxula decisão do Yahoo de acabar com o Auto Forward de mail. Uma das medidas mais antipáticas que já vi. Lá pelos idos 1997, quando a internet começou a chegar no Brasil, eu ainda estava na Faculdade de Medicina da UFMG. Na época, criaram o Centro de Informática Médica na faculdade e disponibilizaram emails para os alunos. Eu tinha um e era bem simples (como toda a internet da época). Aí apareceram o Yahoo Mail (fiz dois, um .com.br e um .com), o HotMail (também fiz um, antes de ser comprado pela Microsoft) e na iG (lembram dela?).

Pois bem, quando saí da faculdade, o acesso ao email da FM-UFMG foi cancelado. Comecei a usar o iG como meu email principal. Depois, mudei para o yahoo.com.br. Quando o Gmail surgiu, a interface dele era melhor e comecei a utilizar o Auto Forward do Yahoo para o Gmail, que acabou sendo a minha interface de email, apesar de receber e responder como yahoo.com.br.

A questão passou a complicar no começo de 2021, quando o Yahoo acabou com o auto forward para as contas gratuitas, alegando que não havia segurança, mas manteve para as contas pagas. Peraí! Não é seguro para conta gratuita mas é seguro para conta paga? PQP! Arranja outra desculpa melhor, né?

Como vários serviços e sites que eu acesso estavam cadastrados com o email Yahoo, fui mudando, ao longo de alguns meses para o Gmail. Atualmente só utilizo o Yahoo para o NoIP e a Apple.

Assim, aproveitei toda essa mudança e vou trocar o serviço do NoIP do Yahoo para Gmail. Só que isso vai resultar na reconfiguração do serviço de DNS dinâmico que preciso para o OpenVPN.

Enfim, dadas as devidas explicações, confirmei que todos os meus arquivos backupados no FreeNAS estão nos meus HD externos e mandei ver na troca do FreeNAS pelo OMV.

Além disso, aproveitei um HD de 500GB parado aqui para colocar no servidor. Assim, ele vai ter um HD de 500GB para rodar o OMV (mais que necessário), além de um de 1TB que já está nele e mais alguns externos para fazer o serviço de Storage.

A instalação é super simples. Após baixar a imagem estável no site deles (eles direcionam para o SourceForge, aqui), basta seguir as instruções na tela. Ja mostrei a instalação no primeiro post da série "Em busca do NAS doméstico (quase) gratuito!". Lá eu tinha mostrado como fazer no RP3 com o RaspOS instalado. Hoje fiz diferente: gravei a ISO baixada num pendrive bootável, desconectei os HDDs do servidor, coloquei o pendrive e reiniciei a máquina. Na hora de escolher onde gravar o OMV, formatei o HD interno da máquina e gravei nele. O resto é só seguir as instruções.

Duas coisas importantes: primeiro, reserve um IP fixo para o server, ajuda muito. Já falei disso aqui e vale sempre recomendar a leitura. Segundo, escolha uma boa senha.

Após instalar e trocar a senha, vá em Sistemas -> Update Management e atualize tudo que houver para ser atualizado.


O OMV, ao contrário do FreeNAS, não tem uma opção para acessar o Shell. E, ao contrário do RP, onde podemos instalar como um programa no RaspOS e acessar o Shell via VNC, o OMV não tem suporte para VNC (não ainda e não o VNC). Assim, ou você precisará de um monitor e um teclado para digitar algumas linhas de comando ou você pode utilizar o SSH. Por padrão, o SSH já está habilitado no OMV e você acessa digitando:

        ssh <usuário>@<endereço do OMV> <enter>

No meu caso, é:

        ssh root@192.168.1.2 <enter>

Usuários do Windows precisam, se não me engano, acessar pelo Putty.

Uma vez dentro do Shell do OMV, instale os "extras" com a seguinte linha de comando:

     wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

Esses extras é que contêm a parte divertida: Docker, Transmission, PlexServer, Vitual Box, etc. Mas vamos falar disso mais pra frente.

Agora vamos preparar os discos para Storage.

Uma das grandes vantagens do FreeNAS e do OMV é aceitarem, nativamente, discos via USB (o XPEnology não aceita nativamente).

Após conectar o disco, vá em File System (ou Sistema de Ficheiros). Veja que o disco que você acabou de conectar NÃO está lá.


O disco, para aparecer, precisa ser "criado". Assim, quando você escolher Criar, aparecerá uma pequena tela que mostrará o disco conectado:


Escolha o disco, crie o nome e formate em EXT4. Como tenho dois discos para backup, ficará assim: o disco do OMV será sda, o primeiro backup será sdb e o terceiro será sdc. Esse é um processo um pouco demorado, a depender do tamanho do disco. Tudo que está nos discos será apagado!

Um detalhe: se a ideia é fazer algum RAID com discos externos, esqueça! O OMV, ao contrário do FreeNAS, não permite!


Não é um grande problema, pelo menos não inicialmente. Posso colocar esses dois discos (ambos de 4TB) para gravarem sequencialmente, mais pra frente comprar um de 8TB para fazer isso também ou, também mais pra frente, comprar uma gaveta e colocar dois discos lá dentro do server. A ver.

Após a criação e formatação dos discos, vamos montá-los no sistemas. Tentei formatar os dois ao mesmo tempo, mas eles estavam sendo persistentemente excluídos. Assim, tirei os dois do computador, liguei um, formatei e montei, depois fiz a mesma coisa com o outro. Aí deu certo. Vejam:


São esses dois, BKP01 e BKP02.

O próximo passo é criar um usuário para acessar os discos e pastas para esses acessos compartilhados na rede.

Assim, vá em em "Gestão de Direitos de Acesso" --> "Utilizador" e crie quantos usuários forem necessários. Aqui eu criei alguns: um para mim e outro para a patroa (cada um terá uma pasta para fazer backup de seus arquivos); um para o Plex (onde vou colocar as mídias), outro para o Transmission. Se precisar, pode-se incluir ou excluir usuários.

Depois, vá em "SMB/CFS" --> "Definições" e ative o SMB em "Ativo" e então vá em "Partilhas" para criar a(s) pasta(s).

Aqui tem um ponto importante: qual o grau de acesso que você quer dar a quem tem acesso a sua rede? Eu escolhi a opção onde o administrador e os usuários cadastro leem e escrevem e os usuários não cadastrados podem apenas ler. Isso vai de acordo com seu interesse.


Se você descer mais as opções, poderá ativar a opção "Time Machine Support" para permitir que o Mac faça o Time Machine. Para isso, optei por criar uma pasta "Time Machine" no outro disco (BKP02).



Para acessar este disco, será pedido um login e senha - é o nome do usuário e senha que você cadastrou!

O próximo passo agora é configurar os backups. Como já fazia tudo pelo Carbon Copy Cloner, é só organizar o destino e mandar começar os backups.

Agora o TimeMachine está rodando e os backups também. E isso vai demorar algumas horas.

Se tudo ficar certinho, vai sair um próximo post para instalar o PlexServer, o Transmission, o OpenVPN e o Virtual Box.

Até o próximo!

sábado, 3 de outubro de 2020

NAS Doméstico - FreeNAS

 Pessoal,

Só para atualizar aqui o NAS.

Backup:

Coloquei o Carbon Copy Cloner para fazer os backups para o NAS. Foi a maneira que encontrei mais fácil de efetuar os backups. Interessante que enquanto usava o WD MyCloud com destino de backup, diversos erros ocorriam. Com o NAS, o processo AGORA está liso!

Disse "AGORA" porque o primeiro backup completo foi dureza. Depois de algum tempo, o sistema ficava offline, o disco do NAS sumia da rede e o backup não era concluído. Gastei uns dois dias para cada backup que fazia. Depois disso, não tive mais erros com o backup.

Mídias:

Instalei o PlexMediaServer como plugin do NAS. É meio chato: criei um usuário "PlexMedia", montado em /mnt/JBCNAS/iocage/jails/PlexMediaServer/root/media/plex. Dentro de Jails, no menu inicial do NAS, direcionei uma subpasta dentro da minha pasta de mídias no pool para uma subpasta do PlexMediaServer:


Depois instalei o aplicativo do Plex no celular, iPad, AppleTV e TV. Pronto: todos eles encontraram o servidor na rede local e começaram a passar as mídias.

Repararam que eu disse "rede local"? Para "streamar" para a internet, o Plex exige que você seja assinante do PlexPass. Se você, assim como eu, tiver uma VPN (veja aqui), basta entrar na VPN e acessar o Plex "localmente)!

Usei principalmente esse vídeo aqui como guia para instalar o PlexMediaServer.

Time Machine:

Estou utilizando o NAS para fazer backup via Time Machine também. Dentro do meu pool, criei um dataset com o nome Time Machine e compartilhei na rede como SMB. Até tentei compartilhar com AFP (Apple File Protocol), mas não conseguia conectar os Macs nele. Com SMB, foi sem problema e vou deixar assim porque está funcionando e está bom (é como diz o velho ditado: "o ótimo é inimigo do bom")!

Próximos passos: instalar o NextCloud no NAS, ver se vou manter o PiVPN no RP ou se ele vai para o NAS e instalar o PiHole no RP. Outra possibilidade é instalar o Ubuntu Server em uma VM no NAS e rodar o PiHole e PiVPN nesta VM, além do aplicativo do NoIP!

Atualização:

Acabei de descobrir que o meu PC véio não tem suporte para criação de VM. Assim, como já tenho o RP rodando o PiVPN e o aplicativo do NoIP (expliquei tudo isso aqui, lá no meio do post; leiam que vale a pena), vou colocar o PiHole no RP também. Explicarei isso no próximo post.

É isso por enquanto.

domingo, 30 de agosto de 2020

Em busca do NAS doméstico (quase) gratuito! - Parte 5 - VPN

Pessoal,

Vou dar continuidade ao desenvolvimento do meu NAS doméstico (quase) gratuito.

Um ponto que sempre pegou para mim, como já coloquei em posts anteriores, é a necessidade de acessar os dados do meu NAS (e consequentemente da minha rede doméstica) de fora de casa.

Ora, ter os dados apenas dentro de casa não resolve muito. Um NAS que se prese tem que não apenas gerenciar o armazenamento de dados mas também permitir seu acesso no momento oportuno.

Então, como diria Jack, vamos por partes: primeira, obter um acesso externo de um modo seguro à minha rede local; segundo, resolver um NAS que atenda as necessidades de confiabilidade e acesso tanto por computador quanto por dispositivo móvel.

Acesso a rede doméstica

Como falei aqui, descobri a duras penas que eu tinha um grande problema com os roteadores.

O roteador da NET estava habilitado a toda e gerava um IP por DHCP para o Google Wifi que gerava os IPs também por DHCP para os equipamentos na rede local. Ou seja, abrir uma porta para um IP local seria, além de difícil, arriscado. Para abrir uma porta, teria que abrir primeiro no router da NET e direcionar para o IP do Google Wifi. Assim, pela lógica, essa porta estaria aberta para todos os equipamentos da rede interna,  independente do IP delas ou se houvesse ou não necessidade para isso. Mas nem isso funcionava.

Assim, coloquei o router da NET em bridge (já falei aqui) e fui estudar um pouco sobre NAT (Network Address Translation), Virtual Server, Port Triggering e DMZ Host.

Mas tudo isso mudou quando relembrei de uma vez que tentei, sem sucesso, criar uma VPN. Na época nem sabia bem para que isso poderia me ajudar, acho que fui instalar para aprender mesmo, sem utilidade prática. Não seria uma VPN para acessar um conteúdo no exterior (falei disso bem no começo do blog, lá em 2010!). Meu objetivo aqui é ligar dois pontos seguros: minha rede local e meu notebook ou celular. Sei onde está a entrada e saída dos dados.

Na época, quando tentei fazer essa VPN, utilizei o PiVPN, fazendo do RP3B+ um servidor de VPN. Não funcionou e hoje suspeito que seja por conflito de IP dos roteadores. Como bypassei o da NET colocando ele em bridge, espero que dê certo desta vez.

Antes de tudo, fiz uma instalação limpa no cartão do RP com o Raspberry Pi OS. Depois instalei o OpenMediaVault (veja como instalar facilmente aqui). O objetivo era ter um HD na rede para testes e saber se a VPN funcionaria bem mesmo. Tudo pronto, vamos à VPN em si.

Optei pelo PiVPN. O processo é fácil, tá bem explicado e tem vários tutoriais na Internet. Gostei muito deste vídeo do Lon Seidman no Lon.TV, um dos melhores do YouTube.

Uma das vantagens do PiVPN é a facilidade para instalação. Outra é que o processo já cria a chave para criptografia durante a instalação.

Para iniciar a instalação, abra o Console do RP (ou Putty ou Terminal, se estiver usando SSH) e digite:

    sudo curl -L https://install.pivpn.io | bash

A instalação vai começar e algumas telas serão mostradas:


Um ponto importante é que, como todo servidor, o PiVPN necessita ter um IP Estático. Além disso, o cliente VPN (o celular ou o notebook) precisará saber para qual IP válido (o IP fornecido pelo provedor, ISP) ele deverá mandar a requisição. Vou falar disso daqui a pouco.


Definir um IP fixo na rede doméstica é fácil. Entre no seu roteador e procure por reservar de IP, reserva de endereços no DHCP ou algo assim. Cada router tem um nome pra isso. Aqui o meu já estava fixado (o RP, pela conexão ethernet, sempre tem esse IP).


Escolha como você vai se conectar, cabo ou wifi. O recomendado para um server sempre é cabo devido a estabilidade. Assim, escolhi eth0.


Confirme se o IP está certo e vamos em frente.

Agora o PiVPN deseja saber onde será guardada as informações do OVPN. Como só tenho um usuário no RP, as configurações serão guardadas em /home/pi/ovpns. Nesta pasta ficará guardada a chave de criptografia que será transferida para o cliente posteriormente.



O sistema agora perguntará se desejamos permitir a instalação automática das atualizações de segurança. Por motivos óbvios, a resposta só pode ser SIM.



Agora escolheremos o protocolo que o PiVPN utilizará, UDP ou TCP (veja a diferença aqui, muito bem explicado) e a porta que deverá ser utilizada. Por padrão o PiVPN escolhe o protocolo UDP e a porta 1194. Eu optei por manter o protocolo UDP, mas troquei a porta por segurança (existem portas que não devem ser utilizadas; o sistema tem 65.536 portas e algumas -veja aqui e aqui devem ser evitadas porque normalmente são utilizadas).

Nesse momento, você deverá retornar ao seu router e reservar, no IP fixado para o RP, qual a porta escolhida para receber o fluxo externo, a porta do fluxo interno (geralmente a mesma) e registrar qual o protocolo deseja utilizar (TCP, UDP ou ambos).



Agora será perguntado sobre nível de encriptação das chaves. Escolha 2048 ou 4096. É a segurança de seus dados e da sua rede doméstica que está em jogo. Jogue para ganhar.



Agora vamos ter mais um pouco de teoria para continuar o processo.

As operadoras fornecem um IP para cada computador conectado na rede. Esse IP é conhecido como IP válido ou IP público (IP atribuído pelo órgão regulador). Para saber se um IP é válido ou não, é só saber o seguinte:

    -> 10.x.x.x
    -> de 172.16.x.x a 172.32.x.x
    -> 192.168.x.x

Todos os IPs que estejam nessa regra de cima NÃO são IPs válidos, servem apenas para uso em redes locais. Fora isso, são IPs válidos (e distribuídos pela sua ISP ou por um órgão regulador).

Os IPs geralmente estão distribuídos na versão 4 (famoso IPv4). Esse endereços têm 32 bits de comprimento e existem 2ˆ32 endereços IPv4 (cerca de 4,3 bilhões de endereços). Com o aumento dos dispositivos conectados, esses endereços são insuficiente. Assim, existem duas saídas: a melhor para o usuário e a melhor para a operadora.

A melhor saída para o usuário é a adoção do IPv6. Aqui os endereços têm 128bits e existem 2ˆ128 endereços IPv6 (cerca de 340 duodecilhões de endereços, 340 seguido de 12 zeros...). Assim, cada dispositivo na rede teria seu endereço fixo (um IP válido para cada equipamento na rede).

MAS (sempre tem um mas...) nem todos os servidores e roteadores suportam IPv6. Tirando a questão de bugs e outros problemas que ainda podem existir. Como sempre, vale a regra do "MAS": nada depois de um MAS pode ser bom!

As operadoras resolveram isso de outra forma: CGNAT. Resumidamente, com a escassez de endereços IPv4 (tem mais equipamento na rede que endereço), eles distribuem os endereços entre que está ativo e podem trocar seu endereço a qualquer momento.

O que isso tem a ver com a nossa VPN? Tudo! O cliente precisa saber qual IP válido ele deve procurar para fazer a requisição do dado. Ora, se o seu IP válido muda frequentemente, como você pode resolver isso? Ou pagando para ter um IP válido fixo ou utilizado um serviço de Dynamic DNS (DDNS, No-IP, etc).

Esses serviços de DDNS fazem basicamente uma atualização do seu IP válido e o registram em um sistema de domínios (DNS). Ou seja, pegam o seu 189.17.48.190 que a sua ISP atribuiu para você e o registram como fulano.ddns.net. Assim, quem digitar isso vai ser encaminhado para o IP atribuído a esse DNS. Esses serviços geralmente tem um aplicativo que faz automaticamente essa atualização. Alguns roteadores fazem essa atualização também (MAS, sempre o MAS, Google Wifi não tem esse serviço de DDNS...).

Assim, entrei no No-IP, fiz o cadastro e escolhi o nome. Baixei o aplicativo deles para atualização pro Mac, mas como estava tudo rodando no Pi, achei melhor baixar pra lá e deixar o RP fazendo tudo isso. Basicamente fiz isso:

    sudo su #para ficar com super usuário

    cd /usr/local/src

    wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz

    tar xzf noip-duc-linux.tar.gz

    cd noip-2.1.9-1

    make

    make install

Agora o programa vai pedir o nome de usuário ou email registrado no No-IP.com, a senha, vai pedir pra você escolher qual nome deseja atualizar e com qual frequência (o padrão é 30 minutos, mas eu escolhi 5 minutos). Depois digite, ainda com SU:

    /usr/local/bin/noip2

Pronto. Agora já temos um DNS ligado ao nosso IP válido e continuamente atualizado.

O próximo passo agora no PiVPN é escolher se quer utilizar o IP público (ou válido) ou escolher um DNS. Obviamente vamos escolher entrar com DNS e colocar o DNS que acabamos de criar no No-IP (lembre-se, é só no DNS, sem "http"):



Agora somos perguntados sobre qual serviço de DNS desejamos usar. Escolhi o Google, mas o OpenDNS também é bem rápido. Falei um pouco disso no final deste post.


Bom, a configuração acaba aqui. Agora falta apenas entrar com os usuários (clientes) da VPN.

Dê um

    pivpn add

e digite o que é pedido: nome do cliente, senha e senha novamente. Nunca é demais reforçar que a senha deve ser boa, né?

Agora, se tudo deu certo, a chave para o cliente foi criada e deverá estar em /home/pi/ovpns. Essa chave deve ser enviada para o cliente. No meu caso, como o cliente sou eu mesmo (será meu notebook, iPad e iPhone), posso passar por três formas: por email (pior opção, insegura), pendrive (tem que lembrar de apagar depois) ou por um serviço de nuvem.

Não se esqueça de liberar essa porta UDP no roteador, em Port Management. Acrescente a regra com a porta escolhida, o padrão de comunicação (UDP, TCP ou ambos) e confira se o MAC Address do servidor é o mesmo que você está liberando.

No Mac instalei o Tunnelblick para acessar a VPN. Arrastei a chave para o ícone do programa, digitei o usuário e a senha e pronto. Fica um pequeno ícone na barra superior e aí é só clicar lá e começar a navegação via VPN.

No iPad e iPhone o processo é um pouco diferente. Para ambos existe aplicativo da OpenVPN que deve ser baixado na AppStore. Depois de baixado, conecte o iDevice ao computador, abra o Finder, selecione seu dispositivo e, à direita, escolha "Arquivos". A seguir arraste a chave para o aplicativo OpenVPN e termine de configurar no iDevice.



Bom, o próximo passo é efetivamente criar um bom NAS.

Utilizando a VPN, tenho a segurança agora de acessar o NAS de fora da rede, qualquer que seja o NAS escolhido.

Pode ser o OpenMediaVault (e ele ficaria apenas para arquivos e/ou TimeMachine). Pode ser o NextCloud (que tem aplicativos que podem ser utilizados nos dispositivos móveis) ou tentar o XPEnology, meu sonho de consumo.

Para o XPEnology, precisarei de uma máquina boa, que permita virtualização.

Lembram do MacMini que morreu no começo do ano? Pois é, descobri uma empresa aqui em BH que tentará recuperar a placa lógica dele. Se der certo, ótimo. Se não der, é pensar no plano B.

Só que esse post acaba por aqui. Obrigado.