restore subdirectory from dump to new partition - BSD

This is a discussion on restore subdirectory from dump to new partition - BSD ; I have added a new HD to my system and am about to upgrade from 6.1 to 6.2. I am trying to do this via an upgrade to the installed system rather than a fresh installation. I have full level ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: restore subdirectory from dump to new partition

  1. restore subdirectory from dump to new partition

    I have added a new HD to my system and am about to upgrade from 6.1 to 6.2.
    I am trying to do this via an upgrade to the installed system rather than a
    fresh installation. I have full level 0 dumps of all of my partitions. I
    will restore my current 6.1 installation to the new HD. In particular, /usr
    is now a separate partition. I would like to put /usr/ports onto a separate
    partition. This part of the tree gets very large and I don't see any point
    in regular backups of things there (if I'm not mistaken, this part of the
    tree need only be backed up after a CVSUP). In particular the
    /usr/ports/distfiles.

    Anyway, independant of my back up "system".

    I have a few CD sized dump files. I would like to restore the /usr/ports to
    the root of a new file system, currently mounted as /mnt/mt1.

    As per the man page, I've tried variations of restore -i and restore -x. All
    of these restore the actual ports/ subdirectory. I don't want this as the
    root of this partition will be the ports/ subdirectory. Any suggestions,
    pointers to FAQ's etc??

    Thanks

    JE



  2. Re: restore subdirectory from dump to new partition

    On Fri, 30 Mar 2007 10:53:38 -0500, JE wrote:
    : of these restore the actual ports/ subdirectory. I don't want this as the
    : root of this partition will be the ports/ subdirectory. Any suggestions,
    : pointers to FAQ's etc??

    Restore it and mv the restored ports/ directory to the root of the drive?

  3. Re: restore subdirectory from dump to new partition

    On 2007-03-30, Howard Goldstein wrote:
    > On Fri, 30 Mar 2007 10:53:38 -0500, JE wrote:
    > : of these restore the actual ports/ subdirectory. I don't want this as the
    > : root of this partition will be the ports/ subdirectory. Any suggestions,
    > : pointers to FAQ's etc??
    >
    > Restore it and mv the restored ports/ directory to the root of the drive?


    As I understand it, mv is a combination of cp and rm. If I recall correctly,
    cp does not accomplish the same tasks as restore. However, with this
    particular directory, that may or may not be an issue. If one were restoring
    a jail subdirectory (for instance), mv would not work properly. For one,
    hard links would not be handled properly. Also, I think any files with read
    only permissions for owner would not be deleted. I think the mv would fail
    at that point and stop (a file with file mode 0400 for instance).

    Cheers

    JE

  4. Re: restore subdirectory from dump to new partition

    On Fri, 30 Mar 2007 11:23:50 -0500, JE wrote:
    : On 2007-03-30, Howard Goldstein wrote:
    : > On Fri, 30 Mar 2007 10:53:38 -0500, JE wrote:
    : > : of these restore the actual ports/ subdirectory. I don't want this as the
    : > : root of this partition will be the ports/ subdirectory. Any suggestions,
    : > : pointers to FAQ's etc??
    : >
    : > Restore it and mv the restored ports/ directory to the root of the drive?
    :
    : As I understand it, mv is a combination of cp and rm. If I recall correctly,

    If it's on the same filesystem then mv is a rename, not a cp and rm

  5. Re: restore subdirectory from dump to new partition

    Begin <4tWdnes6M7oLpJDbnZ2dnUVZ_sGqnZ2d@giganews.com>
    On 2007-03-30, JE wrote:
    > As I understand it, mv is a combination of cp and rm.


    It isn't. It copies and removes data when it has to, but it uses rename()
    if available. You've missed a crucial sentence or two from its manpage.


    > If one were restoring a jail subdirectory (for instance), mv would not
    > work properly. For one, hard links would not be handled properly.


    You can use an archiver like tar for that.


    > Also, I think any files with read only permissions for owner would not
    > be deleted. I think the mv would fail at that point and stop (a file
    > with file mode 0400 for instance).


    If it runs as root it should, at least given -f. There would be a
    problem with extended fs flags like uchg or schg, as it doesn't know how
    to manipulate those. Neither do most archivers, for that matter. It can
    be dealt with through mtree, chflags, and some more scripting, or indeed
    by using dump and restore.

    I haven't really paid attention to the thread but from what I did see, I
    think the problem might be you're trying to make a tool that works with
    entire filesystems do things on a smaller scale. That is probably more
    trouble than it is worth.

    If your concerns are about /usr/ports, since you're upgrading anyway,
    I'd say to take binary packages of everything you have installed, set
    those aside for possible downgrading, and delete the entire ports tree.
    The same goes for the obj and source directories. But then I'm biased as
    I keep a CVS tree updated instead, and can always restore from there.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  6. Re: restore subdirectory from dump to new partition

    On 2007-03-31, jpd wrote:
    > Begin <4tWdnes6M7oLpJDbnZ2dnUVZ_sGqnZ2d@giganews.com>
    > On 2007-03-30, JE wrote:
    >> As I understand it, mv is a combination of cp and rm.

    >
    > It isn't. It copies and removes data when it has to, but it uses rename()
    > if available. You've missed a crucial sentence or two from its manpage.
    >
    >
    >> If one were restoring a jail subdirectory (for instance), mv would not
    >> work properly. For one, hard links would not be handled properly.

    >
    > You can use an archiver like tar for that.
    >
    >
    >> Also, I think any files with read only permissions for owner would not
    >> be deleted. I think the mv would fail at that point and stop (a file
    >> with file mode 0400 for instance).

    >
    > If it runs as root it should, at least given -f. There would be a
    > problem with extended fs flags like uchg or schg, as it doesn't know how
    > to manipulate those. Neither do most archivers, for that matter. It can
    > be dealt with through mtree, chflags, and some more scripting, or indeed
    > by using dump and restore.
    >
    > I haven't really paid attention to the thread but from what I did see, I
    > think the problem might be you're trying to make a tool that works with
    > entire filesystems do things on a smaller scale. That is probably more
    > trouble than it is worth.
    >
    > If your concerns are about /usr/ports, since you're upgrading anyway,
    > I'd say to take binary packages of everything you have installed, set
    > those aside for possible downgrading, and delete the entire ports tree.
    > The same goes for the obj and source directories. But then I'm biased as
    > I keep a CVS tree updated instead, and can always restore from there.
    >


    Hi:

    I would say that your point regarding using dump when something other would
    do is apropos. I was hoping I had missed something and could use my dumps
    for a fairly easy system set up. I will still be able to use my dumped
    backups, but will have to use the -x option rather than the -r option and
    exclude the ports/ tree from /usr. I also would normally delete the entire
    distfiles/ directory if nothing else. However as I am going to do a CVSUP
    upgrade from 6.1 to 6.2 (just to learn how it works!) I wanted to keep the
    distribution files I've already downloaded to lessen the load on the FreeBSD
    servers, in the event that I need to reinstall any ports etc..

    I've also taken to deleting the obj directories on a regular basis. They
    take up space that is irrelevant for a backup.

    Cheers and Thanks

    JE


+ Reply to Thread