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

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

 



On Sat, Dec 16, 2017 at 5:58 AM, Temlakos <temlakos@xxxxxxxxx> wrote:
> Everyone:
>
> If you have followed my threads about:
>
> SMB failing with F27
>
> and
>
> system hanging and requring repeated restarts,
>
> then you've seen people suggest replacing my 1 TB HDD with an SSD. I
> acquired a 1 TB SSD and then tried to clone the HDD to the SSD. The clone
> /failed/. Reason: the disk is already showing some bad sectors. The outputs
> of satactl and fsck make that undeniably clear.

smarctl -l scterc /dev/

This will reveal if this drive supports SCT ERC. If it does, and it's
not enabled, it can be set to an obscenely high value, and then a
matching SCSI block device command timer might permit deep recovery by
the drive's firmware. And then you can just rsync the data from one
drive to another. I would not depend on SMB for this.

rsync -pogAXtlHrDx is the set of flags used by anaconda when doing
live installs; this works locally or remotely

>
> On the advice of a professional installer, I have since acquired an
> additional SSD (capacity 120 GB) and am now acquiring a mounting bracket and
> some power and SATA data cables. I also downloaded the F27 KDE Plasma 5 Spin
> as an ".iso" image.
>
> My plan is to install F27 "clean" on the two SSD's, mounting the 120 GB SSD
> at root ("/") and the 1 TB SSD at /home. I must then migrate my data,
> browser cookies (Google Chrome, Firefox), e-mail
> accounts/saved/messages/other settings (Thunderbird), and documents,
> pictures, music, videos, and various downloads from the HDD to the SSD.

rsync -pogAXtlHrDxn /home/ foo@bar.local:/home/



> 1. Should I even try to accept /automatic/ partitioning when the installer
> gets to that point?

You can, although you probably do not want to pick both drives for
this installation or it'll marry them together in one big LVM VG.
You'll probably want to do this manually, but it really depends what
your familiarity with LVM is, and what kinds of things you're going to
do with this setup - what's your workflow, are you using VM's, if so
do you use Boxes (you use KDE so probably not) or virt-manager. And so
on.

If it were me, I'd probably keep the 120GB drive super simple and no
LVM. As for the 1TB, I'd GPT partition it with one big partition,
optionally LUKS/dmcrypt that partition, then use pvcreate on the
opened LUKS device, add it to a VG, and then divvy up all that space
as needed with LVM. This gives you the flexibility to leave some spare
space for VM's, using LVM LV's for virt-manager backing. Or for space
that won't be used for /home - like for example maybe you put /var
there since /var/lib/libvirt/images can get big if you prefer using
qcow2 or raw files for VM backing. Or if you're using containers. And
so on. So the use case dictates the layout.

>
> 2. Is 120 GB large enough for the information on the other directories
> besides /home?

Yes. The one gotcha is if you happen to have a lot of OS ISOs, qcow2
or raw files for VM's in /var/lib/libvirt/images.


>
> 3. Should I create a separate /boot partition on the smaller SSD, and if so,
> how large should I make it?

Yes. 500MB is fine still for just three kernels, and you're not using
kdump. If you are using kdump or you want more kernels install to
revert to, then 1G should be enough. 1G is the new default in Fedora
for automatic partitioning since Fedora 26.


> 4. How large should the swap partition be, and where should I put it? (That
> is, on the 120 GB or the 1 TB drive)?

It depends if you want to hibernate this machine, in which case it
needs to be at least 1x RAM and many guides say it needs to be 2x
because it's possible you have some swap in use, and then to create
the hibernation image could take up to 1x RAM on top of whatever is
already in swap. I personally do just 1x RAM for swap, and sometimes
less for servers which never hibernate.


>
> 5. In general, should I place a partition for anything other than /home on
> the 1 TB SSD?

Depends on your use case. Depends on your familiarity with LVM. I
think it's easier to depend on LVM, in particular thin provisioning,
should I need throw away block devices for testing things. But you can
certainly just 'fallocate' a file in /home, and put it on loopback and
format it as a test block device.



>
> Now, as regards data migration: I have three user accounts to migrate, plus
> another directory on /home called "lost and found."
>
> 1. Should I even try to migrate "lost and found," and if so, how?

No this is created by mkfs, I would not worry about migrating it,
that's a volume specific folder and in any case it should be empty. If
it's not empty you've had some file system corruption and when it was
partly repaired the orphaned files are put in this directory.


>
> 2. I have at least two choices for migrating data and settings from the
> various user accounts--three for some of them.
>
>     a. Connect the HDD to the SATA bus /after/ installing F27, and then
> force-copying everything out of each /home directory to its corresponding
> directory on the new configuration. (What command(s) would you recommend
> using, and with what options/switches/etc.?)
>
>     b. Connect a large external HDD through a USB interface, transfer all
> the data to it before modifying the hardware, then re-transfer it to the
> system after installing the SSD's and F27.
>
>     c. Migrate the data to its "temporary refuge" over a Samba network
> (possibly do-able for at least one account, and that's the biggest account)
> and then re-migrate to the new system?
>
> Which choice would you recommend?

I'm very skeptical of doing any of this in USB enclosures. Depending
on chipset they can lie about the optimal IO size and alignment will
be computed wrong by device-mapper based commands like LVM and
cryptsetup. I have a bunch of Purex enclosures that are well behaved.
I have another USB enclosure that lies and confuses dmcrypt so all the
alignments are wrong by default (yes I've filed a bug so this should
get fixed in a future version). Anyway it's probably not worth the
hassle of doing this in a USB enclosure.


> 3. Is it worth migrating every single hidden file or folder? Or should I
> select only those folders that I know contain customization, account, or
> similar settings, plus my saved documents/pictures/music/videos, and migrate
> those?

You could lookup how to do a recursive list of files and sort by date
and then separately sort by size. Anything huge is subject to deleting
if you're not using it. If it's old, over a year, it's subject to
deleting.

Otherwise don't get too deep in the weeds, just copy everything.
-- 
Chris Murphy
_______________________________________________
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