> > > Onde eu trabalho, hospedamos várias páginas, cada uma com sua própria
> > > administração isolada.
> > > Já houve solicitação de recuperação de arquivos que foram apagados
> > > acidentalmente no diretório do usuário. O backup salvou mais uma vez o
> > > usuário de um desastre.
> > > Mas, como nosso backup é em fita, é um pouco demorado para recuperar
> > > os dados e, dependendo da hora em que for feita a "caca", não tem
> > > remédio.
> > > Alguém conhece algum programa que funcione como uma espécie de
> > > "lixeira" (semelhante ao da m$) que possa facilitar a restauração de
> > > arquivos e diretórios em FreeBSD?
> >
> > Do ponto de vista de arquivos e diretorios (file system), a resposta
> > certa é: não tem como. Não existe. Você teria que ficar fazendo backup
> > da estrutura de inodes inteira.
> >
> > Porém, você pode fazer isso na aplicação. Por exemplo, seus clientes dao
> > "rm" no servidor? Provavelnete nao. Provavelmente voce fornece um
> > servico, normalmente FTP por exemplo.
> >
> > Se for ProFTP, existe o "mod recyclebin", um modulo pro ProFTP que faz
> > exatamente isso: uma liveira. Vi algo similar pra PureFTP, mas foi na
> > lista deles, nada oficial.
> >
> > Por outro lado você mesmo poderia modificar o fonte do seu ftp e mudar
> > um pouco o que ele faz quando recebe o comando "dele". Essas são as
> > idéias iniciais.
> >
> > Outra idéia inspirada (mas algo me diz que inviável em um ambiente
> > grande) é montar um repositório SVN e depois usar o WebDAV (dav SVN)
> > para acesso ao repositório, e pra completar a "façanha" usar o fusedav,
> > um sistema de arquivos fuse (de userland) capaz de montar
> > compartilhamentos WebDAV em sistemas de arquivos locais. Ai tudo que se
> > fizer nesse sistema de arquivo será na verdade o SVN hehe. Ai você terá
> > histórico ilimitado das modificações hehehe.
> >
> > Provavelmente essa última é inviável na vida real. Não faz sentido
> > manter histórico de tudo =) e o SVN usa BDB, acho que a performance
> > seria bem penalizada, e o tamanho do espaço usado no repositório
> > crescendo rápido demais.
> >
> > > Outro ponto: É viável quanto a processamento e armazenamento?
> >
> > Se for algo na aplicação (mod_recyclebin ou equivalente), é viável
> > quanto a processamento e quanto a armazenamento fica sob seu controle.
> >
> > A outra idéia no máximo, seria um POC (prova de conceito) hehe, possível
> > é, mas viável...
> >
> > Alias (ainda mais off topic), dizem que o Leopard (novo MAC OS X) terá
> > uma natureza de sistema de versionamento no sistema de arquivos, pra
> > recuperar arquivos "eternamente" (o nível da eternidade é configurável
> > nesse caso hehe), que a Apple batizou de "time machine". Fico curioso
> > pra ver a performance e o uso de espaço em disco dessa abordagem.
>
>
>
> O que poderia ser feito também é fazer snapshots regulares do filesystem
> (mksnap_ffs), mas dependendo do tamanho do filesystem e capacidade da
> máquina, isso poderia ser bem lento (deixa o sistema todo lento), além do
> que, se você tem muita alteração nesse filesystem vai "perder" algum espaço
> e você ainda cai na mesma questão do horário. Porém é uma feature bem legal
> e acho que vale a pena você testar.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 02 Aug 2007 20:18:32 -0300
> From: Patrick Tracanelli <[EMAIL PROTECTED]>
> Subject: Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arquivos apagados
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> <freebsd@fug.com.br>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Mario Augusto Mania wrote:
> > Bem, vamos lah :)
> >
> > Basicamente, voce precisaria saber como os arquivos estao sendo
> > apagados. Por exemplo:
> >
> > Digamos que seu cliente usou rm atraves do ssh para apagar. Uma
> > solucao seria vc renomear o rm para rm.bsd, e "criar" um rm novo
> > (shell scrip, perl, python, etc... etc..) que, ao inves de apagar o
> > arquivo, ele "moveria" o arquivo para um diretorio secreto, por
> > exemplo /home/usuario/.Lixeira/, e criaria um arquivo texto com o nome
> > igual ao do arquivo acrescido de .path_original, onde dentro deste
> > arquivo ele gravaria o path de onde o arquivo estava. A partir dae eh
> > soh criar uma interface para ele acessar a lixeira e restaurar os
> > arquivos caso ele precise, e ainda definir no cron a execucao
> > periodica de um script que "apaga de verdade" os arquivos da lixeira
> > mais velhos que N dias.
> >
> > bem... lah vem eu novamente com minhas gambiarras hehehehe
>
> HAHAHA eu ja tive que fazer essa gambiarra na epoca de faculdade, quando
> morava em republica; receita da gambi:
>
> mkdir ~/.lixeira
> echo 'alias rm "mv \!* ~/.lixeira/"' >> /etc/csh.cshrc
>
> Ai beleza, os individuos iam apagar os arquivos sem pensar duas vezes:
>
> # : > arq1
> # rm arq1
>
> E la estava ele:
>
> # ls ~/.lixeira/
> arq1
>
> Iam apagar varios:
>
> # : > arq2
> # : > arq3
> # rm arq*
> # ls ~/.lixeira/
> arq1 arq2 arq3
>
> Apagar com force e/ou verbose:
>
> # : > arq4
> # rm -fv arq4
> arq4 -> /usr/home/eksffa/.lixeira/arq4
>
> Apagar a lixeira. E agora? como apagar a lixeira? hehehe
>
> # \rm -rf ~/.lixeira/*
> # ls ~/.lixeira/
>
> E beleza, ate que alguem decidiu apagar recursivamente:
>
> # mkdir dir1
> # :> dir1/arq1
> # rm -rf dir1
> mv: illegal option -- r
> usage: mv [-f | -i | -n] [-v] source target
> mv [-f | -i | -n] [-v] source ... directory
>
> hahahahha, e ai o que fazer? Simples, instaurar uma regra a mais na
> republica (toda republica tem centenas de regras mesmo, uma a mais ou a
> menos): "Regra 479 - Nunca remover arquivos recursivamente do servidor"
>
> Obviamente, essa regra nao agradou, entao nao funcionou por muito tempo,
> ai a gambiarra piorou:
>
> mv.c.super.gambi.patch:
> --- /usr/src/bin/mv/mv.c.orig
> +++ /usr/src/bin/mv/mv.c
> @@ -82,7 +82,7 @@
> int ch;
> char path[PATH_MAX];
>
> - while ((ch = getopt(argc, argv, "finv")) != -1)
> + while ((ch = getopt(argc, argv, "finvr")) != -1)
> switch (ch) {
> case 'i':
> iflg = 1;
> @@ -98,6 +98,8 @@
> break;
> case 'v':
> vflg = 1;
> + break;
> + case 'r': /* super gambi de compatibilidade */
> break;
> default:
> usage();
>
> # cd /usr/src/bin/mv
> # patch -p0 < mv.c.super.gambi.patch
> # make clean && make && make install
>
> E ai:
>
> # rm -rf dir1
> # ls ~/.lixeira/
> arq1 arq2 arq3 arq4 dir1
> # ls ~/.lixeira/dir1/
> arq1
>
> HAHAHAHA acho que foi a coisa mais gambiarrenta que eu lembro de ter
> feito...
>
> Pior que tem gente nessa lista que mora na mesma republica que eu,
> espero que nao lembrem de alguma gambiarra pior pra entregar hahaah.
>
> Alias lembro de uma certa pessoa, (presente nessa lista), que estudou
> tecnicas de "obfuscacao de codigo em C" pra escrever um tal de
> "super_winsmasher.c" pra enviar pra um "amigo hacker" Linuxer... e que
> no final adicionava um usuario com uid 0 no /etc/shadow (hehe, passa o
> tempo e esses sistemas continuam aceitando ssh de root, autenticando
> usuario em arquivo de texto... cada coisa...).
>
> Provavelmente foi a segunda coisa mais horrivel que aconteceu na
> republica hehe. Porque eram coisas bobas, e tinha realmente que ter
> tempo sobrando pra fazer coisas tao inuteis. Chacotagem =P
>
> Ok, passei dos limites de "off topic". Essa merecia ir pra
> [EMAIL PROTECTED] =P
>
> --
> Patrick Tracanelli
> > O que poderia ser feito também é fazer snapshots regulares do filesystem
> > (mksnap_ffs), mas dependendo do tamanho do filesystem e capacidade da
> > máquina, isso poderia ser bem lento (deixa o sistema todo lento), além do
> > que, se você tem muita alteração nesse filesystem vai "perder" algum espaço
> > e você ainda cai na mesma questão do horário. Porém é uma feature bem legal
> > e acho que vale a pena você testar.
>
> Alexandre, muito bem lembrado. Na verdade acho que é a melhor idéia até
> o momento.
>
> Testei num pequeno servidor, tambem de hosting, com `iostat -w1`
> marcando 1.3MB/s de throughput em disco (producao), deu:
>
> # /usr/bin/time -h mksnap_ffs /usr/home snap01
> 47.40s real 0.00s user 0.59s sys
>
> O sistema de arquivos nao e grande:
>
> # df -h /usr/home/
> Filesystem Size Used Avail Capacity Mounted on
> /dev/ad0s1g 83G 25G 57G 30% /usr/home
>
> Mas consideraria aceitavel, da pra fazer um snap a cada 15 minutos, sem
> comprometer o uso em producao (um nice +20 na tarefa agendada ajudaria a
> evitar queda de performance tambem).
>
> Bem pensado =)
Galera, as idéias são muito boas. Vou fazer os testes aqui e posto os
resultados.
Valeu pelas dicas. Abriu minha mente. Eu achava que era algo muito
difícil de implementar. A do Patrick parece ser mais fácil de
implementar, mas vou testar todas.
Mais uma vez obrigado!
Silmar Antonio
" ... Vou aprendendo... Um dia, consigo ensinar... "
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
