are un file e ricompattarlo
>>> senza
>>> modificare owner e permessi dei file del RFS.
>>> E' possibile? Se sì, come?
>>>
>>
> Se decompatti il file come root e usi --preserve tar mantiene i permessi
> ed i proprietari anche se NON ESISTONO sulla mac
file il cui owner è root
(riferito al sistema embedded per cui è stato prodotto).
Dovrei scompattare tale archivio, modificare un file e ricompattarlo senza
modificare owner e permessi dei file del RFS.
E' possibile? Se sì, come?
Se decompatti il file come root e usi --preserve tar mantiene i
sto comando e sono riuscito a fare
quello che mi serviva.
Lo riporto qui, nel caso in futuro possa essere utile/interessante per
altri:
(dentro uno script eseguo)
fakeroot sh -c '
tar xvjf pkg.tar.bz2
echo "blabla" >> my_path/file_to_change
[other stuff...]
exit'
e il gioco è fatto.
Ciao e grazie,
I.
On Fri, Dec 29, 2017 at 07:53:48AM +0100, Igor Trevisan wrote:
> Con un framework per la gestione/creazione di Root File System per sistemi
> Linux genero un pacchetto tar.bz2 che contiene un RFS completo per un
> sistema Linux (arm). Tale pacchetto contiene file il cui owner è root
> (riferito al
Ciao a tutti,
mi scuso subito per l'OT: la questione che pongo è assolutamente generale
(e non strettamente collegata a Debian quindi) ma confido che in lista ci
sia qualche anima pia che mi perdoni e possa dare una risposta definitiva
ai miei dubbi.
Vengo al sodo.
Sto lavorando da utente
Il 26/09/2016 00:37, beppe ha scritto:
Lo script funziona bene finche' non incontra una directory con spazi:
echo $data
#IFS_OLD=$IFS
#IFS=$'\n'
# per controllare la data
sleep 2
for i in $(ls -d /home/prove/*/ | cut -f4 -d'/' | sed 's/\ /\\ /g');
do tar -cvzf $data'_'${i%%/} '/home/prove/'${i
Il 26/09/2016 12:12, Piviul ha scritto:
beppe ha scritto il 26/09/2016 alle 00:37:
Lo script funziona bene finche' non incontra una directory con spazi:
$ cat tar_backup.sh
#!/bin/bash
data=$data$(date | cut -d ' ' -f6 | cut -c 1-4)
data=$data$(date | cut -d ' ' -f2)
data=$data$(date | cut -d
Piviul ha scritto il 26/09/2016 alle 12:12:
[...]
(anche se userei +%Y%b%d [...]
intendevo +%Y%m%d...ovviamente!
Piviul
beppe ha scritto il 26/09/2016 alle 00:37:
Lo script funziona bene finche' non incontra una directory con spazi:
$ cat tar_backup.sh
#!/bin/bash
data=$data$(date | cut -d ' ' -f6 | cut -c 1-4)
data=$data$(date | cut -d ' ' -f2)
data=$data$(date | cut -d ' ' -f3)
echo $data
a questo punto
' ' -f3)
echo $data
#IFS_OLD=$IFS
#IFS=$'\n'
# per controllare la data
sleep 2
for i in $(ls -d /home/prove/*/ | cut -f4 -d'/' | sed 's/\ /\\ /g'); do
tar -cvzf $data'_'${i%%/} '/home/prove/'${i%%/}; done
io credo che il problema risieda nelle linee che hai commentato. Di
default IFS (Internal
=$'\n'
# per controllare la data
sleep 2
for i in $(ls -d /home/prove/*/ | cut -f4 -d'/' | sed 's/\ /\\ /g'); do
tar -cvzf $data'_'${i%%/} '/home/prove/'${i%%/}; done
io credo che il problema risieda nelle linee che hai commentato. Di
default IFS (Internal File Separator) è lo spazio quindi questo
)
data=$data$(date | cut -d ' ' -f3)
echo $data
#IFS_OLD=$IFS
#IFS=$'\n'
# per controllare la data
sleep 2
for i in $(ls -d /home/prove/*/ | cut -f4 -d'/' | sed 's/\ /\\ /g'); do
tar -cvzf $data'_'${i%%/} '/home/prove/'${i%%/}; done
#IFS=$IFS_OLD
avevo provato a ridefinire IFS, ma quando tar ri
te | cut -d ' ' -f3)
> echo $data
> #IFS_OLD=$IFS
> #IFS=$'\n'
>
> # per controllare la data
> sleep 2
> for i in $(ls -d /home/prove/*/ | cut -f4 -d'/' | sed 's/\ /\\ /g'); do
> tar -cvzf $data'_'${i%%/} '/home/prove/'${i%%/}; done
>
> #IFS=$IFS_OLD
>
> avevo pr
in $(ls -d /home/prove/*/ | cut -f4 -d'/' | sed 's/\ /\\ /g'); do
tar -cvzf $data'_'${i%%/} '/home/prove/'${i%%/}; done
#IFS=$IFS_OLD
avevo provato a ridefinire IFS, ma quando tar riceve i parametri non li
legge correttamente.
(al momento ho risolto rinominando le directory sostituendo gli
i baco segnalato, anche per bachi
infinitamente meno gravi di quello da me riscontrato in tar.
Se poi qualcuno fosse interessato ho sviluppato una serie di script[¹]
in bash per backup incrementali basati su dar che semplificano il backup
su dischi usb con supporto a snapshot LVM per backup "a
Il 11/05/2016 08:55, Piviul ha scritto:
Piviul ha scritto il 30/04/2016 alle 18:51:
[...]
con tar non mi sono trovato bene nel momento in cui ho dovuto anch'io
effettuare un restore... non mi ricordo bene (ora ricordo solo che non
supporta le acl) il motivo ma ricordo che l'ho maledetto un bel
Piviul ha scritto il 30/04/2016 alle 18:51:
> [...]
> con tar non mi sono trovato bene nel momento in cui ho dovuto anch'io
> effettuare un restore... non mi ricordo bene (ora ricordo solo che non
> supporta le acl) il motivo ma ricordo che l'ho maledetto un bel po'.
Ora ricordo il
On 30/04/2016 19:01, Davide Prina wrote:
On 30/04/2016 18:42, Pol Hallen wrote:
esiste un sistema (7zip magari?) che permetta di creare un archivio
(magari grosso il doppio o più) con un altissima tolleranza agli errori?
$ axi-cache search deduplication
ouch!
ho risposto l'opposto di
Il 30/Apr/2016 21:18, "Pol Hallen" ha scritto:
>
> grazie!
>
>
>> Non so se esistono soluzioni più moderne, ma avere più sicurezza un
tempo si usava parchive:
>> http://www.techsono.com/usenet/files/par2
>> Crei l’archivio, e poi crei un file par con una certa ridondanza
grazie!
Non so se esistono soluzioni più moderne, ma avere più sicurezza un tempo si
usava parchive:
http://www.techsono.com/usenet/files/par2
Crei l’archivio, e poi crei un file par con una certa ridondanza (ad es. 15%),
che permette di riparare eventuali danni minori o uguali al livello di
On 04/30/16 18:42, Pol Hallen wrote:
'sera a tutti :-)
ho notato che negli anni, alcuni backup fatti con tar (e bzip2)
presentano dei problemi: tipo alcuni sono corrotti. Forse lo
spostamento dai vari dischi, problemi ai moduli ram, etc.
esiste un sistema (7zip magari?) che permetta di
Il 30/04/2016 19:15, gerlos ha scritto:
Il giorno 30/apr/2016, alle ore 18:42, Pol Hallen <debitv...@fuckaround.org> ha
scritto:
'sera a tutti :-)
ho notato che negli anni, alcuni backup fatti con tar (e bzip2) presentano dei
problemi: tipo alcuni sono corrotti. Forse lo spostamento da
Il 30/04/2016 18:42, Pol Hallen ha scritto:
'sera a tutti :-)
ho notato che negli anni, alcuni backup fatti con tar (e bzip2)
presentano dei problemi: tipo alcuni sono corrotti. Forse lo
spostamento dai vari dischi, problemi ai moduli ram, etc.
esiste un sistema (7zip magari?) che permetta
On Sat, Apr 30, 2016 at 06:42:59PM +0200, Pol Hallen wrote:
> esiste un sistema (7zip magari?) che permetta di creare un archivio (magari
> grosso il doppio o più) con un altissima tolleranza agli errori?
Mi trovo molto bene con par2. Funziona su ogni tipo di file; in breve:
par2 c file.zip
> Il giorno 30/apr/2016, alle ore 18:42, Pol Hallen <debitv...@fuckaround.org>
> ha scritto:
>
> 'sera a tutti :-)
>
> ho notato che negli anni, alcuni backup fatti con tar (e bzip2) presentano
> dei problemi: tipo alcuni sono corrotti. Forse lo spostamento dai
On 30/04/2016 18:42, Pol Hallen wrote:
ho notato che negli anni, alcuni backup fatti con tar (e bzip2)
presentano dei problemi: tipo alcuni sono corrotti. Forse lo spostamento
dai vari dischi, problemi ai moduli ram, etc.
questo mi sembra molto strano. La corruzione degli archivi li puoi
'sera a tutti :-)
ho notato che negli anni, alcuni backup fatti con tar (e bzip2)
presentano dei problemi: tipo alcuni sono corrotti. Forse lo spostamento
dai vari dischi, problemi ai moduli ram, etc.
esiste un sistema (7zip magari?) che permetta di creare un archivio
(magari grosso il
ho potuto provare questo tipo di backup solo adesso grazie a tutti!!
funziona perfettamente! :)
ssh -o Compression=no -c arcfour \
r...@ilmioserver.org 'tar czf - /' \
| tee file-locale.tar.gz | tar tzvf -
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian
Grazie Giuseppe per il bug fixing. Ieri ero di gran fretta...
Sent from my iPad
On 06 Feb 2015, at 22:48, Giuseppe Sacco giuse...@eppesuigoccas.homedns.org
wrote:
Ciao MaX,
# ssh r...@ilmioserver.org /usr/bin/tar zcvf / - ?
ma poi come faccio a redirigere il flusso di dati
Ciao MaX,
# ssh r...@ilmioserver.org /usr/bin/tar zcvf / - ?
ma poi come faccio a redirigere il flusso di dati attraverso lo stesso
canale che sto usando per connettermi in modo che il tar, venga creato
nel mio computer e non nel server?
ssh r...@ilmioserver.org 'tar czf - /' file
://www.2daygeek.com/reverse-rsync-command-practical-example-for-backup-sync/
Ma a me in locale non serve affatto ricostruire l'abero del filesystem
de server... a me serve un tar compresso
cetrto potrei scaricare l'albero e poi comprimerlo ma che spreco
di risorse!!
oppure creare un tar nel
Il 06/02/15, Gian Uberto Laurisa...@eng.it ha scritto:
ssh root@@ilmioserver.org tar -Jcvf - /backup/ilmioserver.org.tar.xz
si, ma non funziona (c' è un @ di troppo, suppongo sia un typo)
...del resto non ci capisce da dove prende l' input
il risultato è:
tar: Cowardly refusing to create
MaX writes:
# tar zcvf - / | ssh r...@ilmioserver.org cat
/backup/ilmioserver.org.tar.gz
Ma davvero non ci hai pensato a
ssh root@@ilmioserver.org tar -Jcvf - /backup/ilmioserver.org.tar.xz
(verifica che opzioni di compressione accetta tar su ilmioserver e la
tua macchina e scegli la
errore tar
512 e si pianta.
ho temporaneamente risolto ignorando gli errori ma non mi sembra una
cosa intelligente. ho pensato che potrebbero essere dei file di log che
sono in uso
2013-03-12 15:10:45 full backup started for directory /
2013-03-12 15:30:32 full backup 0 complete, 183494 files, 0
Non sono un esperto di backup, ma così a prima vista consultare il man di
tar per capire a cosa corrisponde l'errore 512 potrebbe aiutare.
Ciao :)
Giovanni
Il giorno 13 marzo 2013 11:00, Nicola Scattolin n...@ser-tec.org ha
scritto:
ciao a tutti,
sto cercando di configurare backuppc per
CIAO !
Chiedo scusa per la risposta semi-ot, ma dato che uso Proxmox su parecchi
sistemi ti chiedo...
Perchè usi backuppc per gestire il backup di proxmox ?
Proxmox 2.3 usa un nuovo strumento di backup, unificato che sfrutta lo
snapshot di qemu 1.4.
E' uno strumento *molto* più efficace di
...@sirm.org ha scritto:
Non sono un esperto di backup, ma così a prima vista consultare il man di
tar per capire a cosa corrisponde l'errore 512 potrebbe aiutare.
A tar exit status of 2 (= 512) is a failure, either fatal or minor. This
is probably something like a file that it couldn't read, or perhaps
In data mercoledì 13 marzo 2013 13:54:56, Nicola Scattolin ha scritto:
Come apro i log (/var/lib/backuppc/pc/localhost/XferLOG.bad.z)?
dabackuppc mi da solo gli eventi e non i singoli file e non si aprono
con notepad++ e non sono veri e propri archivi
Mah, se ricordo bene devi andare in
Il 13/03/2013 15:05, elio marvin ha scritto:
In data mercoledì 13 marzo 2013 13:54:56, Nicola Scattolin ha scritto:
Come apro i log (/var/lib/backuppc/pc/localhost/XferLOG.bad.z)?
dabackuppc mi da solo gli eventi e non i singoli file e non si aprono
con notepad++ e non sono veri e propri
On 13/03/2013 15:40, Nicola Scattolin wrote:
Il 13/03/2013 15:05, elio marvin ha scritto:
In data mercoledì 13 marzo 2013 13:54:56, Nicola Scattolin ha scritto:
Come apro i log (/var/lib/backuppc/pc/localhost/XferLOG.bad.z)?
devi aprire con i permessi di root.
ma zcat, unzip e 7zip non
Il 13/03/2013 19:26, Davide Prina ha scritto:
On 13/03/2013 15:40, Nicola Scattolin wrote:
Il 13/03/2013 15:05, elio marvin ha scritto:
In data mercoledì 13 marzo 2013 13:54:56, Nicola Scattolin ha scritto:
Come apro i log (/var/lib/backuppc/pc/localhost/XferLOG.bad.z)?
devi aprire con i
lo script usando sempre lo stesso snar ma
le cose non cambiano (vedi esempio[*]). È possibile davvero che nessuno
solo noi usiamo tar per il backup?
[*] esempio di script di backup incrementale e conseguente restore.
#!/bin/sh
dirtest=tartest
if [ -d $dirtest ]; then
echo please delete
nessuno
solo noi usiamo tar per il backup?
anche io uso a volte il tar per il backup, ma non ho mai riscontrato
questo problema. Mi sa che devi proprio segnalarlo come bug.
Ciao,
Giuseppe
P.S. Io utilizzo lo stesso snar per tutti i backup della settimana,
specificando però anche il --level
Il giorno Wed, 09 Nov 2011 17:57:58 +0100
Giuseppe Sacco giuse...@eppesuigoccas.homedns.org ha scritto:
Mi sa che devi proprio segnalarlo come bug.
concordo. ho fatto alcune prove con il tuo script, e non ci vedo nulla
di sbagliato (a parte che -g, nel restore, dovrebbe puntare
a /dev/null,
luigi curzi scrisse in data 09/11/2011 19:06:
[...]
quindi immagino sia un bug.
Aperto bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648048
Comunque ora sto migrando i miei script di backup a dar. Mi sembra molto
meglio: supporta gli extended attribute e soprattutto dicono
Sono riuscito a riprodurre il problema e mi chiedo se sono io che
dimentico qualche parametro di tar oppure è proprio un baco... ma così
grave, mi sembra impossibile...
Comunque se volete provare anche voi questo script rivela il problema:
$ cat bin/tartest.sh
#!/bin/sh
dirtest=tartest
if [ -d
Paolo Sala scrisse in data 08/11/2011 09:31:
Sono riuscito a riprodurre il problema e mi chiedo se sono io che
dimentico qualche parametro di tar oppure è proprio un baco... ma così
grave, mi sembra impossibile...
devo dedurre che oramai tar lo uso solo io...
Ciao e grazie lo stesso
Il giorno Tue, 08 Nov 2011 09:31:31 +0100
Paolo Sala piv...@riminilug.it ha scritto:
Sono riuscito a riprodurre il problema e mi chiedo se sono io che
dimentico qualche parametro di tar oppure è proprio un baco... ma così
grave, mi sembra impossibile...
Comunque se volete provare anche voi
Ciao a tutti, ho fatto uno script in cui viene eseguito un backup
completo la domenica e un incrementale gli altri giorni. Per essere più
esplicito la domenica eseguo:
# tar -cz -g dir0.snar -f dir0.tgz path/to/dir
e per il giorno i-esimo successivo dopo aver copiato dir(i-1).snar in
dir(i).snar
Metti uno sleep anche maggiore di 10, per fare un test metti 50.
Molto probabilmente il tar inizia prima che si concluda il blocco
delle istruzioni precedenti.
E' capitato anche a me e ho risolto con uno sleep.
Facci sapere
Il 22 gennaio 2011 10:45, bodr...@mail.dm.unipi.it ha scritto:
Ciao
Ciao,
On Fri, January 21, 2011 6:30 pm, xserver80 wrote:
Ma la cosa strana, davvero strana, è che se richiamo il comando tar
direttamente da shell funziona correttamente senza errore, se richiamo
lo script 2 , che al suo interno esegue il comando tar, direttamente
da shell, nessun errore; se
Buon giorno a tutti.
Vi scrivo per un problema all'interno di alcuni script con tar: se
inserito in uno script che viene richiamato da un'altro script, mi da
errore file changed as we read it ma non su un file, bensì sulla
cartella che gli vado ad indicare come sorgente.
Anche usando la verbose
Il 21/01/2011 16:16, xserver80 ha scritto:
Buon giorno a tutti.
Vi scrivo per un problema all'interno di alcuni script con tar: se
inserito in uno script che viene richiamato da un'altro script, mi da
errore file changed as we read it ma non su un file, bensì sulla
cartella che gli vado ad
On Fri, Jan 21, 2011 at 04:16:57PM +0100, xserver80 wrote:
Buon giorno a tutti.
Vi scrivo per un problema all'interno di alcuni script con tar: se
inserito in uno script che viene richiamato da un'altro script, mi da
errore file changed as we read it ma non su un file, bensì sulla
cartella
e' una domanda che ci siamo posti tutti almeno una volta :)
non e' esattamente un errore e non compromette il risultato, in genere i
file sono in uso e il loro stato puo' variare durante la creazione
dell'archivio stesso, nel mentre tar fa dei controlli su questi file, ed
ecco che quasi
Buongiorno a tutti,
oggi avevo voglia di fare alcuni test per quanto riguarda la creazione
di archivi.
Nasce dall'esigenza di utilizzare entrambi i core per eseguire l'operazione.
Leggendo in giro ho visto che TAR non è utilizzabile su più core, mentre
7zip lo è.
Da premettere che il test
Il 06 ottobre 2009 12.02, Fabio La Farcioli
fabio.lafarci...@molinoalimonti.com ha scritto:
A quanto pare tar nonostante non usi tutti i core sia più veloce. Com'è
possibile??
Voi cosa usate per archiviare grosse quantita di dati in un unico archivio
??
L'algoritmo di 7zip è più lento
Fabio La Farcioli wrote:
Leggendo in giro ho visto che TAR non è utilizzabile su più core, mentre
7zip lo è.
Ecco i risultati dei test:
tar cjf archive.tar.bz2 ./archive
real1m12.805s
user1m8.656s
sys 0m3.876s
7z a archive.7z ./archive
real3m2.910s
user4m35.865s
sys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I 7zip possono essere formidabili, ma possono arrivare a richiedere
grande quantità di memoria nelle operazioni se molto compressi (in
proporzione al guadagno in spazio).
Ovvio che puoi scegliere di comprimerli di meno, ma allora perderesti
uno
ciao a tutti :-)
mi sa di non aver capito na' mazza dell'opzione --listed-incremental=
tar cvf
backup-dati1.tar --listed-incremental=/var/log/backup-dati1.log /var/www/dati1
funziona, e la dimensione archivio e': 16939495
ripeto lo stesso comando e la dimensione diventa: 52609
se tar usa
Pol Hallen ha scritto:
tar cvf
backup-dati1.tar --listed-incremental=/var/log/backup-dati1.log /var/www/dati1
funziona, e la dimensione archivio e': 16939495
ripeto lo stesso comando e la dimensione diventa: 52609
se tar usa backup-dati1.log per verificare gli aggiornamenti della cartella
Googlando ho pescato l'articolo che hai letto :-D ma dico la nostra
privacy eehehehhe
(http://www.zaffa.org/2007/05/29/backup-incrementale-con-tar/)
ahaha
grande, proprio quello! :-)
Così a brucia pelo mi viene da pensare che il log
/var/log/backup-dati1.log non viene modificato
Pol Hallen ha scritto:
da prima delle 9 sto cercando di capire i motivi.. l'account utente e' lo
stesso.. e se tra un po' non risolvo seguo il tuo consiglio e uso rsync :-)
grazie
Pol
Grazie a te invece :-D n'c'avevo mica pensato di usare tar al volo come
backup incrementale
con
Pol Hallen scrisse in data 17/09/2009 10:23:
ciao a tutti :-)
mi sa di non aver capito na' mazza dell'opzione --listed-incremental=
tar cvf
backup-dati1.tar --listed-incremental=/var/log/backup-dati1.log /var/www/dati1
funziona, e la dimensione archivio e': 16939495
ripeto lo stesso
Paolo Sala ha scritto:
Pol Hallen scrisse in data 17/09/2009 10:23:
backup-dati1.tar --listed-incremental=/var/log/backup-dati1.log /var/www/dati1
bhé ma il nome del tar è sempre lo stesso?
Hai ragione ... io pensavo che avesse lanciato lo script con la
parte dati1.tar variabile
Dario scrisse in data 17/09/2009 12:38:
Siccome mi incuriosiva la cosa ho sperimentato. Quello che inganna,
lasciando pensare ad un singolo file
di backup aggiornato, e' la parola incrementale.
Io ho pensato subito ad un unico archivio di backup incrementale, che
invece n file tar
con
Paolo Sala ha scritto:
Tar fa appunto qualcosa in più: ti permette di avere versioni precedenti
di files archiviati... non so i vostri utenti ma i miei utenti o perché
un file è corrotto o non lo trovano più (è stato cancellato) o si sono
pentiti dei cambiamenti fatti, vogliono spesso versioni
Dovresti dare un nome diverso ad ogni backup in modo da avere tutte le
versioni dei file che sono cambiati non solo le ultime versioni.
Spero di essermi spiegato
ho afferrato :-)
credevo che con quell'opzione tar aggiornasse l'archivio presente, ecco
perche' le discordenze di size..
grazie
Ciao,
a tutta la lista.
Scrivo nuovamente sperando in una soluzione; ringrazio anticipatamente
tutti per gli aiuti !
Ho un problema con il comando tar.
Allego comando usato e piccola guida
echo BACKUP di tipo TOTALE, con verifica dei dati scritti ...
echo
# opzioni
xserver80 ha scritto:
tar cvpPWf $DEST_DIR $SORG_DIR -V ${PREFIX}_totale-$DATA.tar
Eseguo quindi un backup su nastro di circa 300 GB e creo quindi un file di
log.
Ho un errore di verifica:
tar: ERRORE DI VERIFICA: trovate 292 intestazioni non valide
tar: Uscita per errore
Mi piacerebbe poter verifacare i dati che vado ad archiviare..
dopo aver ricercato in lungo e in largo non mi è ancora chiaro quale sia il
modo migliore per sapere se i dati sono stati archiviati correttamente.
rsync e' nato a questo scopo :-)
Pol
--
Per REVOCARE l'iscrizione alla lista,
Sto cercando di scrivere un piccolo script per il backup utilizzando il
comando tar.
Mi piacerebbe poter verifacare i dati che vado ad archiviare..
dopo aver ricercato in lungo e in largo non mi è ancora chiaro quale sia il
modo migliore per sapere se i dati sono stati archiviati correttamente
-- Messaggio inoltrato --
Da: xserver80 xserve...@gmail.com
Date: 29 maggio 2009 12.19
Oggetto: Re: problema verifica tar - VERIFY FAILURE: %d invalid header
detected - ERRORE DI VERIFICA: trovate %d intestazioni non valide
A: Lista debian-italian debian-italian@lists.debian.org
Ciao a tutta la lista,
ho un problema con il comando tar.
Allego comando usato e piccola guida
echo BACKUP di tipo TOTALE, con verifica dei dati scritti ...
echo
# opzioni
# c : crea volume
# v : modalità verbose
# p : preserva i permessi
xserver80 scrisse in data 29/05/2009 12:19:
[...]
Nessun suggerimento ?
bhé un file di 150MB non è poi così ingestibile, poi quando hai
individuato la tipologia di riga che ti interessa creare un altro file
tramite grep con le sole righe che ti servono non mi sembra così
difficile... forse
mi sfugge qualcosa.
in effetti ho provato a cercare all interno del file di log, ma tar
con l'opzione di verifica
non mi segnala il problema nel file di log !
Il tar continua la verifica e segnala un exit status diverso da zero e
mi dà il problema segnalato sopra
Ciao
Piviul
--
Per
Ciao a tutta la lista,
ho un problema con il comando tar.
Allego comando usato e piccola guida
echo BACKUP di tipo TOTALE, con verifica dei dati scritti ...
echo
# opzioni
# c : crea volume
# v : modalità verbose
# p : preserva i permessi
Ciao a tutti, con tar quando archivio alcune directory su una
condivisione cifs ricevo alcuni warnings su alcuni file: 'attenzione, il
file è cambiato mentre lo stavo leggendo'. Se però vado a vedere le
statistiche con stat su uno di tali files vedo che la data di creazione
e ultima modifica si
Paolo Sala scrisse in data 20/03/2009 15:31:
Ciao a tutti, con tar quando archivio alcune directory su una
condivisione cifs ricevo alcuni warnings su alcuni file: 'attenzione, il
file è cambiato mentre lo stavo leggendo'. Se però vado a vedere le
statistiche con stat su uno di tali files vedo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il giorno Fri, 20 Mar 2009 15:31:26 +0100
Paolo Sala piv...@riminilug.it ha scritto:
Ciao a tutti, con tar quando archivio alcune directory su una
condivisione cifs ricevo alcuni warnings su alcuni file: 'attenzione,
il file è cambiato mentre lo
skizzHG scrisse in data 20/03/2009 16:00:
Il giorno Fri, 20 Mar 2009 15:31:26 +0100
Paolo Sala piv...@riminilug.it ha scritto:
Ciao a tutti, con tar quando archivio alcune directory su una
condivisione cifs ricevo alcuni warnings su alcuni file: 'attenzione,
il file è cambiato mentre lo
Buongiorno a tutti!
scusate l'intrusione, ma ho un problemino strano, questo è il mio
script di backup:
tar -cvf /shared/backup/`date|awk '{print $6$2$3}'`_GAInt_backup.tar
/shared/ufficio/
niente di strano e ha sempre funzionato, ma da settimana scorsa come
potete vedere, genera files di
Roberto su tiscali wrote:
la cartella è sempre la stessa e ovviamente tende ad aumentare non a
diminuire le sue dimensioni, ma la cosa più strana è che se lancio lo
script a mano genera un tar di 350 - 400 mb se da crontab 20-30 consigli?
questo potrebbe essere dovuto al fatto che il cron
Ho fatto il tar sul mio disco di rete e dopo un po' quando tarro la home
mi dice che ho superato il limite del file e precisamente si ferma a
2147483647.
Il file system del disco di rete utilizzando l'interfaccia http del
produttore è xfs se vado a vedere il log del disco pare ext3 infatti
Il giorno lun, 29/01/2007 alle 16.35 +0100, [EMAIL PROTECTED] ha
scritto:
Comunque come posso superare questo problema ?
il problema penso sia del protocollo di rete.
Ad esempio con samba hai un limite di di 4GB se non erro...
--
Davide Corio
si è fermato a due giga...
strano...
Il 29/01/07, [EMAIL PROTECTED][EMAIL PROTECTED] ha scritto:
Ho fatto il tar sul mio disco di rete e dopo un po' quando tarro la home
mi dice che ho superato il limite del file e precisamente si ferma a
2147483647.
--
Usate BCC!
La paura ha creato gli dei
Il giorno lun, 29/01/2007 alle 16.41 +0100, Luca Costantino ha scritto:
si è fermato a due giga...
strano...
Il 29/01/07, [EMAIL PROTECTED][EMAIL PROTECTED] ha scritto:
Ho fatto il tar sul mio disco di rete e dopo un po' quando tarro la home
mi dice che ho superato il limite del file e
Davide Corio ha scritto:
Il giorno lun, 29/01/2007 alle 16.41 +0100, Luca Costantino ha scritto:
si è fermato a due giga...
strano...
Il 29/01/07, [EMAIL PROTECTED][EMAIL PROTECTED] ha scritto:
Ho fatto il tar sul mio disco di rete e dopo un po' quando tarro la home
mi dice che ho superato il
Il giorno lun, 29/01/2007 alle 16.54 +0100, [EMAIL PROTECTED] ha
scritto:
ah si...è 2GB il limite :)
Quindi cp -avx ??
Io uso star al posto di tar.
Bye.
--
Alessandro Pellizzari
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
[EMAIL PROTECTED] con oggetto
Alessandro Pellizzari ha scritto:
Il giorno lun, 29/01/2007 alle 16.54 +0100, [EMAIL PROTECTED] ha
scritto:
ah si...è 2GB il limite :)
Quindi cp -avx ??
Io uso star al posto di tar.
Bye.
Però con star non risolvo il problema dei 2Gb di limite, con cp -avx
invece sì. Perché l'intero
ti conviene risolverlo,
altrimenti la volta che hai un'immagine ISO di un DVD sei fregato.
Mi pareva strano che tar avesse un limite di 2 Gb, visto che lo uso per
i backup su cassetta da 30 Gb... :)
Bye.
--
Alessandro Pellizzari
--
Per REVOCARE l'iscrizione alla lista, inviare un email
e` un problema di filesystem, e ti conviene risolverlo,
altrimenti la volta che hai un'immagine ISO di un DVD sei fregato.
Mi pareva strano che tar avesse un limite di 2 Gb, visto che lo uso per
i backup su cassetta da 30 Gb... :)
Bye.
Nella mail di Davide mi dice che è un limite di samba e
pacmo wrote:
Davide Corio ha scritto:
Il giorno lun, 29/01/2007 alle 16.41 +0100, Luca Costantino ha scritto:
Il 29/01/07, pacmo ha scritto:
Ho fatto il tar sul mio disco di rete e dopo un po' quando tarro la
home
mi dice che ho superato il limite del file e precisamente si ferma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In data 29/01/2007 20:35 Davide Prina ha scritto:
penso che la compressione avvenga durante la creazione del file e non
alla fine ... o sbaglio?
Penso anche io... la prima che hai detto.
- --
Uranium per Capsule Corp. con Debian
ma tar non si occupa solo di aggregare i file in un unico archivio che viene
poi compresso?
-Original Message-
From: Uranium [mailto:[EMAIL PROTECTED]
Sent: Mon 29-Jan-2007 8:37 PM
To: Davide Prina
Cc: debian-italian@lists.debian.org
Subject: Re: Limite grandezza file tar
-BEGIN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In data 29/01/2007 20:44 Premoli, Roberto ha scritto:
ma tar non si occupa solo di aggregare i file in un unico archivio che viene
poi compresso?
Penso che tar, cosi come rar o zip, ecc, ecc sia capace di occuparsi
direttamente anche della
Ciao a tutti!
Vi scrivo perchè sto provando da un pò a fare un backup
della partizione /dev/hda3 (circa 5 Gb) con il semplice tar
da riga di comando ma si interrompe dicendomi che ha superato
le dimensioni previste del file.
Potete dirmi se si può aggirare questo errore?
Oppure come faccio
Vi scrivo perchè sto provando da un pò a fare un backup
della partizione /dev/hda3 (circa 5 Gb) con il semplice tar
da riga di comando ma si interrompe dicendomi che ha superato
le dimensioni previste del file.
Non ho mai provato ma:
dimensioni previste del file e' inteso come limite del
lucakodo wrote:
Vi scrivo perchè sto provando da un pò a fare un backup
della partizione /dev/hda3 (circa 5 Gb) con il semplice tar
da riga di comando ma si interrompe dicendomi che ha superato
le dimensioni previste del file.
Potete dirmi se si può aggirare questo errore?
dipende molto da
Lucio Crusca ha scritto:
[...]
# mkfifo sqldump
# mysqldump --opzioni sqldump
# tar czp /etc /home sqldump | netcat [tunnel-di-ssh]
che però non funziona, ovvero tar non mi legge il contenuto della pipe
sqldump. Sapete se esiste un modo per farglielo leggere?
Scusa ma non capisco una cosa
1 - 100 di 268 matches
Mail list logo