utilisation de SuperDuper, depuis un volume tiers ou pas ? en travaillant pendant le clonage ?

[flip flop]

Bonjour

Sur le SSD du Mac, j'ai deux partitions sous El Capitan: une partition principale et une petite partition secondaire.

Pour faire un clone de la partition principale vers un disque externe, comme je dispose de cette partition secondaire, j'exécute SuperDuper depuis la partition secondaire (et non depuis la partition principale elle-même).

Ma question est la suivante: y a-t-il un avantage à utiliser SuperDuper depuis un volume tiers, ou peut-on se contenter d'utiliser SuperDuper tout simplement depuis le volume que l'on veut cloner ?

Ce message a été modifié par flip flop - 19 Oct 2019, 21:27.

[flip flop]

À la lecture des documentations de SD/CCC, je comprends (entre les lignes) que les développeurs partent du principe que la majorité des utilisateurs lancent l'application depuis le volume de travail et travaillent sur ce volume pendant le clonage.

Il y a en fait deux cas de figures à considérer:

1. sous HIGH SIERRA ET ULTERIEUR… il n'y a aucun problème.

SD/CCC fait appel au nouveau gestionnaire de fichiers APFS, capable de prendre un "instantané" (ou "snapshot") de l'état du volume à "un instant t" très précis.

Le clonage étant basé sur cet "instantané", on peut travailler sans problème sur tout et n'importe quoi pendant le clonage, SD/CCC ne prenant absolument pas en compte les changements apportés au volume.

Dans ce cas, travailler pendant le clonage n'a aucune incidence (aucune !) sur le clone final.

2. sous SIERRA ET ANTERIEUR… on ne dispose pas de cette facilité apportée par APFS.

Travailler sur le volume en cours de clonage peut "dans certains cas" avoir une incidence sur le clone.
Il y a à ce sujet des chapitres dans les docs de SD/CCC:

. la doc SD rapporte que bien que ce ne soit pas absolument nécessaire, c'est quand même une bonne habitude de quitter toutes les applications en cours et même de redémarrer le Système en maintenant la touche Shift appuyée avant de lancer le clonage.

. la doc CCC est plus précise et rapporte que si (pendant le clonage) on travaille sur de "gros" fichiers (et CCC donne les exemples d'Images Disque montées ou de container VMWare/Parallels), alors il y a une probabilité non nulle que le clone soit "corrompu". Et donc CCC recommande de ne pas utiliser d'applications pouvant travailler sur de gros fichiers, le temps du clonage.

Bien évidemment, si un clone est "corrompu", cette corruption sera corrigée (cette corruption a de très grandes chances d'être corrigée) lors de la mise à jour suivante du clone.

Pour résumer ce qui est explicitement écrit par SD/CCC, pour les versions de OS X/macOS JUSQU'À SIERRA INCLUS:

. il y a des cas de figures très particuliers pouvant entraîner la corruption du clone,
. on peut donc être pleinement satisfait de SD/CCC, sans savoir qu'un clone peut dans certains cas être corrompu et que si on avait besoin justement de ce clone-là pour restaurer un volume (pour donner raison une fois de plus à la célèbrissime loi de Murphy)… ce clone ne serait pas pleinement cohérent, fiable,
. on peut sans problème lancer le clonage depuis le volume de travail, mais il est recommandé de quitter toutes les applications avant de lancer le clonage.

- - - - - - - - -

Pour info, un extrait de la doc SD:

Although it’s not strictly necessary, it’s usually a good practice to quit all running applications before performing a backup. Since there are some that aren’t visible, like the Microsoft Office Database Daemon, it’s easiest to log out of your account, and then log back in with the Shift key held down. This will prevent your startup items from running, and helps to ensure that your personal data doesn’t change during the backup.

Pour info, deux extraits de la doc CCC:

https://bombich.com/fr/kb/ccc5/can-i-run-ba...ey-be-backed-up
Can I run a backup while I'm using my computer? If I have open files, will they be backed up?

Generally, yes. Performance will be affected during the backup task (especially the first one) as CCC reads the entire source volume and writes to the destination volume. If your work is "disk bound" — that is your applications are reading or writing to either the source or destination, then you'll notice a performance hit. If you're just reading email or writing a document, then you probably won't notice the performance hit.

What happens if files are modified while they're being copied?

If the source volume is not APFS-formatted, then some consideration should be given to the modification of files on the source during the backup task. Typically it's OK to work from the source volume while you're copying it, with the understanding that if CCC copied a file, then you open it, make changes, save it, then CCC completes the backup task, the modified version of your document is not backed up (this time around). Typically that's no big deal, the modifications will get backed up the next time the backup task runs. More importantly, though, if you're working with large files (mounted disk image, Entourage email database, VMWare/Parallels container) during the backup operation, it is possible that those large files could be modified while CCC is backing up that file. This won't affect the source file, but there's a good chance that the backup version of that file will be corrupt. For this reason it is a good idea to stop using applications that may be modifying large files for the duration of the backup task. Again, keep in mind that this is only applicable for non-APFS source volumes.

https://bombich.com/fr/kb/ccc5/backing-up-l...hine-containers
Backing up large files, mounted disk images, and Virtual Machine containers

Note: When backing up an APFS-formatted volume with CCC 5.1 or later, CCC will copy files from a read-only snapshot of the source volume. The subject of this article is not applicable in those cases.

Mounted disk images and running Virtual Machine container files pose an interesting problem to incremental backup utilities. By simply being mounted and accessed (e.g. via browsing the contents, booting the VM), the content of these large files are subject to modification by the applications that use those files. If you run a CCC backup task while a read/write disk image is mounted or while a VM container's OS is booted, there is a chance that the disk image file or VM container will be modified while it is being backed up, resulting in a corrupted version of the file on your backup volume.

If you have disk image files or VM containers that are regularly in use on your system, you should exclude these items from your backup routine and configure an alternate backup task for these items that runs when they are not in use. Alternatively, you could quit or suspend the applications that modify those files for the duration of the backup (see the "Example pre and post clone shell scripts" link below for examples of how to automate this).

If errors do occur while backing up large files, quit or suspend the applications that modify those files, then simply run the backup task again to correct the copy of the file on the backup volume.