Newsgroup: it.lavoro.professioni.webmaster
Titolo: spostare sito di medie dimensioni

ho provato a afre un .tar e a ricopiarlo su nuova locazione e 
decomprimerlo ma mi ha dato errore.
L'archivio TAR viene circa 700 Mb.
Mi pare abbastanza improponibile di fare via ftp con cartelle e sotto 
cartelle, altro metodo cper fare un file unico da scompattare altrove 
mantenendo struttura e permessi?
Server con linux

 mantenendo struttura e permessi?
Ho spostato vari siti, un paio anche grandi, con il tar, e non ho mai 
avuto problemi... che errore ti da ?
Potresti provare, se il server lo supporta, ad usare scp

 mantenendo struttura e permessi?
specificare a cosa hai accesso non farebbe male:
hai una shell ? (risposta: no)
che linguaggio/i puoi usare?

 Potresti provare, se il server lo supporta, ad usare scp
come comando esiste ma non ci sto a capire come comprimere una directory 
e trasferirla.
-bash-3.2$ scp
usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
            [-l limit] [-o ssh_option] [-P port] [-S program]
            [[user@]host1:]file1 ... [[user@]host2:]file2
-bash-3.2$
Mi tocca googlare :D

 che linguaggio/i puoi usare?
nessuno perché non li conosco, ma casomai un comando di linea?

decomprimerlo ma mi ha dato errore.
"Mi ha dato errore" non è una informazione fungibile[1]. Cosa è successo?
In aggiunta e non in sostituzione alla domanda di cui sopra: fai un md5 a
quel file tar, prima di inviarlo (sulla macchina origine) e dopo l'arrivo
(sulla macchina destinazione). Giusto per essere sicuri.
Leonardo
[1] cioè, ti posso rispondere "Ci sarà un problema, correggilo": ma, come
    vedi, non è molto utile come suggerimento.
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

per creare il tar
tar czf file.tgz directory/
per aprire il tar
ti posizioni nella directory e dai
tar xzf file.tgz
(puoi anche togliere la z da entrambi i comandi ma non ci sarà la 
compressione, quindi il file potrebbe essere più grande)
il file.tgz lo devi spostare usando ftp in modalità BINARY altrimenti 
è... sputtanato...
puoi creare un checksum sui file prima e dopo il trasporto con:
md5sum file.tgz
e verificare che il risultato sia lo stesso
se non sai cos'è ssh... lascia stare...


Si forse il suggerimento di controllare il metodo di trasfermimento ftp 
è utile, in quanto l'ho impostato du automatico ma forse non capisce 
bene il progamma, oltre che io, ovviamente!

 ssh
ah ma allora è tutto molto + semplice!
intanto invece di archiviare e basta ti consiglio anche di comprimere, 
per non sprecare banda e spazio su disco.
tar cvzf per comprimere
tar xvzf per decomprimere
adesso le domande:
- hai i permessi per scrivere in tale directory? (dico con l'utente ssh 
non con quello ftp)
- hai verificato che ci sia abbastanza spazio per decomprimere il file?
- il tar di partenza e di destinazione sono gli stessi?
- il file system di partenza e di destinazione sono gli stessi?
- provato ad uppare con sftp? ( sftp user@host poi dai la pwd, poi dai 
"put nomefiletar")
- hai provare qualche esperimento con file di prova? tipo tarra una dir 
piccola con qyualche file, trasferiscila e vedi se su quell'archivio 
continua a non funzionare.
- boh

nessuno perché non li conosco, ma casomai un comando di linea?
Test:
cd "/path/da/backuppare" && tar cjf - . \
| ssh -o Compression=no -c arcfour utente@macchinaB \
'cd "/path/per/il/restore"; tar tjv'
Sul serio:
cd "/path/da/backuppare" && tar cjf - . \
| ssh -o Compression=no -c arcfour utente@macchinaB \
'cd "/path/per/il/restore"; tar xjv'
Tu prova. Magari funziona ]:-D
Leonardo che garantisce freschezza, non verità


 Compression=no -c arcfour
come mai queste?
soprattuto la specifica sul cipher.




La non compressione dipende dal fatto che il flusso dati è già compresso
da bzip2, con una finestra BWT che alle capacita' di SSH fa come il Mike
Tyson a Woody Allen. A quel punto, mettere la compressione in SSH è solo
un di più, si spreca CPU e basta.
Se la CPU ricevente costa (Amazon?) o fa schifo, può valere la pena fare
un tar in chiaro e comprimerlo via SSH: comprime molto meno ma pesa meno
sulla CPU d'arrivo. Non ho fatto gran prove comparative, pero'.
Per il cipher, be', su un'architettura P4 e' il cipher che costa meno, e
in particolare meno dell'AES che era IIRC il default della mia distro.
Prova a fare
	scp -o Compression=no -c arcfour filelocale
macchinainretelocale:/tmp/zot
e
	scp -C filelocale macchinainretelocale:/tmp/zot
e guarda come si comporta rispetto al default tuo.
Su una macchina che ho qui sottomano, ottengo 96 Mb/s e 9 Mb/s, fai te.
D'altra parte, verso una macchina remota via ADSL farlocca ottengo, con
gli stessi parametri, 530 Kb/s e 1.7 Mb/s (perché il file e' un tantino
compressibile). -c arcfour mi lascia a 1.7 Mb/s perché il bottleneck e'
cosi' talmente schifosamente tanto sull'ADSL, che potrei far lucidare i
bit uno ad uno dai frati praliti dell'eremo di Pimpandoli, con tempo da
buttare.
Riassumendo, IMHO, -c arcfour sempre, -C per flussi generici, zero comp
per flussi compressi. Si', OK, ci si rimette du' citti in sicurezza, ma
dubito che Echelon venga mai a titillarvi i bit e si faccia scrupoli di
patire su ArcFour più che su 3DES o Rijndael/AES. Nel caso riòrdate, la
NSA legge XKCD.
 
http://xkcd.com/538/
	]:-D
Leonardo



Avevo già fatto altri e due siti, il server è identico solo che questo è 
più vicino e veloce.
Forse è l'eccessivo numero di cartelle che mi frega, il file risultatne 
anche comresso risulta 1,6 Gb


Alla fine non mi ha dato errore con questo procedimento, che differisce 
solo per la compressione rispetto a quello che facevo io.
Poi il database ha a dato il suo da fare (era 130Mb) ma ora è tutto a 
posto...