Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Snapshot / Clone a Directory/Disk for Backup purposes

  1. #11
    Join Date
    Feb 2010
    Location
    South Dakota, USA
    Posts
    171

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    Quote Originally Posted by robin_listas View Post
    On 2013-12-21 22:56, wolfi323 wrote:
    >> But I've often been curious as to why the /mnt/ is even there ...
    > I think /mnt was originally there to be able to mount your root file
    > system in the rescue system or something like that.


    I understand it is the standard place for manual, non default, mounts.
    But what do you mean by "non default" ? Like for Digital Cameras, DVD/CD Drives, or USB Flash Drives? I have 2 of my partitions, one at the end of Hard Disk #1 for stowage (like for software downloads and other stuff), "/media/stowage", and all of Hard Disk #2 primarily for backups, "/media/spare". These partitions I need to have mounted at boot-up, or at least I prefer it that way.

  2. #12
    Join Date
    Feb 2010
    Location
    South Dakota, USA
    Posts
    171

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    Quote Originally Posted by tsu2 View Post
    Seems this thread got off on a little bit of a tangent (although still useful info).

    1. I'm not entirely clear about your "read only" requirement, if it's related to your source directory/disk, that's not an issue in UNIX (but is in Windows which puts a lock on the file system when it's being accessed with more than read-only permissions).

    2. You may need to specify your requirement and need if you're considering a snapshot or cloning, IMO they describe slightly different operations. But, you can consider
    dd -- The universal disk block copier
    Various apps can help automate and manage the cloning process, including compressing or sending across a network.
    My personal "enterprise" tool is G4U (g4u - Harddisk Image Cloning for PCs) I haven't seen anything to compare with its versatility.
    Personal cloning can be done with apps like the popular Clonezilla.

    When you use the above apps, you don't have to deal with the miscellaneous gruntwork mounting/unmounting if they're even necessary (likely not). Just specify source and destination and execute (after optionally specifying some other configs).

    HTH,
    TSU
    Thank you for your input, references and advice. Your point is well taken that I haven't used the right words I guess -- I suspected that from the start. Maybe the proper term is a "shadow mount"? I saw something in [a] manual(s) and/or web page(s) that showed that in order to maintain the atimes (access times) of the files you back up in your home user directory, mount that system elsewhere as "read-only" (mount -r, mount -o=ro), and back the files up from there. It worked, but I was unable to umount that 'read-only' system after I was done, until I either logged out or had to reboot (can't remember which).

    I use Clonezilla for the openSUSE system drive/partition, and its partition is not an issue at this time (I suspect I can't make a duplicated reference to the system drive as read-only, don't know) ... since I could restore a backup with Clonezilla and update any updated files with the YaST Software Management that have been updated since the such an backup occurred.

    Let me give you an example from the manual for "star":
    Code:
    -atime, -a
    Reset access time of files after storing them to tarfile. On Solaris 2.x, (if invoked by root) star uses the _FIOSATIME ioctl to do this. This enables star not to trash the ctime while resetting the atime of the files...[text removed for brevity and content]...
    Another option to retain the access time for the the files that are going to be archives is to readonly mount a UFS snapshot and to archive files from the mount point of the UFS snapshot.
    But the only other info I see on this "UFS" mount seems to be related to file servers and remotes:
    Code:
    echo > /tmp/snapstamp 
    
    mount -r `fssnap -F ufs -o \ 
        backing-store=/var/tmp/EXPORT-NFS.snap /export/nfs` /mnt 
    
    star -c -xdev -sparse -acl -link-dirs level=0 -wtardumps \ 
        f=archive-name dumpdate=/tmp/snapstamp \ 
        fs-name=/export/nfs -C /mnt .
    Cliff

  3. #13
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    On 2013-12-22 00:56, Star Gazer wrote:
    >
    > robin_listas;2610502 Wrote:
    >> On 2013-12-21 22:56, wolfi323 wrote:
    >>>> But I've often been curious as to why the /mnt/ is even there ...
    >>> I think /mnt was originally there to be able to mount your root file
    >>> system in the rescue system or something like that.

    >>
    >> I understand it is the standard place for manual, non default, mounts.
    >>

    >
    > But what do you mean by "non default" ? Like for Digital Cameras, DVD/CD
    > Drives, or USB Flash Drives?


    Those things usually mount automatically, you don't need to do it.

    > I have 2 of my partitions, one at the end
    > of Hard Disk #1 for stowage (like for software downloads and other
    > stuff), "/media/stowage", and all of Hard Disk #2 primarily for backups,
    > "/media/spare". These partitions I need to have mounted at boot-up, or
    > at least I prefer it that way.


    Well, what I say is that it is better to mount that at "/mnt/stowage". When I see that I know that
    you mounted it, that it was not mounted by the desktop automatically or something.

    If I mount something permanently, from fstab, I typically use "/data/something".

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" (Elessar))

  4. #14
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    On 2013-12-22 02:36, Star Gazer wrote:

    > home user directory, mount that system elsewhere as "read-only" (mount
    > -r, mount -o=ro), and back the files up from there. It worked, but I was
    > unable to umount that 'read-only' system after I was done, until I
    > either logged out or had to reboot (can't remember which).


    Try to umount it with "umount -v ....". You should get a reason why you can not.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" (Elessar))

  5. #15
    Join Date
    Feb 2010
    Location
    South Dakota, USA
    Posts
    171

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    Quote Originally Posted by robin_listas View Post
    On 2013-12-22 02:36, Star Gazer wrote:

    > home user directory, mount that system elsewhere as "read-only" (mount
    > -r, mount -o=ro), and back the files up from there. It worked, but I was
    > unable to umount that 'read-only' system after I was done, until I
    > either logged out or had to reboot (can't remember which).


    Try to umount it with "umount -v ....". You should get a reason why you can not.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" (Elessar))
    The response I got back when trying to umount the read-only copy was that "the system is busy".

    Cliff

  6. #16
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    On 2013-12-22 22:36, Star Gazer wrote:

    > The response I got back when trying to umount the read-only copy was
    > that "the system is busy".


    Then find out why. Use "lsof /pathtoromount"

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" (Elessar))

  7. #17
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,273
    Blog Entries
    2

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    It's possible you might have an app running that's still accessing the mount point. Or, an app can be faulty and not close completely and properly (terminating all related processes).

    If you're <absolutely sure> you have nothing that should be accessing the mount point, you can try "force umount" (see the help and man pages).

    TSU

  8. #18
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    On 2013-12-23 17:06, tsu2 wrote:
    >
    > It's possible you might have an app running that's still accessing the
    > mount point. Or, an app can be faulty and not close completely and
    > properly (terminating all related processes).
    >
    > If you're <absolutely sure> you have nothing that should be accessing
    > the mount point, you can try "force umount" (see the help and man
    > pages).


    That will probably crash whatever app is accessing, and perhaps corrupt some files.

    The service "famd" can cause these symptoms.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" (Elessar))

  9. #19
    Join Date
    Feb 2010
    Location
    South Dakota, USA
    Posts
    171

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    Quote Originally Posted by robin_listas View Post
    On 2013-12-22 22:36, Star Gazer wrote:

    > The response I got back when trying to umount the read-only copy was
    > that "the system is busy".


    Then find out why. Use "lsof /pathtoromount"

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" (Elessar))
    Thanks for the info

  10. #20
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,273
    Blog Entries
    2

    Default Re: Snapshot / Clone a Directory/Disk for Backup purposes

    Quote Originally Posted by robin_listas View Post
    On 2013-12-23 17:06, tsu2 wrote:
    >
    > It's possible you might have an app running that's still accessing the
    > mount point. Or, an app can be faulty and not close completely and
    > properly (terminating all related processes).
    >
    > If you're <absolutely sure> you have nothing that should be accessing
    > the mount point, you can try "force umount" (see the help and man
    > pages).


    That will probably crash whatever app is accessing, and perhaps corrupt some files.

    The service "famd" can cause these symptoms.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" (Elessar))
    Actually, I've found this not to be the case (corruption) if you're absolutely certain nothing is accessing file in the mount.
    One way to verify is to look at the disk activity light. If it hasn't blinked in over a minute, it's unlikely anything is happening even on a "busy" machine.

    At least for me, I experienced an app that apparently was poorly written, leaving a thread or process connecting to the mount point even when the app was closed... So I deemed it safe to forcibly unmount in my case.

    But I agree that you better be sure... Particularly if you're doing a command line file operation. But from what I've seen I suspect that even similar file operations likely are executed differently to ensure file integrity (typically using temp files which are removed after the operation has completed).

    TSU

Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •