Postagem em destaque

WSL: Backup e Restauração

Imagem
Às vezes você tem um drive mais rápido (SSD) que o outro (HD). É o meu caso: meu drive C, é um SSD de 256 GB e meu drive D, é um HD de 512 GB. Um é pequeno e rápido; outro é grande e lento.  Meu drive C, por ser pequeno, acabou ficando sem espaço. Então fui pesquisar por grandes arquivos (usei o excelente TreeSize Free para isso) e descobri um tal de ext4.vhdx que tinha 29 GB. Esse arquivo é a imagem do disco do WSL no Windows e é normal ficar grande. O problema é que mesmo você apagando arquivos ele não diminui. E quando você usa o Docker, a situação se agrava rapidamente. Então, descobri uma maneira de compactar esse arquivo/disco. É um comentário da KarolineWss numa issue do WSL. Funciona maravilhosamente bem. Tanto que consegui diminuir praticamente pela metade o arquivo.  Mas para fazer isso, claro, pesquisei como fazer backup (e restauração). Esse artigo é sobre isso. E com um bônus, esse o arquivo fica numa localização meio complicada para humanos, mas fazendo um bac...

Faça o simples

Comecei a programar bem cedo, em 1985, num TK-2000. Naquela época tinha que se virar com meros 48 KB (isso mesmo, não são 48 MB) de memória RAM e talvez por isso aprendi a fazer programas enxutos.

Lembro que quando trabalhava com Clipper, tive que criar um módulo de abertura/fechamento de tabelas do BD, pois se ficasse com muitas tabelas abertas simultaneamente dava problema de falta de memória. Assim, o programa ficava monitorando as tabelas, e cada vez que uma era aberta, subia uma posição na fila. As que ficavam no final da fila, abaixo de um determinado limite, eram fechadas automaticamente.

Em sistemas maiores, sempre tem quem tente cercar todas as possibilidades: "e se, o usuário quiser, mais tarde, um relatório por filial", "e se, no futuro, for preciso aplicar uma correção na tabela XYZ", "e se, ...".

Reparem que são suposições ("e se") projetadas para um momento que não se sabe se ocorrerá ("mais tarde", "no futuro"). Mas atenção: em momento algum disse que não é preciso prever certas situações. Pelo contrário, o bom analista/programador precisa saber distinguir essas situações. Mas é preciso ficar atento à, digamos, preparação do código para novas funcionalidades. Isso pode gerar, no mínimo, tempo gasto sem necessidade.

Para saber mais: Curiosity e suas 2,5 milhões de linhas de código


Comentários

Postagens mais visitadas deste blog

Netflix não mostra ícone de streaming

Google Hacking

Radar no KM 175 da BR101