Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
Alexandre Biancalana wrote: > On 8/2/07, Patrick Tracanelli <[EMAIL PROTECTED]> wrote: >> 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 SizeUsed Avail Capacity Mounted on >> /dev/ad0s1g 83G 25G57G30%/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 =) > > > > Obrigado! ;-) > > Só acho vale a pena ser testado no ambiente final dele, em horário de pico, > em fim, um "teste real", eu nunca usei snapshot desta forma, mas nas listas > la fora teve gente reclamando de "congelamento" momentaneo do SO durante o > snapshot em versões passadas (final do ano passado), e o Kris Kennaway > comentou na época que isso poderia mesmo acontecer. Sem duvida. Eu tenho problema de congelamento com dump -L por exemplo, em producao. Porem, se o sistema de arquivos nao for muito grande ou o uso em producao tambem nao, muda muito o comportamento. Isso porque o acesso a disco ainda nao pode ser controlado como prioridade no escalonador por exemplo, entao um processo de baixa prioridade pode gerar acesso em disco maior que outros, ao ponto de prejudicar os mais privilegiados. O ideal seria uma forma de definir prioridade de operacao em disco. O PJD comentou sobre estar implementando isso como modulo geom, mas nao sei da "prioridade" disso pra esse desenvolvedor. > Silmar, testa ai e fala pra gente se funcionou, se puder com alguns detalhes > de tamanho do filesystem, tempo de execuçao, etc... Tamanho do FS, metodo de acesso a disco e vazao em producao, vao fazer a diferenca entre a viabilidade ou nao. Senao, implementar na aplicação volta a ser a opcao. > > Eu tenho a idéia de implementar isso nos novos servidores de arquivos aqui > da empresa, pois está cada vez mais frequente os cabecinhas > apagarem/alterarem oque não devem e ficarem pedindo pra restaurar planilhas, > etc... só não testei... teremos pelo menos 2 servidores com 2 TB cada um... Desse tamanho, acho que fora do horario comercial soh. E' servidor de arquivos com o que? Samba tem o vfs recycle que gera a lixeira (com politica configuravel) e appletalk tem o drestore, menos flexivel que o recycle do samba mas ainda assim funcional. Se for NFS, bom, ai so com coisa experimental (NFS4 com o "newnfsd" permite chamar scripts externos pra certos tipos de operacoes). > > Alexandre > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
On 8/2/07, Patrick Tracanelli <[EMAIL PROTECTED]> wrote: > > 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 SizeUsed Avail Capacity Mounted on > /dev/ad0s1g 83G 25G57G30%/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 =) Obrigado! ;-) Só acho vale a pena ser testado no ambiente final dele, em horário de pico, em fim, um "teste real", eu nunca usei snapshot desta forma, mas nas listas la fora teve gente reclamando de "congelamento" momentaneo do SO durante o snapshot em versões passadas (final do ano passado), e o Kris Kennaway comentou na época que isso poderia mesmo acontecer. Silmar, testa ai e fala pra gente se funcionou, se puder com alguns detalhes de tamanho do filesystem, tempo de execuçao, etc... Eu tenho a idéia de implementar isso nos novos servidores de arquivos aqui da empresa, pois está cada vez mais frequente os cabecinhas apagarem/alterarem oque não devem e ficarem pedindo pra restaurar planilhas, etc... só não testei... teremos pelo menos 2 servidores com 2 TB cada um... Alexandre - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
> > > 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)" > > 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/ > arq1arq2
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
> 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 SizeUsed Avail Capacity Mounted on /dev/ad0s1g 83G 25G57G30%/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 =) -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
kakakakakakakakakakakakaka
desculpa não deu pra segurar !!!
abraços !
Forfe (São Carlos)
Patrick Tracanelli escreveu:
> 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/
> arq1arq2arq3
>
> 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/
> arq1arq2arq3arq4dir1
> # 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
>
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
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/
arq1arq2arq3
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/
arq1arq2arq3arq4dir1
# 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
FreeBSD Brasil LTDA.
(31) 3281-9633 / 3281-3547
[EMAIL PROTECTED]
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
On 8/2/07, Patrick Tracanelli <[EMAIL PROTECTED]> wrote: > > Silmar Oliveira wrote: > > Olá, lista. > > > > 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. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
Silmar Oliveira wrote: > Olá, lista. > > 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. > > Desde já agradeço. > > Abs, > Silmar Antonio -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
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 m3 Em 02/08/07, Victor Loureiro Lima<[EMAIL PROTECTED]> escreveu: > Em 02/08/07, Silmar Oliveira<[EMAIL PROTECTED]> escreveu: > > Olá, lista. > > > > 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? > > Outro ponto: É viável quanto a processamento e armazenamento? > > > > Desde já agradeço. > > > > Abs, > > Silmar Antonio > > - > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > E se voce versionasse toda a estrutura de diretorios dos dominios com > um repositorio, algo como um svn (http://subversion.tigris.net) ou cvs > (www.opencvs.org)? > > victor f. loureiro lima > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Atenciosmente Mario Augusto Mania --- [EMAIL PROTECTED] Cel.: (43) 9938-9629 Msn: [EMAIL PROTECTED] - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
Em 02/08/07, Silmar Oliveira<[EMAIL PROTECTED]> escreveu: > Olá, lista. > > 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? > Outro ponto: É viável quanto a processamento e armazenamento? > > Desde já agradeço. > > Abs, > Silmar Antonio > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > E se voce versionasse toda a estrutura de diretorios dos dominios com um repositorio, algo como um svn (http://subversion.tigris.net) ou cvs (www.opencvs.org)? victor f. loureiro lima - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] [OFF-TOPIC] Prevenção contra arqu ivos apagados
Olá, lista. 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? Outro ponto: É viável quanto a processamento e armazenamento? Desde já agradeço. Abs, Silmar Antonio - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
