how_to_clone_tru64_and_digital_unix
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
how_to_clone_tru64_and_digital_unix [2019/06/25 06:35] – [It Hangs During Boot] sgriggs | how_to_clone_tru64_and_digital_unix [2023/09/08 23:03] – [Fix AdvFS Domains in /etc/fdmns] sgriggs | ||
---|---|---|---|
Line 24: | Line 24: | ||
- Do not try to eliminate the /usr file system for UFS __and__ AdvFS. Startup scripts in **/ | - Do not try to eliminate the /usr file system for UFS __and__ AdvFS. Startup scripts in **/ | ||
- You might have read about **sysman** clone features. Forget that. That tool is garbage and will cause you much more pain than it saves you. Plan on doing it manually yourself or have an expert do it for you using this process. | - You might have read about **sysman** clone features. Forget that. That tool is garbage and will cause you much more pain than it saves you. Plan on doing it manually yourself or have an expert do it for you using this process. | ||
- | - Do not plan on using the **dd** method unless you have completely identical disks. That has several major drawbacks otherwise. The worst include performance problems (due to bad geometry alignment on the disklabel) and loss of space if the target disk is larger (or loss of __data__ if the target disk is smaller). However, just to say we shared the actual command if you cloned an identical dsk1 onto a dsk2 in tru64 5.x it'd be this command: **dd if=/ | + | - Do not plan on using the **dd** method unless you have completely identical disks. That has several major drawbacks otherwise. The worst include performance problems (due to bad geometry alignment on the disklabel) and loss of space if the target disk is larger (or loss of __data__ if the target disk is smaller). However, just to say we shared the actual command if you cloned an identical dsk1 onto a dsk2 in tru64 5.x it'd be this command: **dd if=/ |
==== Take Inventory ==== | ==== Take Inventory ==== | ||
Line 38: | Line 38: | ||
< | < | ||
- | # for Digital Unix | + | # for Digital Unix and OSF/1 (version 1.0 through 4.0g) |
scu show edt | scu show edt | ||
- | # for Tru64 | + | # for Tru64 5.0 and 5.1 |
hwmgr show scsi | hwmgr show scsi | ||
Line 58: | Line 58: | ||
# If we are using LSM on our root disk, I panic and run away. Don' | # If we are using LSM on our root disk, I panic and run away. Don' | ||
- | # try to clone this setup, recreate it and restore backups to it. | + | # try to clone this setup, recreate it and restore backups to it. LSM is |
- | volprint -ht | + | # really VxVM in disguise (no, really) and it has a completely different |
+ | # way of cloning I might cover in a whole separate document. | ||
+ | volprint -ht | ||
+ | |||
+ | # If that last command gives you " | ||
+ | # Configuration daemon is not accessible" | ||
+ | # you aren't using LSM. | ||
</ | </ | ||
Line 67: | Line 73: | ||
LSM is a volume management scheme which is pretty much identical to Veritas Volume Manager (VxVM). This is because, at the time, DEC was able to secure a one-shot licensed copy of VxVM but they agreed to change it's name. So, if you know VxVM, then all you do is replace the string " | LSM is a volume management scheme which is pretty much identical to Veritas Volume Manager (VxVM). This is because, at the time, DEC was able to secure a one-shot licensed copy of VxVM but they agreed to change it's name. So, if you know VxVM, then all you do is replace the string " | ||
- | Systems using LSM are extremely hard to clone unless you can use dd alone to clone a single disk. This would not be a very common | + | Systems using LSM can be cloned, but you need to use LSM (VxVM) semantics and methods. In a nutshell, you create and break a three-way mirror. This isn't covered by this document (yet). It' |
==== The Boot Sector ==== | ==== The Boot Sector ==== | ||
Line 91: | Line 97: | ||
__REMEMBER__: | __REMEMBER__: | ||
- | You will find the boot sectors themselves under the **/mdec** directory. There are ones for UFS, AdvFS, and CDFS (iso9660 with rock ridge extensions). This is where **disklabel** goes to find them and thus you can see that none of them are mixed case or have any unexpected spelling. | + | You will find the boot sectors themselves under the **/mdec** directory. There are ones for UFS, AdvFS, and CDFS (iso9660 with rock ridge extensions). This is where **disklabel** goes to find them and thus you can see that none of them are mixed case or have any unexpected spelling. It's a bit interesting. |
< | < | ||
Line 145: | Line 151: | ||
At first, this output can look intimidating, | At first, this output can look intimidating, | ||
- | What you normally see is that slices '' | + | What you normally see is that slices '' |
In general, if you are cloning a UFS based system, then be very careful that your disklabel is going to give you enough space for the **/** and **/usr** file systems. If you are using AdvFS make sure that the total slices you set aside can be used to add up to the sizes you need (ie.. remember that AdvFS can do concatination, | In general, if you are cloning a UFS based system, then be very careful that your disklabel is going to give you enough space for the **/** and **/usr** file systems. If you are using AdvFS make sure that the total slices you set aside can be used to add up to the sizes you need (ie.. remember that AdvFS can do concatination, | ||
- | ==== File Copy Steps ==== | + | ==== Creating File Systems ==== |
+ | |||
+ | Once you have your disk label setup on the clone, what you have is a essentially a partition table with no file systems. It's now up to us to actually create file systems inside of those extents we just defined. Obviously, this is a different process depending on if you use UFS or AdvFS. | ||
+ | |||
+ | ===== Re-Creating an AdvFS Layout ===== | ||
+ | |||
+ | The AdvFS system is a combination of a disk volume manager with a journaling filesystem. Copy-on-write features are sprinkled in there as well (snapshots, cloning, and such). First you need to understand AdvFS and I don't really want to write a novel on it. See the [[https:// | ||
+ | |||
+ | AdvFS has two main overarching concepts. Domains and Filesets. AdvFS domains are abstractions you don't use directly. They are containers for the disks and the configuration. The Filesets are the actual file systems you really mount on a directory. The proper nomenclature for AdvFS is " | ||
+ | |||
+ | If you are cloning an AdvFS system you have two problems to solve. The first getting the AdvFS configuration planned and created. The second is mounting it. Both old and new disks need to be mounted simultaneously to allow a copy, but we must avoid namespace collisions in our AdvFS file domains (especially the reserved domains " | ||
+ | |||
+ | Let's assume we are cloning disk **dsk0** onto disk **dsk1**. All we have done so far is to simply clone the disklabel from the source disk and make **dsk1** match. Let's create a local (source disk environment side) configuration for our clone' | ||
+ | |||
+ | < | ||
+ | # Use slice dsk1a to create the copy of the root domain | ||
+ | mkfdmn / | ||
+ | |||
+ | # We need a target for our usr_domain copy | ||
+ | mkfdmn / | ||
+ | |||
+ | # Now we must make filesets in the domains. Note that they have no size | ||
+ | # that is because they, by default, can use all the space in the domain. | ||
+ | mkfset target-root_domain root | ||
+ | mkfset target-usr_domain usr | ||
+ | mkfset target-usr_domain var | ||
+ | |||
+ | # We need a place to mount these file sets. Let's create three new directories | ||
+ | # and use them as target mount-points for our file copy jobs. I abbreviate | ||
+ | # in order to make it easier to navigate, but " | ||
+ | # this will be the root (/) of your cloned target disk when it boots for real. | ||
+ | mkdir /t | ||
+ | mount target-root_domain# | ||
+ | mkdir /t/usr | ||
+ | mkdir /t/var | ||
+ | mount target-usr_domain# | ||
+ | mount target-usr_domain# | ||
+ | </ | ||
+ | |||
+ | Note that in this case, the filesets for the **/var** and **/usr** file systems (filesets) are both using the same AdvFS file domain called " | ||
+ | |||
+ | So, if you'd be using the same layout as above (source of **dsk0** target of **dsk1** with two AdvFS data slices " | ||
+ | |||
+ | Let me first elaborate on the issues you'll need to correct in **/ | ||
+ | |||
+ | So, do a thought experiment.... your are rebooting from the clone, it comes up and checks / | ||
+ | ===== UFS Filesystem Setup ===== | ||
+ | |||
+ | For UFS users the process is much more simple. You simply need to run the **newfs** command on each UFS partition. It's no more complicated than that. Here is an example, in this case we have three filesystems, | ||
+ | |||
+ | < | ||
+ | # newfs / | ||
+ | # newfs / | ||
+ | # newfs / | ||
+ | </ | ||
+ | |||
+ | That puts down all the superblocks and metadata information the filesystem uses internally to operate. It doesn' | ||
+ | |||
+ | ==== File Copying For The Impatient ==== | ||
+ | |||
+ | This assumes you have the filesystems mounted up (/ | ||
+ | |||
+ | < | ||
+ | # Copy over the root filesystem | ||
+ | vdump -0 -f - / | (cd / | ||
+ | |||
+ | # Copy over the /usr filesystem | ||
+ | vdump -0 -f - /usr | (cd / | ||
+ | |||
+ | # Copy over the /var filesystem | ||
+ | vdump -0 -f - /var | (cd / | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | ==== File Copy Steps in Detail with Troubleshooting | ||
- | The UFS file system is BSD's native file system. It's very reliable and tough, but it also lacks features such as journaling, logging, and some other more esoteric stuff. It's maximums are also much lower than AdvFS. The upshot of UFS is that it's extremely | + | The UFS file system is BSD's native file system. It's very reliable and tough, but it also lacks features such as journaling, logging, and some other more esoteric stuff. It's maximums are also much lower than AdvFS. The upshot of UFS is that it's extremely stable, gives you reasonably high performance, |
UFS is easy to clone. You can use any file copy utility to move the data. However, you must insure that the tool you pick can, at a minimum, do a few things. AdvFS is also easy to clone, but I recommend using **vdump** for that exclusively as it's the easiest to remember and the fastest method I've seen speed-of-copy wise. For whatever reason, it's significantly faster than using **tar** or **cpio**, but don't try that method for UFS since vdump will refuse to dump it! Whatever tool you choose to use, make sure it has these capabilities. | UFS is easy to clone. You can use any file copy utility to move the data. However, you must insure that the tool you pick can, at a minimum, do a few things. AdvFS is also easy to clone, but I recommend using **vdump** for that exclusively as it's the easiest to remember and the fastest method I've seen speed-of-copy wise. For whatever reason, it's significantly faster than using **tar** or **cpio**, but don't try that method for UFS since vdump will refuse to dump it! Whatever tool you choose to use, make sure it has these capabilities. | ||
Line 158: | Line 239: | ||
- __It must be able to restore the filesystem to a different directory than it was backed up from__. This is something that **tar** only works with if you remembered to make the archive with relative paths. It has a flag for it '' | - __It must be able to restore the filesystem to a different directory than it was backed up from__. This is something that **tar** only works with if you remembered to make the archive with relative paths. It has a flag for it '' | ||
- | Here are some actually //valid// ways to copy one file system at a time in isolation. I use the ''/ | + | Here are some actually //valid// ways to copy one file system at a time in isolation. I use the ''/ |
- | + | - You can use the AdvFS **vdump** and **vrestore** commands. They will also work on UFS which is really nice since this method is by far the easiest and fastest. Example '' | |
- | - CPIO in two easy steps: '' | + | - CPIO in two easy steps: '' |
- Don't try to use **tar** it has no combination of flags (at least on Tru64' | - Don't try to use **tar** it has no combination of flags (at least on Tru64' | ||
- If you managed to get the **rsync** binary (which does not come with any version of OSF/1, Digital Unix, or Tru64 but is [[https:// | - If you managed to get the **rsync** binary (which does not come with any version of OSF/1, Digital Unix, or Tru64 but is [[https:// | ||
- | - You can use the AdvFS **vdump** and **vrestore** commands. They will also work on UFS which is really nice since this method is by far the easiest and fastest. Example '' | ||
Here is an example of what you might want to try, but surely **won' | Here is an example of what you might want to try, but surely **won' | ||
Line 173: | Line 253: | ||
cd / | cd / | ||
tar cvpf - . | tar -f - -xpP -C /new | tar cvpf - . | tar -f - -xpP -C /new | ||
+ | |||
## Whoops, you just filled up /new with files from /usr | ## Whoops, you just filled up /new with files from /usr | ||
## before you got a chance to even create /usr!! | ## before you got a chance to even create /usr!! | ||
Line 189: | Line 270: | ||
There is a big problem with the fact that you just can't limit Tru64' | There is a big problem with the fact that you just can't limit Tru64' | ||
- | You should __not__ | + | It's complicated to use regular UFS **dump** and **restore** commands __through a pipe__ |
=== Post Copy Fixes === | === Post Copy Fixes === | ||
Once you've re-created your slices (partitions) and got your data copied over then you are ready to begin making the final tweaks that will make sure the system is bootable. | Once you've re-created your slices (partitions) and got your data copied over then you are ready to begin making the final tweaks that will make sure the system is bootable. | ||
+ | |||
+ | ==== Dynamic Disk Reconfiguration in Tru64 5.x Horks AdvFS ===== | ||
+ | |||
+ | There are a lot of situations in which your clone might fail to boot or might boot up crippled in single user mode after cloning a Tru64 system. For storage and other items, Tru64 has a dynamic hardware database it tries to keep updated on it's own. Rather than assign names based on absolute hardware locations, like in Digital Unix 4.x before, it does something completely new. I'm not sure why thought it was a good idea or why, but it turns out to be pretty sub-optimal in practice. One of many negative side effects of adopting this system was that it causes problems for anyone wanting to clone a root disk. You're in a chicken and egg scenario. How do you know what links to create for " | ||
+ | |||
+ | There are two strategies for addressing this issue: | ||
+ | |||
+ | - If you clone the OS image from the workstation you use to do the vrestore operations, you can safely assume the disk name will stay the same. Why? Because you are copying the same hardware database that the system has booted up with. Therefore, you're going to get the same disk name as when you had when you created the file domain, mounted the target file sets, and performed the restore. So, in this case, you should have a clean booting clone. This is especially true if you are booting the disk on the same physical system (ie.. you're clone was for a backup root disk should your primary fail). | ||
+ | - In other cases, you are restoring vdumps from a non-local system. In this case, you're getting the hardware database that came from those vdumps (the database files are in /etc). In this situation, you have literally no idea what the disk number will be. The best strategy is to boot the system into single user mode, then observe whatever disk name the root disk came up with. Then, if possible, run **bcheckrc** from your single-user session, and fix your links in /etc/fdmns to point to the new disk name. If that fails then do the same process after booting optical media or a different hard disk drive. Once you know the disk name the system is going to pick, it's just a matter of fixing /etc/fdmns sub-directories and updating their symlinks. | ||
+ | |||
+ | |||
+ | ==== Fix AdvFS Domains in /etc/fdmns ==== | ||
+ | |||
+ | Once you finish copying data for the root fileset in AdvFS you'll have the exact same layout as the running system. The trouble is, that's not what we need on the clone. It needs to have it's own disk name reflected in the symbolic links present in /etc/fdmns. In Tru64 5.1 there are three required file systems. These are the root file system (/), /usr, and /var filesystems. They must be present in either two or three AdvFS file domains with specific names. If not, the boot scripts will halt/fail, so do not try to " | ||
+ | |||
+ | At a minimum, you need a domain called " | ||
+ | |||
+ | We have a problem because the system we use to create and copy the cloned data will have already given the disk a name. However, once you reboot using the prepared-target disk it will be using it's hardware database from you just restored. So, __where did you restore it from?__ That is the critical question. If you cloned the machine you used for the copy & restore operation, you can be sure the disk name will stay the same. For example, if it was ' | ||
+ | |||
+ | So, consider what might happen if you restored a vdump from another system, instead of your cloning workstation. You really don't know what the disk name will be, do you? Same is true of a RAID-1 based clone. So, here's what's going to happen. You'll need to boot up your system, observe what disk name the system believes it's OS disks are called, then (if it's different from the link structure in the target /etc/fdmns directory) you'll need to go in and correct the disk symlinks in /etc/fdmns. Odds are, the first boot will drop you into single-user mode anyway and complain it cannot mount /usr. | ||
+ | |||
+ | Thus, before this clone ever boots, we need to fix this issue. Since I don't know your exact scenario, I can't give a one-size-fits-all solution. What you need is for the system to boot once, then see what the dynamic hardware configuration will name the " | ||
+ | |||
+ | If you are building a cloned disk for the same system you are doing the cloning on, you can be pretty sure the disk name will remain constant with whatever you booted with, now. | ||
+ | |||
+ | I do not know how Tru64 tracks disk devices. It might be by WWN or some other identifier. However, it takes very little to " | ||
+ | |||
+ | I can give you detail on the process, of fixing this, at least. Start with a session like this one in my example. | ||
+ | |||
+ | < | ||
+ | # Change into the AdvFS configuration directory | ||
+ | cd /etc/fdmns | ||
+ | |||
+ | # See what you have right now. See which disks are linked in each sub-directory? | ||
+ | # those sub-directories have the same names as all your AdvFS Domains | ||
+ | |||
+ | $ ls -lR | ||
+ | total 32 | ||
+ | drwxr-xr-x | ||
+ | drwxr-xr-x | ||
+ | drwxr-xr-x | ||
+ | drwxr-xr-x | ||
+ | |||
+ | ./ | ||
+ | total 0 | ||
+ | lrwxr-xr-x | ||
+ | |||
+ | ./ | ||
+ | total 0 | ||
+ | lrwxr-xr-x | ||
+ | |||
+ | ./ | ||
+ | total 0 | ||
+ | lrwxr-xr-x | ||
+ | |||
+ | ./ | ||
+ | total 0 | ||
+ | lrwxr-xr-x | ||
+ | |||
+ | |||
+ | # You can see from that structure that the system would try to use disk dsk0 | ||
+ | # which is our original. The clone is dsk1. So, your easiest option is to manually | ||
+ | # fix these links before the clone ever tries to boot of this disk. | ||
+ | |||
+ | # Out go the references to the never-to-be-seen-again dsk0 | ||
+ | # we need to link to the new target disk, instead. | ||
+ | rm / | ||
+ | rm / | ||
+ | |||
+ | # In go our cloned slices which are now promoted to production/ | ||
+ | # names " | ||
+ | # them temporarily while you were copying the data over. | ||
+ | ln -s / | ||
+ | ln -s / | ||
+ | |||
+ | </ | ||
+ | |||
+ | In that situation, we just adjusted the disk names from using dsk0 to dsk1. We might have done this because we know the clone disk will be going back into the same system and the Tru64 disk name will stay static. We might also have done this after booting into single user mode, and discovering we had to fix the links because Tru64 decided it wanted a new name for the root disk (it happens for many reasons). In either case, the fix is the same: | ||
+ | |||
+ | - Start by learning what disks you have and are " | ||
+ | - Read the disklabel of each disk to understand what's on it. **disklabel -r dskX** | ||
+ | - Update the links for AdvFS in /etc/fdmns. Keep in mind the updated disk will need to replace the old disk name in all the symbolic soft links in any AdvFS file domain directories in /etc/fdmns. | ||
+ | - Check for usability with **showfsets mydomain**. If that works, your domain is usable. | ||
+ | - Clean up any old/stale file domains that no longer exist. Simply remove the directories in /etc/fdmns. | ||
+ | - Remember to never remove root_domain or usr_domain. They can never be combined. | ||
+ | |||
+ | What about the fact that **/ | ||
+ | |||
+ | < | ||
+ | # Be careful with this command since it's recursive. Double check your syntax. | ||
+ | # but afterewards you will have no stale reference to the no-longer-clone | ||
+ | rm -rf / | ||
+ | </ | ||
==== Fix the Fstab ==== | ==== Fix the Fstab ==== | ||
Line 199: | Line 373: | ||
First fix you'll need to make is to your **/ | First fix you'll need to make is to your **/ | ||
- | So, the bottom line is that you /might/ not have to alter the **/ | + | So, the bottom line is that you /might/ not have to alter the **/ |
+ | < | ||
+ | # Here is a working, normal, ordinary, average, Tru64 /etc/fstab for AdvFS | ||
+ | root_domain# | ||
+ | /proc / | ||
+ | usr_domain# | ||
+ | usr_domain# | ||
+ | </ | ||
+ | |||
+ | What about UFS? Here is an example of a valid fstab for UFS | ||
+ | < | ||
+ | # Here is a Tru64 5.1 /etc/fstab from a UFS based system | ||
+ | # note the sysadmin took advantage of a 2nd disk for his user's | ||
+ | # home directories. This would be ignored by our cloning process | ||
+ | / | ||
+ | / | ||
+ | / | ||
+ | / | ||
+ | </ | ||
==== Fix the rc.config ==== | ==== Fix the rc.config ==== | ||
The **/ | The **/ | ||
- | The main thing you are looking for is any reference to swap on the old disk. It will occur in some kind of variable name and you can simply remove the whole line, or edit the line to point to your new disk's swap slice. The name of the variable will be something like " | + | The main thing you are looking for is any reference to swap on the old disk. It will occur in some kind of variable name and you can simply remove the whole line, or edit the line to point to your new disk's swap slice. The name of the variable will be something like " |
- | Both Tru64 and Digital Unix (but especially Tru64) have a hardware registry which will store the names of disk devices that are seen by the system. In most cases, once a disk is seen, it's name will not change even on the cloned disk (the registry will be copied over at the same time during the file copy steps). | + | Both Tru64 and Digital Unix (but especially Tru64) have a hardware registry which will store the names of disk devices that are seen by the system. In most cases, once a disk is seen, it's name will not change even on the cloned disk (the registry will be copied over at the same time during the file copy steps). |
==== Fix the Sysconfigtab ==== | ==== Fix the Sysconfigtab ==== | ||
Line 256: | Line 448: | ||
- Make sure your copy method preserved all the permissions, | - Make sure your copy method preserved all the permissions, | ||
- Do NOT try to eliminate one of the default AdvFS file domains (one for root and another for /usr). As mentioned earlier, the startup scripts reference both **root_domain** and **usr_domain** and if you change their names or eliminate one of them the startup scripts will fail. | - Do NOT try to eliminate one of the default AdvFS file domains (one for root and another for /usr). As mentioned earlier, the startup scripts reference both **root_domain** and **usr_domain** and if you change their names or eliminate one of them the startup scripts will fail. | ||
- | - Make sure your SRM variables for __boot_file__ and or __boot_flags__ may be incorrect and have old VMS data in there or some other garbage. Your boot file should be your kernel, which is usually __/vmunix__ or __/ | + | - Make sure your SRM variables for __boot_file__ and or __boot_flags__ may be incorrect and have old VMS data in there or some other garbage. Your boot file should be your kernel, which is usually __/vmunix__ or __/ |
+ | - Are you absolutely sure you prepared your disk with the properly **disklabel** command with the -t flag so that it got the correct boot loader? If you miss this you wasted a lot of time and will need to start over from that step! | ||
===== It Boots but It's Horked Up ===== | ===== It Boots but It's Horked Up ===== | ||
- Double check your swap is pointing to the right place and working (swapon -s) | - Double check your swap is pointing to the right place and working (swapon -s) | ||
- | - Make sure your filesystems are not showing up with weird or generic names. Double check your source and destination device and make sure that your old device name isn't still leftover in a config file somewhere. Most commonly it's the **/ | + | - Make sure your filesystems are not showing up with weird or generic names. Double check your source and destination device and make sure that your old device name isn't still leftover in a config file somewhere. Most commonly it's the **/ |
- | - Make sure if you use a new system type that any kernel tuning you do makes sense. Ie.. if you take parameters from a system that has 4GB of RAM and try to use them on a big GS1280 with 64GB of RAM then you are almost certainly going to have some bad tuning in there. Double check your __sysctl__ settings with **sysctl -a**. | + | - Make sure if you use a new system type that any kernel tuning you do makes sense. Ie.. if you take parameters from a system that has 4GB of RAM and try to use them on a big GS1280 with 64GB of RAM then you are almost certainly going to have some bad tuning in there. Double check your __sysctl__ settings with **sysctl -a**. |
+ | - In general, you should make sure that the symlinks in /etc/fdmns sub-directories point to real disks that actually exist (check with disklabel -r dskX). Make sure file domains can show their file sets with the **showfsets** command to check for domain health. | ||
If you have problems beyond the ones documented, then consider contacting PARSEC for some consulting work to help you! | If you have problems beyond the ones documented, then consider contacting PARSEC for some consulting work to help you! | ||
+ | ===== A Note About Alphaserver Compaq Smart Array Contollers ===== | ||
+ | |||
+ | Early models of the Compaq Smart Array controller are available for Alpha hardware and feature RAID1-10 levels in including distributed parity. They are configured via the " | ||
+ | |||
+ | These array controllers have RAID-1 features. If you're using a system with such a card, you might be tempted to copy RAID volumes by breaking RAID-1 mirrors and re-synchronizing them to disks you intend as clones. This way you can import the RAID configuration on the clone-target system and everything is supposed to work, right? After all, it's a bit-for-bit clone! | ||
+ | |||
+ | Well, yes and no. First of all there are some drawbacks to this method. Here are some absolute show stoppers for example: | ||
+ | - You cannot do this with anything other than RAID-1 or RAID-10 based arrays. RAID-5 is right out as you cannot split the array and maintain enough parity in two places at once. RAID-6 or RAID-DP is also unworkable due to this issue. Mirroring or bust. | ||
+ | - Your disks must be as large or larger than the original disks you are cloning. If you do use mismatched disks, your resulting logical drive will just waste the extra space on the larger drive. | ||
+ | Other potentially troublesome issues include: | ||
+ | - The copy time will run for the full capacity of the disk, not just the modified blocks on the array. Thus, if you already have some small vdump backup files, consider that you might be able to vrestore those faster than the RAID controller can mirror the entire drive. | ||
+ | - If you use a larger disk as the sync-target, | ||
+ | - The target/ | ||
+ | - Even uglier. Once you rebuild the mirror on the __source__ machine' |
how_to_clone_tru64_and_digital_unix.txt · Last modified: 2023/09/08 23:04 by sgriggs