Creating Backups - Revision history

JPV: Added mentions about new backup programs in 3.20

2026-06-30T12:08:53Z

Added mentions about new backup programs in 3.20

JPV: LhA header level update

2026-06-25T14:13:01Z

LhA header level update

JPV: Modified MirrorCheck/Copy parts for the built-in solution in 3.20

2026-06-25T14:09:37Z

Modified MirrorCheck/Copy parts for the built-in solution in 3.20

JPV at 08:24, 1 April 2023

2023-04-01T08:24:04Z

JPV at 16:54, 31 March 2023

2023-03-31T16:54:29Z

JPV at 16:47, 31 March 2023

2023-03-31T16:47:34Z

JPV at 15:49, 31 March 2023

2023-03-31T15:49:41Z

JPV at 14:42, 30 March 2023

2023-03-30T14:42:41Z

JPV at 14:41, 30 March 2023

2023-03-30T14:41:47Z

JPV at 14:08, 30 March 2023

2023-03-30T14:08:10Z

@@ Line 34: / Line 34: @@
 There are two directories at the root level of the RAWDISK: device. The Devices directory contains all raw data of each device and unit found in the system. For example, mass storage devices connected to the internal IDE controller of a computer could be found under the ide.device sub-directory and USB mass storage devices under the usbscsi.device sub-directory. The second directory at the root level is Disks, and it contains raw data images of mounted partitions. It isn't that useful for backups, as there's a risk that data on a partition changes while copying a backup.
 === Creating a Backup ===
-To create a full backup of an entire disk, navigate to the ''RAWDISK:Devices/<your.device>/<unit>/'' directory. For example, a hard disk drive connected on the internal IDE port of a Mac mini computer would use the path ''RAWDISK:Devices/ide.device/0/''. The directory contains the rawdisk file, which is practically the raw data of the entire disk presented as a file. There's also a sub-directory that is named after the partition table of the disk (MAC, RDB, MBR), and that directory contains all partitions found on the disk as separate files.
+To create a full backup of an entire disk, either use the [[Tools/DriveImager | DriveImager]] tool or manually navigate to the ''RAWDISK:Devices/<your.device>/<unit>/'' directory. For example, a hard disk drive connected on the internal IDE port of a Mac mini computer would use the path ''RAWDISK:Devices/ide.device/0/''. The directory contains the rawdisk file, which is practically the raw data of the entire disk presented as a file. There's also a sub-directory that is named after the partition table of the disk (MAC, RDB, MBR), and that directory contains all partitions found on the disk as separate files.
 In theory, a full backup of an entire disk would be just copying the ''rawdisk'' file to another location, but remember that the file size is in most cases huge, so keep the destination filesystem limits in mind. An ext2 or ext3 formatted backup drive will work fine, for instance.
@@ Line 58: / Line 60: @@
 There are two ways to restore a raw image backup. Either the image can be mounted and any required files can be copied where desired, or the entire image file can be written to a storage device overwriting everything previously on it.
-When writing a rawdisk image back to a device, it must be copied either with the [[Shell_Commands/Copy|Copy]] command with the '''DIRECT''' argument or with the cp command from the [https://morphos-team.net/downloads MorphOS SDK]. Ambient or 3rd party filemanagers don't work to do this.
+When writing a rawdisk image back to a device, it must be copied either with the [[Shell_Commands/Copy|Copy]] command with the '''DIRECT''' argument or with the cp command from the [https://morphos-team.net/downloads MorphOS SDK]. Ambient or 3rd party filemanagers don't work to do this. Since MorphOS 3.20 it can also be done with the [[Tools/DriveImager | DriveImager]] tool.
 '''Be very careful when selecting a destination device to write an image file!''' For example, when writing to a USB storage device, the unit number may always be different. '''Always check the correct destination device and unit''' from the RAWDISK: directory structure. The partition table directory under the unit directory offers a good hint.
@@ Line 80: / Line 82: @@
 There are several ways to create an image file for backing-up:
 * A base backup image can be copied from the RAWDISK: device as described previously in the article.
 * Create a new empty file with the [[Shell_Commands/FileWrite|FileWrite]] command, mount it as '''MorphOS SFS''' in [[Tools/FileImageCtrl|FileImageCtrl]], and Quick Format it (maybe with Recycled disabled).
@@ Line 116: / Line 119: @@
 See [[Shell_Commands/MirrorCopy | MirrorCopy]]'s documentation for more options.
 ==== Third Party Programs ====
@@ Line 185: / Line 192: @@
 The minimum you should do is to check if file/directory sizes of source and destination paths match. For a more thorough test, a separate program that compares directories and data in them should be used.
-The [[Shell_Commands/MirrorCheck | MirrorCheck]] program is a good option to compare directories. It can compare file data (reads entire files), file name casing, owner info, protection bits, comments, dates, sizes, and existence of files. Each of these checks can be skipped if there's no need to compare certain things or you get too many reports of unimportant tests. For a quick check the file data comparison can be disabled or if you're making incremental backups, the existence check can be skipped in either or both directories.
+The built-in [[Shell_Commands/MirrorCheck | MirrorCheck]] shell command is a good option to compare directories. It can compare file data (reads entire files), file name casing, owner info, protection bits, comments, dates, sizes, and existence of files. Each of these checks can be skipped if there's no need to compare certain things or you get too many reports of unimportant tests. For a quick check the file data comparison can be disabled or if you're making incremental backups, the existence check can be skipped in either or both directories.

@@ Line 147: / Line 147: @@
 -z  Do not compress files</nowiki>
-It's safer to increase the header level from the default (0) to, for example, -H1, because some deeper file paths/comments may be too long and so be skipped with the -H0 level.
+It's safer to increase the header level from the default (0) to, for example, -H1, because some deeper file paths/comments may be too long and so be skipped with the -H0 level. Edit: the default header level was changed to H1 in MorphOS 3.20.
 Disabling the compression creates backups faster, but increases the resulting file size.
 Example:
-  System:> lha -H1 -e -x -r a Backup:System.lha #?
+  System:> lha -e -x -r a Backup:System.lha #?
 === Tar ===

@@ Line 95: / Line 95: @@
   Ram Disk:> Copy System: Backup:System/ ALL CLONE QUIET
-==== Third Party Programs ====
+==== MirrorCopy ====
-Leif Salomonsson's [https://www.morphos-storage.net/?find=mirrorcopy MirrorCopy] (don't mix it up with the original 68k program of the same name!) is a very comprehensive mirroring tool for MorphOS. It can be used to make exact copies of directories where files that are deleted from the source directory will be removed from the backup directory too. It handles file links properly, which makes it useful for backing up the directory structure that contains the SDK directory.
+The built-in [[Shell_Commands/MirrorCopy | MirrorCopy]] shell command (don't mix it up with 3rd party programs of the same name! Especially not with the 68k one) is a very comprehensive mirroring tool for MorphOS. It can be used to make exact copies of directories where files that are deleted from the source directory will be removed from the backup directory too. It handles file links properly, which makes it useful for backing up the directory structure that contains the SDK directory.
 Updating a backup is much faster than with the standard Copy command, because only changed/added/removed files are updated in the existing backup directory. With the Copy command you'd have to copy all the files over and over again.
@@ Line 119: / Line 115: @@
   Ram Disk:> mirrorcopy FROM System: TO Backup:System/ ALL DELDIR Backup:SystemDeleted
-See MirrorCopy's documentation for more options.
+See [[Shell_Commands/MirrorCopy | MirrorCopy]]'s documentation for more options.
 ===== BackUp =====
@@ Line 185: / Line 185: @@
 The minimum you should do is to check if file/directory sizes of source and destination paths match. For a more thorough test, a separate program that compares directories and data in them should be used.
-The [https://www.morphos-storage.net/?find=mirrorcheck MirrorCheck] program is a good option to compare directories. It can compare file data (reads entire files), file name casing, owner info, protection bits, comments, dates, sizes, and existence of files. Each of these checks can be skipped if there's no need to compare certain things or you get too many reports of unimportant tests. For a quick check the file data comparison can be disabled or if you're making incremental backups, the existence check can be skipped in either or both directories.
+The [[Shell_Commands/MirrorCheck | MirrorCheck]] program is a good option to compare directories. It can compare file data (reads entire files), file name casing, owner info, protection bits, comments, dates, sizes, and existence of files. Each of these checks can be skipped if there's no need to compare certain things or you get too many reports of unimportant tests. For a quick check the file data comparison can be disabled or if you're making incremental backups, the existence check can be skipped in either or both directories.

@@ Line 177: / Line 177: @@
 == Custom Backup Programs and Formats ==
-There are some other less standard options for backing-up using dedicated programs, like [https://www.morphos-storage.net/?find=diavolo Diavolo]. They may have some extra features like scheduling and comparing of backups, but they usually save backups into custom formats that require that specific program to be accessed. Many of these programs are also outdated for today's standards and may not support file links, etc.. If you're not completely familiar with the programs, it might be better to make backups on formats that are more common and accessible in the future to be sure.
+There are some other less standard options for backing-up using dedicated programs, like [https://www.morphos-storage.net/?find=diavolo Diavolo]. They may have some extra features like scheduling and comparing of backups, but they usually save backups into custom formats that require that specific program to be accessed. Many of these programs are also outdated for today's standards and may not support file links (enable the ''3.1 or better'' filesystem option in Diavolo for the file link support), etc.. If you're not completely familiar with the programs, it might be better to make backups on formats that are more common and accessible in the future to be sure.
 == Validating a Backup ==

@@ Line 137: / Line 137: @@
 === LhA ===
-LhA is a de-facto archiver on MorphOS (and Amiga), which was made to handle all related files and their properties, but it has its quirks and it doesn't support file links either. So don't use it for backing-up the MorphOS SDK.
+[[Shell_Commands/LhA|LhA]] is a de-facto archiver on MorphOS (and Amiga), which was made to handle all related files and their properties, but it has its quirks and it doesn't support file links either. So don't use it for backing-up the MorphOS SDK.
 LhA has tens of options and here are some that are important to achieve a successful backup:

@@ Line 9: / Line 9: @@
 It is especially important to preserve file attributes when making a backup of the system partition, and it would be a good practice for installed software in other locations too. It doesn't usually do any harm to copy generic data files into an "alien" destination, but even then you might lose file comments that indicate origin of the file, for instance.
-=== Preserivng File Links ===
+=== Preserving File Links ===
 A source directory structure may contain file links that are like shortcuts to actual files or directories. The links can be either soft or hard links, but usually soft links in practice. The hard links aren't supported by all MorphOS filesystems, so it's quite safe to assume that all links are soft links.

@@ Line 23: / Line 23: @@
 === Be Careful with Content Changes While Backing-up ===
-Backing-up a live system you have booted from is always a bit risky, or at least you should be totally sure that nothing (by your activity or background processes) writes to the data that is being backed-up, as this could be fatal, especially for partition/disk cloning by raw image files.
+Backing-up a live system you have booted from is always a bit risky, or at least you should be totally sure that nothing (by your activity or background processes) writes to the data that is being backed-up, as this could be fatal, especially for partition/disk cloning by raw image files. It's highly advisable to unmount partitions first when making raw image backups.
 The best practice is to boot from another media to make backups. Booting from the [https://morphos-team.net/downloads MorphOS installation media] is a good choice, especially if the beta timeout is removed with the [https://www.morphos-storage.net/?find=registeriso RegisterISO] program.
@@ Line 48: / Line 48: @@
 If you want to mount partitions from a raw image file at some point, there's a pitfall in it. MorphOS doesn't play well when different partitions share the same '''volume name'''. For example, if the System: partition is mounted from both the original HDD and the backup image, there will be issues. A solution for it is to name the partitions differently in the original location and in the backup. Probably the easiest solution is to rename ([[Shell_Commands/Relabel|relabel]]) the original partitions before making the backup, and then rename them back to the original after a successful backup process.
-Also, contents of partitions that are being backed-up shouldn't change while creating a backup, as it can break the filesystem structure. The best practise is to '''unmount partitions''' before copying them from the RAWDISK: device. Booting from another media before making a backup is highly recommended, or being very careful otherwise.
+Also, contents of partitions that are being backed-up shouldn't change while creating a backup, as it can break the filesystem structure. The best practise is to '''unmount partitions''' before copying them from the RAWDISK: device. Unmounting can be done, for example, with the [[Tools/Mounter|Mounter]] tool. Booting from another media before making a backup is highly recommended, or being very careful otherwise.
 === Updating a Backup ===

@@ Line 140: / Line 140: @@
 LhA has tens of options and here are some that are important to achieve a successful backup:
 -e  Archive empty directories
 -r  Collect files recursively
 -x  Preserve and use path names
 -H  Write header level ( 0,1,2 )
--z  Do not compress files
+-z  Do not compress files</nowiki>
 It's safer to increase the header level from the default (0) to, for example, -H1, because some deeper file paths/comments may be too long and so be skipped with the -H0 level.