Ciao a tutti!
Avendo la Root del peso di circa 2GB (tra foto e quant'altro...), mi si presenta la necessità di trovare una maniera il più veloce e sicura possibile (tenendo conto che ho una connessione Fastweb 6MB...) - credo che usando FileZilla mi ci vorranno 2/3 giorni tra Download e Upload e da qui, è partita la la mia ricerca verso un metodo + veloce e sicuro...
Ho iniziato ad informarmi un pochino e, devo dire, che anche qui (come nei Backups del DB MySQL...), ho scoperto delle cose interessanti circa modalità e diversi sistemi...
Mi sono imbattuto in "WinSCP" > http://winscp.net/eng/docs/lang:it ...è una valida alternativa a FileZilla?
Sono su DH (Shared Hosting...) - dal pannello di controllo, posso mettere il "Flag" sulle cartelle che mi interessano e fare il download sul mio PC (ogni cartella me la salva in formato ZIP) - mi chiedo se flaggando la cartella principale "miosito.com" e facendo partire il download (sul mio Desktop...) sia la cosa migliore da fare oppure usare i metodi sopra citati e, in particolare SFTP
Insomma, il rompicapo è questo... qualcuno ha consigli e/o soluzioni per gestire questa faccenda nel modo + veloce?
Grazie
Ciao
Kipper
In termini di sicurezza SI poiché WinSCP viaggia su protocollo SSH quindi è criptato, ma di conseguenza avrai un evidente calo di prestazioni rispetto all'FTP (che è in chiaro) per via della crittazione dei dati.
Sostanzialmente penso che tolte le cartelle di sistema di Drupal (sistema,moduli e temi vari) una volta zippati occupano poco, il problema sono le immagini e i file vari, qui andrei di FTP tradizionale un po' alla volta con FileZilla.
Quando sono in ballo un enorme quantità di file, bisogna trovare strategie diverse - FTP diventa un problema invece di una soluzione.
Qui la strategia è di calcolare cosa è cambiato fra i due file system. Ci possono essere migliaia di file e centinaia di indirizzi, ma magari sono cambiati (creati, modificati, o cancellati) solo una piccola percentuale di questi fra un backup è l'altro.
La soluzione che uso io è ssh insieme con rsync. Ma questo significa sapere a priori che il hosting offre entrambi questi servizi lato server (rsync è un app client-server quanto ssh). In questo modo viene prima costruito una lista di cambiamenti fra i due file system, poi una serie di commandi per sincronizzare l'uno al l'altro.
Nella stessa maniera, per fare un backup del file system in locale, io mi trovo bene con rdiff-backup che oltre a copiare i file mantiene la differenza 'alla rovescia', che permette di ricostruire i fs com'era diciamo 5 giorni fa.
Più imparo, più dubito.
Ciao sylpheed!
Sono d'accordo con il tuo metodo:
1. Salvare Drupal (sistema,moduli e temi vari) da Pannello di Controllo DH in formato ZIP - anche perchè ho notato che facendolo con FileZilla (selezionando le cartelle...) non vengono salvati es. .htaccess e altre cose... mentre in formato ZIP, viene conservato tutto il contenuto...
2. Andare di FTP per il resto (immagini, video etc...)
Grazie molte
Ciao
Kipper
puoi spiegarmi come fai a comprimere tutti i file in un file zip?
quale sarebbe il pannello di controllo DH?
Ciao John!
Mi hai anticipato mentre rispondevo al post dell'amico sylpheed... quando ho inviato il mio post di risposta, ho visto che avevi postato anche tu anticipandomi...
hmmm... vedrò di mettermi al lavoro la prossima settimana sulle tue solite preziose info/dritte - adesso sono in vacanza e rientro tra 2 giorni...
P.S. Contrariamente a quello che ti avevo detto in un post di 3 settimane fa (circa...), dove dicevo di essere costretto a starmene a milano per via della mancanza di connessione internet nel micro-paesino abruzzese > http://www.cmvalsangro.it/Comuni/comune-di-monteferrante (ho la casa dei suoceri non la calcolosi renale... grazie a Dio...) ...sono riuscito a fare un'acrobazia:
Nel paese ho un amico esperto di reti e cablaggi che mi ha gentilmente offerto una porta nel suo Modem-Ruter - per farla breve, ho comprato un cavo LAN di 70MT (settanta metri) e, da casa sua (per tetti, canali etc...) l'ho fatto arrivare da me... cosa non si fa per Drupal!
Grazie di nuovo
Ciao
Giuliano
Chiedo scusa, volevo dire il pannello di controllo FTP di DH - si dice così?
Ciao
Kipper
D'accordo con l'uso di rsync ed affini.
Chiaramente è meglio un "backup differenziale" quando si può.
http://www.sanisapori.eu
continuo a non capire, forse intendi il cpanel? ma da li come si fa a comprimere il tutto in un file zip?
mi interesserebbe saperlo perchè via filezilla ci metti una vita a farti un backup.
Se non si sono capite bene le parole di Kipper, "DH" sta per Dreamhost. E' una funzione del loro pannello di controllo. La offrono anche altri provider, ma non tutti.
http://nuvole.org
http://youthagora.org
FileZilla non salva (e non mostra) i file nascosti, ed .htaccess è un file nascosto. Per salvarli bisogna andare nel menu Server ed attivare "Visualizza file nascosti".
ahhhhhh... chiedo scusa non avevo capito che era dreamhost.
uso siteground e non da quel pannello, cioè da solo cpanel, ma mi sembra che da li non ci sono opzioni similari.
Ma sii... l'FTP server... i file dalla root si possono visualizzare in due modi:
1. Con un client FTP (FileZilla etc...)
2. Direttamente dal server FTP del Provider - Ciascun Provider ne ha uno suo...
Nel mio caso (dreamhost.com), a sinistra di ogni cartella c'è un checkbox che, una volta selezionato, si ha la possibilità di fare determinate operazioni sulla cartella stessa (Permessi, Copia, Incolla, Download etc...)
Cosa intendi con "backup differenziale"? abbi pazienza...
Grazie per la dritta... non ci avevo mai pensato a questa funzione...
Approfitto per chiedere una cosa:
Premettendo che se seleziono una o più cartelle "poco pesanti" (2/3MB...) e faccio il download sul mio pc mi vengono salvate senza problemi in formato ZIP, ho fatto una seconda prova su una cartella di circa 300MB e il download è andato in time-out e adesso, quando accedo al server, cliccando su quella cartella, appare al top il seguente messaggio che è un avviso per il limite di download per i files di grosse dimensioni - il problema è che non riesco ad eliminarlo; ho provato a fare anche "Kill all Ftp Session" ma niente, il messaggio persiste...
Qualcuno ne sa qualcosa per farlo sparire? ...lo so, apro un ticket a DH, ma visto che ne stiamo parlando magari qualcuno ha una risposta al "volo"...
http://www.giuliweb.com/img_drupalitalia/pppdf5g4dfg4f.jpg
Ciao
kipper
Anch'io ho un dominio su siteground - Al momento non ho nessun sito ma tempo fa ho installato Drupal e, dopo il salvataggio (View, Story etc...), mi apparivano molte schermate "completamente bianche" - però le modifiche venivano regolarmente salvate e visualizzate dopo un refresh... Hai anche tu riscontrato problemi di questo tipo?
P.S. Sono sinceramente rimasto un po deluso da Siteground nel senso che ho inviato una mail per segnalare questo problema e non mi ha risposto mai nessuno, boh...
Ciao
Kipper
no deluso, ma mi sono sentito preso in giro perchè hanno fatto la stessa cosa con me. ti allettano con prezzi bassi e poi ti abbandonano.
uso siteground finchè non mi scade poi lascerò perdere sinceramente.
A me dicevano che le pagine vianche erano dovute alla pesantezza di drupal e consigliavano di usare wordpress. :(
per il sito dell'azienda dove lavoro abbiamo utilizzato uno script bash sul server che comprime il contenuto della cartella sites e esporta il db (avendo un vps linux tutto é possibile :)) e copiamo il tutto in locale, con rdiff-backup appunto. Il vantaggio é che copiando solo le differenze tra la copia online e quella locale si diminuisce di molto il volume di file trasferiti. Non ho mai provato peró credo che sia possibile dire a rdiff-backup di copiare direttamente i file di drupal,forse su questo john ha piú esperienza.
Follow me @DarthDrupal and @Dinamicamente.org
Dinamicamente.org
ok, mi hai dato la conferma di quella che era una mia sensazione/intuizione...
Grazie
Ciao
Kipper
A questo punto giriamo la boa, ed alziamo lo spinnaker. Abbiamo parlarto quasi esclusivamente di backup, dimenticando il suo fratello gemello, restore.
Il buon Darth (attendiamo con ansia il nuovo logo) e jscm hanno cenato dei discorsi interessante. Prima jscm che ha parlato di backup incrementale. Stile Vindoze. Cosa vuol dire? Semplicemente che fai, diciamo una volta alla settimana un backup completo (full), poi per le altre sei giorni fai un backup incrementale (cioè solo quello che è cambiato dal backup full). Così risparmi spazio, ma se devi fare un restore al sesto giorno, devi: fare il restore dal full, poi da ogni backup incrementale rigorosamente in sequenza. Hmm.
Darth ha parlato di creare un script compremendo il sito. Anch'io facevo così fino a qualche mese fa. La pratica (almeno il mio) è di estrarre il DB come testo (mysqldump - n commandi SQL) metterlo nel filepath di Drupal, o nel commando di compressione (gzip di solito), poi compremere tutto il filepath di Drupal ed il file SQL, trasferirlo per poi scompattarlo in locale, e fiondare l'SQL nel DB locale. In questo modo replici un installazione Drupal da un server su un altro - dal server al locale, oppura anche viceversa. Ma quando inizi ad aggiungere tanti immagini (che sono già compressi) o peggio file audio e video (anche loro compressi), questa tattica diventa controproduttivo. Se 80% del file system sono immagine, audio e video (non difficile oggi giorno) allora comprimi poco, e spedisci un file veramente enorme (> 50MB) - anche se non è cambiato niente.
Ma poi c'è Drush (scusate se linko - dal verbo linkare - ad un thread mio), che - insieme a qualche amico del LUG di Villafranca - mi ha fatto cambiare idea. Specificamente ssh e rsync (entrambi obbligatorio per questo discorso). Anche Drush sul server è obbligatorio se vuoi seguire questa strada.
Per rispondere a jscm: anche rsync è in un certo senso un backup incrementale - controlla cosa è cambiato, poi trasmette questi differenze. E' meglio di un backup full/diff, perchè il risultato è due file system perfettamente synchronizzati, al costo di spedire le differenze, più un pò di protocollo extra (le liste di differenze, il controllo md5, ecc). Veramente straordinario.
Quindi io ho semplicemente buttato (sorridendo) i miei script bash nel grande cestino universale, perchè lo fa già tutto Drush. Essenzialmente separa le operazioni: DB tramite mysqldump ed rsync, e poi backup file system tramite rsync. Sono separati probabilmente per essere più flessibile.
Dove sta il 'salto di qualità' è negli alias - almeno per me. Creando un unico file alias, posso usare lo stesso script per fare questo operazione su più siti, anche su più server - basta che ci sia ssh e rsync. E la gioia sta nel fatto che se inverti gli alias, allora stai faccendo un restore.
Una volta in locale, puoi usare quello che vuoi per backupare, er, il backup. Su disco rimuovibile, o su cloud - come cenato da Mavimo.
Tutto ciò esclude Arrabbia, et al. Ma cosa pretendi per €30 al anno? Un servizio professionale? Se vogliono fare profitto a quei prezzi devono avere una politica 'è così e basta' e non rispondere ai ticket. Oppure impiegare le schimmie. Forse entrami le cose.
Io faccio un calcolo 'alla rovescia'. Se impiego un ora (Arrabbia) per fare quello che faccio (io?) con Drush in dieci minuti su un sito professionale, quanto costa quei 50 minuti in più? Facciamolo 10 volte all'anno? Sono 500 minuti. Pago €80 al anno in più ben voluntieri per risparmiare un giorno lavorativo - che nessuno mi paga (bene). E poi lo facciamo molto più volte all'anno... O sono io che sbaglia in continuo? ;-)
Più imparo, più dubito.
a forza da sentirne parlare non mi rimane che provarlo questo drush!!
@Mr John: ho giá aggiornato l'avatar con il super darth drupal ;)
Follow me @DarthDrupal and @Dinamicamente.org
Dinamicamente.org
Great! :)
Ciao John,
Avendo ormai superato la barriera del dolore per quanto riguarda Drush e i Backup/Restore del DB nonchè l'uso dei vari comandi "disarmanti" per velocità e semplicità (ringraziando ancora l'amico Pescetti, tu John e Bohz... forse anche altri, scusate se non ricordo tutti al momento...), mi ritrovo (in maniera del tutto naturale ed automatica...) ad avere la stessa necessità di un altrettanto sistema di Backup/Restore (interessantissima la variante "incrementale...") della Root di tutti i miei siti - in particolare ho una Root che tra Foto, Video etc... pesa circa 1.2GB...
Credo che dovrò affrontare e superare un'altra barriera del dolore per configurare/installare/imparare e usare "rdiff-backup-1.2.8.tar" e "rsync-3.0.6-3.0.7.diffs" (credo siano questi gli applicativi in questione... se ho capito bene...) - li ho scaricati da:
http://www.samba.org/rsync/download.html
http://rdiff-backup.nongnu.org/
Affiancarli al mio Drush su DreamHost credo non ci siano problemi però avrei bisogno di supporto pre-installazione perchè al momento attuale è come se stessi entrando in un'aula per la prima lezione di Arabo...
Da dove inizio? ...qual è la prima lettera dell'alfabeto Arabo?
P.S. Mi interesserebbe un tuo parere su questo > http://code.google.com/p/ftpsync2d/
P.S.2. Questo LUG di Villafranca mi ha messo un pò di curiosità ;-)
Grazie
Ciao
Kipper
Vedi http://www.drupalitalia.org/node/10803#comment-34968
Puoi tenere rdiff-backup fuori del server - è sufficiente rsync.
Usi rdiff-backup per backupare i files sincronizzati sul tuo PC. (Questo Linux Day cercerò di convincere la gente di usare questo programma proprio per fare il backup su disco USB)
Più imparo, più dubito.
allora, sto già operando e mi sono recato qui dove apparentemente non vedo dei grossi problemi; come primo approccio sembrerebbe abbastanza semplice ma, tuttavia, ho alcune cose da risolvere prima di installare un nuovo Drupal in un dominio.org "vuoto" su DH e procedere con l'esecuzione della "sincronizzazione server/pc" e del "backup".
1.
rsyncè installato di default su DH o va installato come con Drush - tanto per capirci... (mi sembra di aver capito che viene riconosciuto il comando e quindi NIENTE Installazione o sbaglio?)2. Nel primo comando "
rsync -e ssh -av [email protected]:remote_directory local_directory", la stringa di esempio "remote_directory" a cosa è riferita alla Root Principale e cioè posso fare un replace da "remote_directory" a "miosito.org" e mi fa il backup di quella Root? Posso anche mettere se volessi fare un Backup di una sub-directory es. "miosito.org/mie_immagini"? è così che funziona?Rimane da chiarire come devo fare per creare (e come dargli un percorso sul mio PC...) alla directory locale "
local_directory" sempre presente nel comando (alla fine...)3. Questo comando "
rsync -e ssh -av [email protected]:www/ backup/", se ho capito bene, dovrebbe fare il Backup della Root es." miosito.org", ma la domanda è la stessa:Come faccio a creare una directory sul PC in modo che venga riconosciuto il percorso di destinazione dal comando?
Spero di essermi spiegato...
Comunque mi sembra sia meno doloroso di quel che pensavo... credo... spero...
Dopo alcune operazioni con Drush sembrerebbe che i "comandi da Shell" facciano meno paura...
Grazie
Ciao
Giuliano
Linux lesson #10,345...
Bisogna ricordare che rsync (di solito) funziona come applicativo client server - pensa Browser/Apache. Questo non è necessario quando sincronizzando indirizzi dove sorgente e destinazione sono nello stesso filesystem (hard disk a disco usb per esempio), ma è sicuramente il nostro caso dove il sorgente sta sul nostro server, e destinazione sul nosto PC (o viceversa).
Per capire se rsync (o un qualsiasi altro programma linux) è installato io di solito uso il nome seguito da --help:
rsync --helpse da un risultato allora è installato ;-) Nota che deve essere installato sia sul server che sul tuo PC.
Per capire se il daemon è installato e sta girando (solo sul server) bisogna usare ps insieme con grep.
Se vuoi vedere tutti i processi attivi basta digitare:
ps auxma se come la lista è lunga, meglio usare un pipe e passare i risultati tramite grep:
ps aux | grep "rsyncd"se ti da una riga di informazione rsyncd (il daemon - server - di rsync) sta girando, altrimenti no.
Tutte gli operazioni vanno eseguito sul tuo PC, quindi il percorso usato sarà uguale a come fai in locale. Per l'indirizzo remoto però bisogna prependere il nome della macchina e scelgere un protocollo. Nel tuo esempio stai usando ssh per il protocollo e il percorso sarà user@nome_macchina, per esempio [email protected]. Dato che il commando apre una sessione ssh (e lo chiude alla fine), ti sarà chiesto il password per quel utente - ogni volta che usi il commando.
Here endeth the lesson.
Più imparo, più dubito.
Thanks John, I really appreciate it.
La situazione su DH è questa, tu che dici:
P.S. Ho provato i comandi sia da Server che da
cd miosito.orge il risultato è sempre uguale, è OK!Su server credo sia installato - qui il risultato del comando "rsync --help"
Come faccio a sapere se è installato su PC? Come lo installo su PC se non dovesse esserci?
Non capisco questo step... potresti gentilmente usare un approccio diverso per farmelo comprendere?
Grazie
Ciao
Giuliano
Avanti...
In realtà non sta girando - quello che vedi è il processo che cerca per il daemon. Un pò come fotografare uno specchio insomma.
La buona notizie è che non serve il daemon, o meglio serve per altre cose - non l'ho trovato neanch'io sul mio server.
La lista viene troncato in larghezza - basta specificare ps auwx se vuoi vedere tutto.
Si, c'è e come!
Uhm, installandolo? http://www.samba.org/rsync/download.html. Se sei Vindowsiano, hai bisogno di cwRsync (sicuramente non c'è). Se Linuxiano, sinceramente non mi ricordo se c'è di default nel distro, altrimenti
apt-get install rsyncè il tuo amico.Ho due computer - il mio (che chiamerò locale) è quello del server (indovina...). In realtà stiamo parlando di filesystem qui, ma va bene cosi.
Se io voglio sincronizzare un indrizzo su locale dal server, o viceversa, lo faccio lanciando il commando sul mio PC (locale).
Allora se sul server l'indirizzo è /home/user-jhl/www, e sul mio PC è /home/john/backups/server devo specificare:
rsync -avz --delete -e "ssh" [email protected]:/home/user-jhl/www/ /home/john/backups/server/dove:
-avz --delete -e "ssh"sono gli opzioni archivio, verboso, compressione, cancella files in destinazione, e protocollo[email protected]:/home/user-jhl/www/è il percorso allo sorgente (sul server)/home/john/backups/server/è il percorso alla destinazione (sul mio PC)OT: Qualcuno usa opzioni diversi/migliori?
Più imparo, più dubito.
Ciao John,
riprendo questo vecchio (ma credo attuale...) thread per esporre alcuni risultati che ho raggiunto attraverso test e ricerche e, come al solito, vorrei un tuo parere (se ce ne sono altri ben vengano ad unirsi a noi...)
Ormai lo sai, a me piace sperimentare, andare fuori rotta, rientrare, accorgendomi di aver scoperto cose nuove etc etc... hai detto che per i Windowsiani (uso anche OSX ma al momento non ho trovato soluzione...) ci vuole cwRsync, l'ho trovato un pò incasinato nell'installazione/configurazione ed allora ho optato per Cygwin... l'ho configurato (aggiungendo le reposity necessarie in fase di install...), ho aggiunto la porta 22 (SSH) al mio Firewall (Uso XP SP3...), abilitato i "servizi" etc etc...
Apro il terminale Cygwin e configuro un pò di cose:
chown kipper:root /var/logchmod a=rwx /var/log
chmod +r /etc/passwd
chmod +r /etc/group
chmod 777 /var
net start sshd
netsh firewall add portopening protocol=TCP port=22 name="My_SSH(22)" mode=ENABLE scope=ALL
...lancio ancora il terminale dall'icona Cygwin sul desktop e inizio:
Il tuo esempio funziona!
rsync -avz --delete -e "ssh" [email protected]:/home/user/miosito.com/cartella_prova/ /cygdrive/c/kipper/backupsPer "uploare" i files da locale a remoto faccio così:
rsync -e ssh -av /cygdrive/c/kipper/backups/ [email protected]:miosito.com/nuova_cartellaCopio anche i file da Locale >>> Locale:
rsync -rtuvz --delete /cygdrive/c/cartella_01 /cygdrive/c/cartella_02Ritornando sul discorso di sincronizzazione files Remoto > Locale volevo sapere se il tutto è affidabile anche se uso Cygwin ...io mi ci trovo molto bene - sono sicuro che il backup dei files della mia root remota una volta copiati in locale siano "realmente" pari pari (1:1) e che non ci siano potenziali problemi di files "corrotti" o non copiati perchè magari bloccati da alcuni permessi sul server??? ...ho controllato alcuni files (.htaccess - setting.php etc etc... e me li ha copiati senza problemi...) insomma, usando Cygwin va ugualmente bene o è meglio usare (come suggerito da te...) cwRsync - che differenza c'è tra i due approcci... in fondo è un terminale che ti permette di interfacciarti con il tunnel SSH, non penso ci siano problemi e poi, da quanto credo di aver capito di Linux, se uno script fa partire un'operazione senza che vengano segnalati degli errori dovrebbe essere ok giusto? ...una cosa o va o non va, da quello che credo di aver capito; altrimenti viene segnalato...
...ho fatto decine di prove in download e in upload sui soliti siti test e mi sembra che tutto funzioni bene... che dici? procedo così???
Per quanto riguarda rdiff-backup sono ancora in alto mare nel senso che non ci ho ancora messo la testa... appena ho tempo vedrò anche quello... può essere eseguito con il prompt di Cygwin come rsync? ...se si hai qualche comando o delucidazione?
Attendo eventuali pareri/osservazioni/consigli da tutti (come al solito...)
Ciao a tutti
mah... leggendo bene >>> http://it.wikipedia.org/wiki/Rsync mi sembra di capire che la strada di Cygwin è ok ma c'è una nota nella descrizione sotto Windows che non mi fa stare tranquillo e cioè:
Tuttavia, va notato che si possono verificare dei piccoli problemi usando rsync fra macchine con diversi sistemi operativi, in particolare per quanto riguarda le date di modifica dei file, l'accuratezza con cui vengono trasmesse alcune informazioni ausiliarie sui file (proprietario, diritti, ecc.) e le possibili ambiguità fra nomi di file in maiuscolo e minuscolo su Windows.Mi sa che dovrò preparare un PC al volo con installato Ubuntu... gli esperti cosa mi suggeriscono e cosa ne pensano di questa descrizione abbastanza allarmante riportata su Wikipedia???
Grazie in anticipo
Ciao
Kipper
Il problema non è usare sistemi operativi diversi, ma usare filesystem diversi. Il rischio di corruzione file non c'è (rsync è fatto apposta). Tuttavia, ci sono casi limite in cui il tuo filesystem conta: ad esempio, su Linux (per la precisione, su filesystem ext3) puoi avere nella stessa directory i file "foto.jpg" e "Foto.jpg" perché il filesystem di Linux li considera diversi; su Windows (per la precisione, su filesystem NTFS) no, perché Windows non permette di creare due file che differiscano solo per le maiuscole.
Caso pratico: tu carichi su Drupal (Linux) foto.jpg e Foto.jpg e Drupal li mette entrambi in sites/default/files ; quando fai rsync verso una macchina Windows, quei due file vengono scritti sul medesimo file, quindi rsync ti dà un errore. La medesima cosa succede se al posto di Windows usi Mac OS X.
Per evitare il problema, attiva su Drupal il modulo transliteration che "standardizza" i nomi dei file; a quel punto è tranquillo anche il passaggio tra filesystem diversi.
http://nuvole.org
http://youthagora.org
Grazie Pescetti come al solito...
Avrei un'altra cosa da chiederti - puramente a titolo informativo:
Usando >>> WinSCP che da quanto ho capito fa la stessa operazione ma attraverso una GUI e che sentendo in giro ne parlano molto bene quali sono le differenze?
Mi sembra di aver capito che operando direttamente da "terminale" è sempre la cosa migliore in ogni caso, ma volevo sapere un tuo parere sulla qualità/affidabilità nell'eseguire backup/restore attraverso questo strumento... in fondo si collega anche lui via SSH... può essere semplicemente una questione di scelta o ce dell'altro (importante)???
P.S. In questo modo si eviterebbe di installare e configurare Cygwin su Windows XP ma credo che con WinSCP e senza Cygwin si perda la possibilità di usare rsync che è la cosa più importante... giusto???
P.S.2. Facendo il backup da remoto > locale con rsync (da terminale...) mi viene assicurata anche l'integrità dei file *.sql; fatti con drush salvati in
sites/all/databasee altri db fatti con mysqldump ho è meglio salvare i db separatamente... voglio essere sicuro e lasciare al caso meno roba possibile... abbi pazienza...Ciao
Esatto, quindi in pratica perdi il vantaggio principale (cioè: se tu cambi solo due file sul sito, rsync controlla l'integrità di tutit gli altri e trasferisce solo i due che sono cambiati; scp invece copia tutto da zero).
Sì; tutti i file, compresi quelli.
http://nuvole.org
http://youthagora.org
ok, grazie ancora pescetti!
alla prossima...
ciao
kipper
...anche con Snow Leopard è tutto ok! ...ho cercato in lungo e in largo per poter eseguire rsync su OSX dando per scontato che gli stessi comandi da terminale NON potevano funzionare perchè mancava una sorta di supporto Cgywin per OSX e anche rsync ma mi sbagliavo...
senza stare qui ad elencare le potenziali soluzioni/proposte che ho trovato (rsyncx - MacPorts etc etc etc... tutte da testare... qualcuuno ha anche accennato >>> http://developer.apple.com/xcode/) sono andato direttamente sul MAC (Snow Leopard V. 10.6.7), che evidentemente ha già installato tutto il necessario essendo aggiornatissimo, ho lanciato il terminale e ho inserito:
Local > Local:rsync -rtuvz --delete /Users/nomeutente/Documents/my_backups/source /Users/nomeutente/Documents/my_backups/destination
Remote > Local:
rsync -avz --delete -e "ssh" [email protected]:/home/nomeutente/miosito.com/source/ /Users/nomeutente/Documents/my_backups/destination
Local > Remote:
rsync -e ssh -av /Users/nomeutente/Documents/my_backups/source/ [email protected]:miosito.com/destination
Tutto funziona perfettamente...
Quindi, installando il modulo per Drupal "transliteration" posso stare tranquillo anche usando OSX (che preferisco... per ovvi motivi...), tu che ne pensi???
Se le operazioni vengono eseguite senza fare una piega vale sempre il discorso che se non vengono segnalati errori vuol dire che è tutto ok giusto???
P.S. Come spiegheresti che su Snow Leopard a quanto pare è presente/installato il client rsync, il supporto ssh sulla porta 22 e una sorta di driver simile a Cgywin... cosa sarà???
Tu useresti a questo punto Win oppure MAC per l'operazione?
Ciao
Modulo transliteration:
Ho installato e attivato il modulo su un sito test con parecchi files jpg, gif... già inseriti e in >
admin/settings/file-system, sotto la voce Transliteration: ho i 2 checkbox già flaggati di default:Transliterate file names during upload.
Enable to convert file names to US-ASCII character set for cross-platform compatibility.
Lowercase transliterated file names.
This is a recommended setting to prevent issues with case-insensitive file systems. It has no effect if transliteration has been disabled.
cliccando sul TAB > Transliteration mi porto in >
admin/settings/file-system/transliteratione sotto mi appare:The database currently lists 25 file names containing non-ASCII characters.
This count might be inaccurate, though, since some files may not need to be renamed.
Foto1.jpgFoto2.jpg
one & one.jpg
etc etc...
più sotto ancora:
<strong>WARNING:</strong>if you have manually entered image or file paths in text fields (for example, text areas or WYSIWYG editors), renaming the files will break these references. Since there is currently no automated way to also fix referenced files in textual contents, it is a very good idea to backup the database and sites/default/files directory beforehand. Modules accessing files using their internal system ids are not affected.
<strong>Questa azione non può essere annullata.</strong>
Essendo sempre nel sito test ho cliccato il pulsante > Transliterate e mi è uscito un warning:
Not all file names could be converted. The following files could not be accessed and have been ignored:sites/default/files/1 roma & Milano-ok.jpg
sites/default/files/4 Torino.jpg
Va beh... per qualche motivo non li ha "convertiti/digeriti"...
Ma la mia preoccupazione (non avendo mai usato questo modulo) è:
Sono sicuro che dopo aver applicato il comando Transliterate (se alcuni files non vengono tradotti pazienza... tenendo conto anche che sto operando in multilingua con i18n...) le immagini che adesso vedo correttamente in tutto il sito (uso anche image cache - thickbox per gli ingrandimenti etc...) si vedano tutte regolarmente senza potenziali rischi di eventuali sorprese??? ...agendo questo modulo direttamente sul File System???
P.S.
Transliterate file names during upload.
Enable to convert file names to US-ASCII character set for cross-platform compatibility.
e
Lowercase transliterated file names.
This is a recommended setting to prevent issues with case-insensitive file systems. It has no effect if transliteration has been disabled.
Li lascio "flaggati come di default"?
E i percorsi dei nodi (Clean URL...) rimangono inalterati? ...non rischio di avere delle sorprese nel senso che non mi funziona più qualche link a qualche nodo?
Per ovvi motivi dovrei assolutamente avere + info su questa questione...
Grazie
Ciao
Se usi imagecache è vivamente consigliato installare transliteration. Ovviamente la cosa migliore sarebbe stato farlo all'avvio del sito.
Io attivo entrambi "Transliterate file names during upload" e "Lowercase transliterated file names", che garantiscono una situazione pulita.
Per la migrazione dei file esistenti, l'unico problema è se tu hai usato dei link espliciti (ad esempio se hai inserito immagini nelle pagine scrivendo a mano "img src=..."); fai sempre un backup prima, ma in situazioni normali non avrai problemi. Idem per i Clean URL, non interviene sui nodi.
http://nuvole.org
http://youthagora.org
eh si, quante cose rifarei meglio se potessi re-iniziare alcuni siti dall'inizio...
per quanto riguarda i link espliciti ("img src=...") NESSUNO fa riferimento/punta a
sites/default/filesma puntano/risiedono tutti in cartelle dedicate e caricati via FTP... insites/default/filesci sono SOLO i files caricati da CCK, imagecache, etc etc... ovvero tutti quei files che si caricano da CCK cliccando su "Sfoglia" (tanto per intenderci...)da quanto ho capito Transliteration va ad agire SOLO in
sites/default/filese a questo punto è chiaro anche il fatto che NON agisce per nulla sui Clean URL's giusto?ritornando al discorso files, con lo scenario che ti ho appena esposto, cliccando su Transliterate, i file che per qualche motivo decide di cambiare nome/rinominare e cioè solo quelli caricati con "Sfoglia", sono sicuro che si apriranno e/o rimarranno sempre memorizzati/associati alla posizione originale anche con eventuale nome modificato??? ...uso anche Thickbox per ingrandire immagini ridotte con imagecache...
spero di essermi spiegato...
grazie ancora pescetti
Esatto.
Non ho provato con Thickbox, ma tutti i moduli fatti decentemente non danno problemi: Transliteration agisce sulla tabella "files" e sistema le cose in modo che tutti i moduli decenti non abbiano problemi.
http://nuvole.org
http://youthagora.org
ho un fastidioso problema ogni volta che lancio il comando rsync:
rsync -avz --delete -e "ssh" [source] [destination]premetto che NON ho ancora attivato il modulo Tranliteration ma siccome i files hanno un nome in questo formato > mio-file_01.jpg, non credo stia qui il problema... credo...
...in pratica, dopo aver copiato tutta la "root" da remoto in locale, se rilancio il comando, rsync mi intercetta alcuni files in
/sites/default/files/e le rispettive miniature/sites/default/files/imagefield_thumbs/che sono già presenti in locale... ogni volta che lancio il comando, mi intercetta sempre quegli stessi files e mi dice che li ha copiati... che risposta si può dare a questo strano comportamento?poi, quella z dopo av (-avz) che serve per la compressione, in realtà cosa fa questa compressione???
...concludendo:
rsync -avz --delete -e "ssh" [source] [destination]lo tengo così oppure va aggiunta (o tolta...) qualche opzione? ...chiedo questo perchè dando un'occhiata alle opzioni disponibili di rsync ho visto un-- ignore-existingche, se ho capito bene (credo...), ignora i files già presenti in destinazione e andrebbe a risolvere il problema di quei 10 files *.jpg; che ho menzionato sopra... ma l'esclusione dei files già esistenti dovrebbe farla già rsync di default... non è nella sua natura???quindi:
rsync -avz --delete --ignore-existing -e "ssh"[source] [destination]potrebbe essere una soluzione? ...le opzioni di rsync possono essere aggiunte in un ordine casuale o ci sono delle regole ben precise???
ciao