Web lists-archives.com

Re: Backup problem using "cp"




On Mon, 7 May 2018, Kushal Kumaran wrote:

Date: Mon, 7 May 2018 13:15:48
From: Kushal Kumaran <kushal@xxxxxxxxxxxxx>
To: debian-user@xxxxxxxxxxxxxxxx
Subject: Re: Backup problem using "cp"
Resent-Date: Mon,  7 May 2018 17:16:09 +0000 (UTC)
Resent-From: debian-user@xxxxxxxxxxxxxxxx

Richard Owlett <rowlett@xxxxxxxxxxx> writes:

On 05/07/2018 07:01 AM, Thomas Schmitt wrote:
Hi,

Richard Owlett wrote:
richard@debian-jan13:~$ stat / | fgrep Device
Device: 80eh/2062d      Inode: 2           Links: 22
richard@debian-jan13:~$ stat /media | fgrep Device
Device: 80eh/2062d      Inode: 131073      Links: 5

"/media" was not the directory to examine.
You need to examine the directory which you gave as second argument to cp.
In your initial post of this thread the cp command is quoted as

   cp -ax /  "/media/richard/MISC
   backups/dev_sda14/"

(Dunno whether the line break in that mail is significant.)

No the _apparent_ line break was an artifact of email quoting process.
I can't rerun the diagnostic at the moment - hardware fully occupied
with testing my proposed workaround, which works so far but progress
resembles molasses running uphill on Pluto in winter ;/




I gather that "cp" is then an inappropriate tool.

That's not decided yet.

If your cp target directory had a different device number, then cp option -x
did not what it is supposed to do.

But if your target directory was not the mount point of the USB disk and
not inside the filesystem of the USB disk, then you made a mistake by
giving that directory as target.

Understood.



"tar" is inappropriate for my preferences - I was attempting to use "cp" as
there would be multiple files &/or directories as input *and* output.

You could use multiple tar commands.
(I doubt that you can talk cp into addressing more than one target.)

Communication confusion.
My goal was to copy root and its sub-directory to a directory on
another physical device.


Are you using an LVM volume as your root?  Then mounting a snapshot at
some location and copying from there is a good option.  This is what I
do for my own backups.

If you're not using LVM volumes, you could still use bind mounts for
this.  Run:

 # mkdir -p /mnt/source
 # mount --bind -o ro / /mnt/source

(The -o ro option is to make the /mnt/source mount read only.  I
understand you intend to use this as a backup source, so read-only
access should be sufficient.  If you change it to not be read-only, be
cautious when changing things in /mnt/source, because it is the same
filesystem as /)

Now /mnt/source is exactly the root filesystem.  Other filesystems
mounted (such as /dev or /proc) would only be present as empty
directories in /mnt/source.  After you're done copying, remove the bind
by running:

 # umount /mnt/source

This way, you do not have to figure out an exclude list or instruct
tools to stop at filesystem boundaries.

Make sure you do verify the files and directories you need are included.
If some of the required files are not part of the root filesystem, then
bind-mount them at the proper location under /mnt/source as well.  For
example, if your /home is a different filesystem, and you need it to be
part of your copying:

 # mkdir -p /mnt/source
 # mount --bind -o ro / /mnt/source
 # mount --bind -o ro /home /mnt/source/home

Then unmounting after you finish copying will be in the reverse order:

 # umount /mnt/source/home
 # umount /mnt/source

Tar has a -T file and an -X file set of options too. Of course files with includes and excludes will have to exist before the copying for that to work.



--