Re: Data migration for replacing HDD with SSD - suggestions?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/16/2017 03:17 PM, fred roller wrote:
Terry,
Stan hit on the points perfectly; ty Stan, it is the artifacts you leave in /home/user that start causing anomalies, most go un-noticed except to a trained eye but can snowball over time.  As for the re-linking, if you are comfortable a script can be made to relink but I found this more trouble than it is worth.  It is too easy to type the first set of commands then up arrow key to repeat the process as needed.  For me, catastrophic recovery took about 40-90 min under this set up; depending on anything new I wanted to implement.

As for default sizes I believe /boot was around 500 Mb, not much, so 1 Gb would suffice.  Bearing in mind the OS is designed to take not much more than 15 Gb total, if the numbers still hold, then the size of /tmp depends on usage.  At one point I gave /tmp 40-50 Gb because I was using heavy 30-50 Mb RAW image files in GIMP 8 or 9 at a time.  So a large /tmp helped me there.  Now days I check email and watch movies so 10-20% of remainder would easily suffice.  If you can watch /tmp on your current system via the command "watch 'ls -lh /tmp'"during a typical usage period.  See if your current quota is being used or staying mostly empty. 

On Sat, Dec 16, 2017 at 2:17 PM, stan <stanl-fedorauser@xxxxxxxxxxx> wrote:
On Sat, 16 Dec 2017 13:09:47 -0500
Temlakos <temlakos@xxxxxxxxx> wrote:

> On 12/16/2017 12:59 PM, stan wrote:
> > On Sat, 16 Dec 2017 10:13:55 -0500
> > fred roller <fredroller66@xxxxxxxxx> wrote:

> >> | 5. In general, should I place a partition for anything other
> >> than /home on the 1 TB SSD?
> >> This will explain how/why I put /home on the 120 [smaller drive].
> >> Through the use of hard/soft links to folders in /Crypt I connected
> >> the data files I wanted to preserve on /Crypt.  This use of links
> >> kept data writing to /Crypt and in so doing kept it separate from
> >> the OS drive.  So /home/user1/Documents
> >> -->/Crypt/user1/Documents, /home/user1/Pictures
> >> --> /Crypt/user1/Pictures, etc. etc.  This link was invisible to
> >> the user.  The data files from software likewise can be
> >> linked, /home/user1/.thunderbird --> /Crypt/user1/.thunderbird;
> >> which was great for recovering the mail client and other
> >> softeware.  This set-up was born of having put /home on /Crypt at
> >> first but if you migrated to a new distro or recovered from
> >> failure you tended to inherit artifacts which the new system
> >> choked on. This process proved to be a cleaner foundation from
> >> which to recover/reinstall.  One had only reinstall a clean OS on
> >> the 120 then re-link, the data was never touched during the
> >> installation process. Proved so effective that I preferred do
> >> clean installs from OS iteration to the next as opposed to
> >> upgrading.  There are some pros/cons to soft/hard links so
> >> research for the trade-offs.
> Stan:
>
> How exactly do you manage mounting the larger drive under a different
> name (whether /crypt or some other name) and setting up/maintaining
> the link structure? Seems to me you have to rebuild it every time you
> (a) reinstall the OS or (b) add or remove users. It also seems to me
> that mounting the larger drive as /home accomplishes the same goal.
> Why doesn't it?
>
> Temlakos

I think you meant this question for Fred, but I'll respond to at least
some of it.

[mounting the larger drive]  That's just creating a mount point
under /mnt and an entry in /etc/fstab. When the system starts, the
partition is mounted. Sure, the link structure has to be created when
you add a user.  But that's all of 5 minutes work, at least for me.
Create the mount point.
Edit /etc/fstab to copy the setup line into the new system.
ln -s [mount point] [home mount name]
for each directory in the mount you want to mount in home
As you can see, I use symbolic links.  This reminds me that there is a
caveat for doing things this way.  Any cp or rsync has to be restricted
to a single file system, or it will follow the links.

Fred answered your last question in the blurb above.  But the TLDR is
*cruft* and incompatibility.  Data is always compatible with any
program that can read it.  But configurations for the tools that do
read it might be different in different versions of the OS.  So using
an old home for a new version can lead to subtle problems.  And
safety.  The data is never in danger during any install or upgrade as
the partitions where it resides are never touched.  The disk can even
be unplugged during system maintenance with no issues.
_______________________________________________

I would appreciate two things:

1. How can you write the linking commands so that they will execute automatically at startup, rather than your having to "sudo ln -s [source] [destination]" for every directory for every user every time you restart your system? (I'm likely to be shutting down and restarting every day and sometimes twice or three times a day, depending on whether I can solve the "KDE Plasma 5 system hang" problem with this new installation.)

2. Could you give me an example of such a linking system, with names changed to protect your privacy?

Thanks.

Temlakos
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux