<div dir="ltr"><div>We are just cloning the main OS area, not any data...  The systems we are upgrading are usually SAP HANA or Oracle.  Yeah, I'm familiar with the reasons to break up the OS volumes... I do a lot of work with the DISA, NIST, USGCB, and CISv2 STIGs. :)  I'm just looking to see if there is a better way to clone the core OS directories.  The ReaR process does work... but it has some annoyances. :)</div><div><br></div><div>"young-ins" - Haha!  No... that's not me... I'm a grey-hair like you my friend! LOL! <br></div><div><br></div><div>Thanks,</div><div>/Raj W.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 17, 2021 at 2:17 PM Jon "maddog" Hall via Ale <<a href="mailto:ale@ale.org">ale@ale.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Storage size is not the only reason for splitting up the system file tree.  Access time to the data is another reason.<br>
<br>
In "the old days" separating /tmp, swap and other "heavy I/O" areas of the disk from user files could improve throughput of some systems from 20-40%.   There were concepts of being "I/O bound" as well as cpu bound, particularly on devices like slow disk drives with head movement.<br>
<br>
SSDs and larger memory buffers help to alleviate this issue, but even with SSDs you might find that one controller (say a USB) is "I/O bound".<br>
<br>
Splitting up the file tree also allows for you to mount different filesystems in different ways.  If /tmp is really "temp files" then why would you use a log-based file system on it?  If the system crashes the easiest way of clearing it is to remake the file system.<br>
<br>
[Note: It has been a long time since I had to look at this, so please take that into consideration.]<br>
<br>
Along these lines, be aware that "cloning a live system" may allow for the cloned file system to be incomplete.  Depending on the cloning software and how tied it is to the actual operating system, file system buffers may not be copied properly, leaving data incomplete.<br>
<br>
dd(1) is a good example of this.  If you are dd(1)ing a raw partition, it may not reach up into the file system buffer to copy that data to the new device....nor would dd(1) know how to apply that data.<br>
<br>
Also long running user applications may not have flushed their data when their section of the disk is being copied.  Even if the filesystem structure is ok, the data of the application may be caught in an incomplete state.<br>
<br>
As I said, it has been a long time since I had to think about this, but I will bring up these points for you "young-ins" to think about.<br>
<br>
md<br>
<br><br>
</blockquote></div></div>