On Ven, 6 Dicembre 2013 10:04, Nicola Ferrari (#554252) wrote: ... > Ora ho configurato il backuppc col nuovo host, e sta facendo un backup > completo (non vedo molto movimento, ma c'è il PID del processo ancora > attivo..), ti faccio sapere! Le fasi sono queste, se hai configurato l'host con il pre-share command per le acl 1) vedrai il backup partire dalla webgui, con un pid singolo. In questa fase sta girando il salvataggio delle acl sulla vm (azione acl-backup nel forced command) L'attività di rete è zero, perche nessun dato viene trasferito. 2) Nella fase successiva, si vede un solo pid sotto la colonna "PID Xfer" della webgui. La fase salvataggio acl è finita, ed è partito il comando rsync verso l'host. In questa fase (azione rsync-backup nel forced command) viene preparata la snapshot sul virtualizzatore, viene montata sulo stesso e parte un processo, sempre sul virtualizzatore, che salva gli attributi estesi del filesystem NT (ancora le acl, ma anche attributi ntfs, nomi corti, ecc). Questi attributi vengono salvati in un file attr.bak.gz sulla snapshot. L'attività di rete è sempre zero. 3) Terza fase. Compare un secondo processo "PID Xfer"; significa che il comando rsync è stato rediretto con successo e sta girando sul virtualizzatore, e sulla snapshot (che nel frattempo è stata rimontata in readonly). Il secondo "PID Xfer" è un'implementazione perl di un client rsync sviluppata specificamente dal progetto BackupPC che scrive nel pool i dati provenienti dal client. L'attività di rete è in genere limitata, come pure le scritture sul pool perchè il protocollo rsync è sviluppato proprio per ridurrle al minimo (specialmente durante i backup incrementali). Un modo molto carino di seguire l'attività di trasferimento con lsof: su backuppc: lsof -p <seconfo PID Xfer> -a +r2 sul virtualizzatore lsof -p <rsync PID> -a +r2 rob -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx