My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.

I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2022-12-04, attend <attend@homesrv.net> wrote:

My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.

How did you copy the partitions?

I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.

I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.

you've not given a lot of information.

For instance what was your cmdline.txt file and what is it now?

Are you sure the new /boot partition is in VFAT format?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hi attend,

On 4 Dec 2022 at 19:23:04 CET, "attend" <attend@homesrv.net> wrote:

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk.

I use "rip-clone" which creates a bootable backup of the current boot disk. Size differences don't matter as long as te target disk is big enough to hold the whole contents of your current boot disk.

Also, I found it to be good practice to format the target disk. If you don't then you're backup may or may not boot.

https://github.com/billw2/rpi-clone

Hope this helps,
Paul

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 04/12/2022 19:31, Jim Jackson wrote:

On 2022-12-04, attend <attend@homesrv.net> wrote:

My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.

How did you copy the partitions?

I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.

I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.

I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.

you've not given a lot of information.

For instance what was your cmdline.txt file and what is it now?

Are you sure the new /boot partition is in VFAT format?

Yes, two partitions. FAT32 for boot and ext4 for root.

cmdline.txt in 128G disk (current running) is as below:

console=serial0,115200 console=tty1 root=PARTUUID=7295e545-02
rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

And I've changed root=PARTUUID=7295e545-02 to the 120G disk partuuid,
which I have manually changed to 7295e546-02 by fdisk.

From my understanding, files in boot partition are not required in
particular sectors of hard drive and there is no such thing like MBR.

Having read some information about the boot sequence of the Raspberry Pi
from website http://www.diy.ind.in/raspberry-pi/55-run-scripts-on-startup-in-raspberry-pi

1. Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache
2. Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3
3. Stage 3 is loader.bin. It knows about the .elf format and loads start.elf
4. start.elf loads kernel.img. It then also reads config.txt,
cmdline.txt and bcm2835.dtb If the dtb file exists, it is loaded at
0×100 & kernel @ 0×8000 If disable_commandline_tags is set it loads
kernel @ 0×0 Otherwise it loads kernel @ 0×8000 and put ATAGS at 0×100
5. kernel.img is then run on the ARM.


At stage 4, system will read config.txt and cmdline.txt. I believe there
is no partition information in config.txt, and only cmdline.txt is
required to change in boot partition for the partuuid.

I suppose rsync is not suitable for this?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 04/12/2022 20:31, Paul Förster wrote:

Hi attend,

On 4 Dec 2022 at 19:23:04 CET, "attend" <attend@homesrv.net> wrote:

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk.

I use "rip-clone" which creates a bootable backup of the current boot disk. Size differences don't matter as long as te target disk is big enough to hold the whole contents of your current boot disk.

Also, I found it to be good practice to format the target disk. If you don't then you're backup may or may not boot.

https://github.com/billw2/rpi-clone

Hope this helps,
Paul

Hi Paul,

Thanks for the information. I haven't heard of this software before, and
I'll have a try during Xmas break.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2022-12-04, attend <attend@homesrv.net> wrote:

My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.

I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.

No need for anything fancy here. I've been using the built-in SD Card
Copier to backup my SSD to a flash Drive. The software doesn't care that there's no SD card in the mix. Oh, and by the way, My pi 4 boots and
runs just fine from the flash drive, just a bit slower, due to the
nature of the media.
--
chrispam1@me.com is a filtered spam magnet. Email replies may be lost.
You're better off replying to this newsgroup.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hello attend!

Sunday December 04 2022 18:23, you wrote to All:

My respberry pi 4 is currently booting from a 128G ssd disk thourgh
usb and everything is fine. I just got a spare 120G ssd disk and I'm
going to use it as a backup disk in case the current running one got problem.

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.

I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.

Consider using the Pi o/s installer on another system with the Pi turned off and the USB dongle removed and the USB drive port plugged into the other system
and do similar to the spare SSD drive connecting it to the same system.

Use the O/S installer to copy of the system to spare.

At this momment you now have a bootable spare.

If the OS installer did not transfer over the user directories do so using rsync from 128Gb to the spare 120GB.

This, should work.

You way would not have transferred over the boot areas as well as the boot tracks on the 128Gb and these are not so easy to copy over unless using as above or possibly using a migrate SSD copier that often is available from the SSD manufacturer although this will need to be run on a standard system using
a Intel type processor - I could be wrong here and there is one for a ARM cpu.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.8/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

On 2022-12-04, attend <attend@homesrv.net> wrote:

On 04/12/2022 19:31, Jim Jackson wrote:

On 2022-12-04, attend <attend@homesrv.net> wrote:

My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.

How did you copy the partitions?

I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.

I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.

I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.

you've not given a lot of information.

For instance what was your cmdline.txt file and what is it now?

Are you sure the new /boot partition is in VFAT format?

Yes, two partitions. FAT32 for boot and ext4 for root.

cmdline.txt in 128G disk (current running) is as below:

console=serial0,115200 console=tty1 root=PARTUUID=7295e545-02
rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

And I've changed root=PARTUUID=7295e545-02 to the 120G disk partuuid,
which I have manually changed to 7295e546-02 by fdisk.

From my understanding, files in boot partition are not required in particular sectors of hard drive and there is no such thing like MBR.

Having read some information about the boot sequence of the Raspberry Pi
from website http://www.diy.ind.in/raspberry-pi/55-run-scripts-on-startup-in-raspberry-pi

1. Stage 1 boot is in the on-chip ROM. Loads Stage 2 in the L2 cache
2. Stage 2 is bootcode.bin. Enables SDRAM and loads Stage 3
3. Stage 3 is loader.bin. It knows about the .elf format and loads start.elf
4. start.elf loads kernel.img. It then also reads config.txt,
cmdline.txt and bcm2835.dtb If the dtb file exists, it is loaded at
0??100 & kernel @ 0??8000 If disable_commandline_tags is set it loads
kernel @ 0??0 Otherwise it loads kernel @ 0??8000 and put ATAGS at 0??100
5. kernel.img is then run on the ARM.

At stage 4, system will read config.txt and cmdline.txt. I believe there
is no partition information in config.txt, and only cmdline.txt is
required to change in boot partition for the partuuid.

I suppose rsync is not suitable for this?

It should be. I use the options -vauxXAH

what does sudfo blkid say for the new disk?

Have you got a monitor connected or a serial console connection? Do you
get any output?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hi attend,

On 4 Dec 2022 at 23:20:45 CET, "attend" <attend@homesrv.net> wrote:

Hi Paul,

Thanks for the information. I haven't heard of this software before, and
I'll have a try during Xmas break.

It's not a special piece of software. It's just a shell script that does everything for you that needs to be done. All the tools the shell script uses are already part of your Linux distribution.

Cheers,
Paul

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

attend <attend@homesrv.net> wrote:

My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.

This is how I image storage devices for the Raspberry Pi. I use it with MicroSD cards, but I see no reason why it wouldn't work with other types of storage.

1) Put the source card in your desktop machine and use gparted to shrink the
root partition as small as possible.
2) Use fdisk to get the block number of the last block of the root
partition. This, plus one, should be the number of blocks you'll need
to back up. It'll most likely be a multiple of 2048...go ahead and do
that, and use the resulting number below. (For this example, let's say
it's 5632 for a disk with 5.5 GB in use, and that your SD-card reader
is /dev/sda.)
3) Create an image with dd:
dd if=/dev/sda bs=1048576 count=5632 status=progress | xz -9 >rpi-image.img.x
4) Use gparted to restore the root partition to its normal size, then eject
the source card and put in your destination card.
5) Blast the image onto the destination card:
xzcat rpi-image.tar.xz | dd of=/dev/sda bs=1048576 status=progress
6) Use gparted to expand the root partition to fill up the card.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to match the 120G disk, but it won't boot.

Why wouldn't a standard 'dd if=/src of=/destination' work? So long as the /destination is LARGER than the /src, it should write [clone] with no issues.



|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 2022/07/15 (Linux/64)
* Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (1:105/420)

On 2022-12-06 12:07, Anssi Saari wrote:

Björn Lundin <bnl@nowhere.com> writes:

On 2022-12-05 05:05, paul lee wrote:

Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with no issues.

|07p|15AULIE|1142|07o
|08.........

120 < 128

Even then, assuming there's space on the 128 GB card, he could've just resized the file system(s) so they take at most 120 GB and dded
away. Seems weird the OP didn't just do that.

You also seem to miss OP's first sentence :

"My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk ..."

That is the new disk is smaller.
The destination is not larger - it is SMALLER


--
/Björn

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2022-12-06, Björn Lundin <bnl@nowhere.com> wrote:

On 2022-12-06 12:07, Anssi Saari wrote:

Björn Lundin <bnl@nowhere.com> writes:

On 2022-12-05 05:05, paul lee wrote:

Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with no issues.

|07p|15AULIE|1142|07o
|08.........

120 < 128

Even then, assuming there's space on the 128 GB card, he could've just
resized the file system(s) so they take at most 120 GB and dded
away. Seems weird the OP didn't just do that.

You also seem to miss OP's first sentence :

"My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk ..."

That is the new disk is smaller.
The destination is not larger - it is SMALLER

I made a comment earlier in this thread, but it may have been lost in
the shuffle, perhaps due to me omitting a few key details. I boot and
run my pi 4 from a 256 GB SSD, but at this time the drive is extremely under-utilized. I use SD Card Copier to backup this drive to a much,
much smaller capacity flash drive. SD Card Copier doesn't care what size
the destination drive is, as long as all the source data will fit.

As I said before, my backup flash drive boots and runs just fine.

Depending on the original poster's unique situation, it may be quite
possible to backup a 128 GB SSD to to a 120 GB SSD using SD Card Copier.

--
chrispam1@me.com is a filtered spam magnet. Email replies may be lost.
You're better off replying to this newsgroup.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 6.12.2022 18.42, Björn Lundin wrote:

On 2022-12-06 12:07, Anssi Saari wrote:

Björn Lundin <bnl@nowhere.com> writes:

On 2022-12-05 05:05, paul lee wrote:

Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with
no issues.

|07p|15AULIE|1142|07o
|08.........

120 < 128

Even then, assuming there's space on the 128 GB card, he could've just
resized the file system(s) so they take at most 120 GB and dded
away. Seems weird the OP didn't just do that.

You also seem to miss OP's first sentence :

"My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk ..."

That is the new disk is smaller.
The destination is not larger - it is SMALLER

The image file of the disk can be shrunk on another Linux computer
by setting up a loop drive with partitions:

sudo losetup -f -P --show path_to_image_file

You can then start gparted with the listed /dev/loop as an argument:

sudo gparted /dev/loopn

replacing /dev/loopn with the reported device, e.g. /dev/loop3

Gparted can be used to shrink the ext4 partition to the size really
used (leaving a few megabytes to spare). After the shrink check from
the information menu the last sector of the ext4 partition, add one
and divide by 2048 to get the new image size in megabytes.

Remember to disconnect the loop device before adjusting the image file:

sudo losetup -d /dev/loopn

The image file can then be truncated with the truncate command:

truncate -s new_file_size path_to_image_file

Please note that a recent Linux distributions use a bunch of loop
devices, so to be safe, it is a good idea to let losetup to find
the loop device. My Kubuntu 2204 LTS uses 10 loop devices for itself.

The copied disk can be expanded to fill the available space with
raspi-config:

sudo raspi-config

Select 6 Advanced Options, then A1 Expand Filesystem, and follow
the on-screen instructions, reboot when instructed so.

HTH

--

-TV

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2022-12-06 20:26, Tauno Voipio wrote:

On 6.12.2022 18.42, Björn Lundin wrote:

On 2022-12-06 12:07, Anssi Saari wrote:

Björn Lundin <bnl@nowhere.com> writes:

On 2022-12-05 05:05, paul lee wrote:

Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with
no issues.

|07p|15AULIE|1142|07o
|08.........

120 < 128

Even then, assuming there's space on the 128 GB card, he could've just
resized the file system(s) so they take at most 120 GB and dded
away. Seems weird the OP didn't just do that.

You also seem to miss OP's first sentence :

"My respberry pi 4 is currently booting from a 128G ssd disk thourgh
usb and everything is fine. I just got a spare 120G ssd disk ..."

That is the new disk is smaller.
The destination is not larger - it is SMALLER

The image file of the disk can be shrunk on another Linux computer
by setting up a loop drive with partitions:

---
<many commands shrinking data/partitions snipped/>

You are replying on a possible way to move the data.
I was replying to why it does not work to use a 'standard dd'' (and i
quote from above in this msg)

Why wouldn't a standard 'dd if=/src of=/destination' work? So long
as the
/destination is LARGER than the /src, it should write [clone] with
no issues.

And I stay with my first reply

120 < 128

It does not fit.


Of course it *can* be moved if it is shrunk first.
But I replied to why 'a standard dd' would not do


Personally, I did the corresponding thing with gparted.
I was then surprised it did copy/paste with partitions and its data


---


--
/Björn

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Dana Sun, 4 Dec 2022 18:23:04 +0000, attend <attend@homesrv.net> napis'o:

My respberry pi 4 is currently booting from a 128G ssd disk thourgh usb
and everything is fine. I just got a spare 120G ssd disk and I'm going
to use it as a backup disk in case the current running one got problem.

As the 120G ssd is not the same size and brand as the 128G one, I
couldn't use dd to clone whole disk. Then I did it manually by copying
boot partion and root partion to the 120G disk partitions seperately.
I've also changed the disk identifier in /etc/fstab and cmdline.txt to
match the 120G disk, but it won't boot.

I couldn't find any useful information in the website, any suggestion
woul be greately appreciated.

I would use resize2fs to shrink the last partition on the source
to make data under 120G.
You should boot from SD card to do this.
Than boot from source drive to confirm that everything is ok...
Than boot from SD...
Than copy the whole source drive to destination drive.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

attend wrote:

I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.

I do following trick

given /dev/sda1 is boot and /dev/sda2 is root of the source drive and
/dev/sdb1 is boot and /dev/sdb2 is root of the target drive
I mount /dev/sda2 on /mnt/source and /dev/sda1 /mnt/source/boot
then I mount /dev/sdb2 on /mnt/target and /dev/sdb1 /mnt/target/boot

so now cd /mnt/source && tar cf - . | (cd /mnt/target; tar xvf -)

tar would preserve groups and permission.
However this would not boot if UUIDs are used. One should modify /etc/fstab
in /mnt/target and update initram if used

If you want identical UUIDs, then dd only the partition table and use the method above to transfer the content (after formatting)

The cool thing with tar is, you can use it over SSH

tar cf - . | ssh myhost 'cd /media/myuser/mydisk && tar xvf -'
(see Unix Power Tools, 3rd Edition. ch10.13)

BR

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 07/12/2022 20:25, Deloptes wrote:

attend wrote:

I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.

I do following trick

given /dev/sda1 is boot and /dev/sda2 is root of the source drive and /dev/sdb1 is boot and /dev/sdb2 is root of the target drive
I mount /dev/sda2 on /mnt/source and /dev/sda1 /mnt/source/boot
then I mount /dev/sdb2 on /mnt/target and /dev/sdb1 /mnt/target/boot

so now cd /mnt/source && tar cf - . | (cd /mnt/target; tar xvf -)

tar would preserve groups and permission.
However this would not boot if UUIDs are used. One should modify /etc/fstab in /mnt/target and update initram if used

That is fine for small amounts of data but is terribly inefficient for
entire discs with GB of data.

rsync is a much better tool for the job, and had the advantage that
should the copying be interrupted for any reason, just issuing the
command again will cause it to continue from exactly where it went off.

rsync with -axHAXP flags will preserve all attributes including hard
links, and show the progress. It's even possible to copy a live system
this way (such as when doing incremental backups) but you need to
specify a number of directories to exclude for that, so you don't copy
things such as /dev or /proc

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Wed, 7 Dec 2022 21:29:13 +0000
druck <news@druck.org.uk> wrote:

rsync with -axHAXP flags will preserve all attributes including hard
links, and show the progress. It's even possible to copy a live system
this way (such as when doing incremental backups) but you need to
specify a number of directories to exclude for that, so you don't copy
things such as /dev or /proc

You need not to have any active databases or similar cached stores operating at the time also any files being written at the time of the copy
will be corrupt or at least truncated.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 08/12/2022 06:13, Ahem A Rivet's Shot wrote:

On Wed, 7 Dec 2022 21:29:13 +0000
druck <news@druck.org.uk> wrote:

rsync with -axHAXP flags will preserve all attributes including hard
links, and show the progress. It's even possible to copy a live system
this way (such as when doing incremental backups) but you need to
specify a number of directories to exclude for that, so you don't copy
things such as /dev or /proc

You need not to have any active databases or similar cached stores operating at the time also any files being written at the time of the copy will be corrupt or at least truncated.

That is a possibility with certain software, so proceed with caution and
always check that your backuped files are identical to the originals
*BEFORE* you need to restore from it.

However in practice, there are few problems with this approach.
Particularly as frequently changing files such the contents of caches
are best excluded from incremental backups, and recreated when needed.

I have dozens of large sqlite databases which are receive updates during backups, and have not suffered any corrupted, verified by checking
against remote replicated copies.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thu, 8 Dec 2022 21:52:30 +0000
druck <news@druck.org.uk> wrote:

I have dozens of large sqlite databases which are receive updates during backups, and have not suffered any corrupted, verified by checking
against remote replicated copies.

Don't try it with a real database server.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Björn Lundin <bnl@nowhere.com> writes:

That is the new disk is smaller.
The destination is not larger - it is SMALLER

That was clear but what I said also stands. Take one 128 GB drive,
resize the file system(s) on it so that they take up at most 120 GB of
the drive and dd away. dd will error out when the smaller drive is full
but it doesn't matter since everything contained in the file system(s)
was copied at that point.

I can see someone else proposed this as well so it shouldn't be a
radical concept. Tools to resize common file systems have been around
for a few decades now.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 09/12/2022 05:03, Ahem A Rivet's Shot wrote:

On Thu, 8 Dec 2022 21:52:30 +0000
druck <news@druck.org.uk> wrote:

I have dozens of large sqlite databases which are receive updates during
backups, and have not suffered any corrupted, verified by checking
against remote replicated copies.

Don't try it with a real database server.

You can get away with it on a database server using C-ISAM files
provided its relatively quiescent.

--
The biggest threat to humanity comes from socialism, which has utterly
diverted our attention away from what really matters to our existential survival, to indulging in navel gazing and faux moral investigations
into what the world ought to be, whilst we fail utterly to deal with
what it actually is.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2022-12-07, druck <news@druck.org.uk> wrote:

On 07/12/2022 20:25, Deloptes wrote:

attend wrote:

I used rsync to copy everything (hopefully) by using another computer
running linux, and both disks connected to the computer through USB3.

I do following trick

given /dev/sda1 is boot and /dev/sda2 is root of the source drive and
/dev/sdb1 is boot and /dev/sdb2 is root of the target drive
I mount /dev/sda2 on /mnt/source and /dev/sda1 /mnt/source/boot
then I mount /dev/sdb2 on /mnt/target and /dev/sdb1 /mnt/target/boot

so now cd /mnt/source && tar cf - . | (cd /mnt/target; tar xvf -)

tar would preserve groups and permission.
However this would not boot if UUIDs are used. One should modify /etc/fstab >> in /mnt/target and update initram if used

That is fine for small amounts of data but is terribly inefficient for
entire discs with GB of data.

rsync is a much better tool for the job, and had the advantage that
should the copying be interrupted for any reason, just issuing the
command again will cause it to continue from exactly where it went off.

rsync with -axHAXP flags will preserve all attributes including hard
links, and show the progress. It's even possible to copy a live system
this way (such as when doing incremental backups) but you need to
specify a number of directories to exclude for that, so you don't copy
things such as /dev or /proc

the -x option you quoted stops it cross filesystems - so no need to
exclude /dev /proc /sys etc

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Dana Fri, 09 Dec 2022 12:35:58 +0200, Anssi Saari <as@sci.fi> napis'o:

Björn Lundin <bnl@nowhere.com> writes:

That is the new disk is smaller.
The destination is not larger - it is SMALLER

That was clear but what I said also stands. Take one 128 GB drive,
resize the file system(s) on it so that they take up at most 120 GB of
the drive and dd away. dd will error out when the smaller drive is full
but it doesn't matter since everything contained in the file system(s)
was copied at that point.

I can see someone else proposed this as well so it shouldn't be a
radical concept. Tools to resize common file systems have been around
for a few decades now.

True. I've done that few times.
On different architectures. Worked every time.
It should even be faster than rsync if one has lamost full partition.

Or he could resize it to the size a bit over the size used in that partition, copy... and than resize to the full size of the partition.
Much faster than rsync.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)