1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

FreeBSD Dump to usb drive

Discussion in 'Storage' started by Understudy, Feb 3, 2013.

  1. Understudy

    Understudy New Member

    Messages:
    87
    Likes Received:
    0
    Hi,

    I have looked through several threads here and on google and may have overdone it and caused my brain to melt.

    Here is what I have.

    Code:
    $ uname -a
    FreeBSD spider.brendhanhorne.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:15:25 
    UTC 2012     root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
    
    
    I have a live server. I want to do a complete dump to a usb hard drive.
    The setup looks like this:

    Code:
    $ df -h
    Filesystem          Size    Used   Avail Capacity  Mounted on
    /dev/mirror/root    358G     56G    273G    17%    /
    devfs               1.0k    1.0k      0B   100%    /dev
    /dev/da0s1          458G    162G    259G    38%    /usb
    
    
    Now this is till early on so let me not freak anyone out. The /usb (da0s1) will be zero out before I get started.

    What I want to do is a complete dump to the usb. One of my concerns is how to not cause a redundant loop. If I do a complete backup I don't want it to try and dump /usb to /usb. That would be bad as I understand it.

    In addition I would like to do a incremental dump that will add only new or updated file information. I would add that as a cron job to a script.

    So if I do the following am I screwed:

    Code:
    # dump -OaLuf /usb /dev/mirror/root
    

    I assume the follow up command is going to be something like:
    Code:
    # dump -1aLuf /usb /dev/mirror/root
    
    Sincerely,

    Brendhan
     
  2. jb_fvwm2

    jb_fvwm2 Member

    Messages:
    1,567
    Likes Received:
    1
    Early in my usage of FreeBSD, I repeatedly wrecked UFS filesystems writing to them on usb disk(s) (IIRC). (usb drivers, disk firmware, ... ?). I can write full-speed (not too much data at once) to a thumbdrive, read full-speed FROM the thumbdrive, gcp (with a sleep 1 programmed between a many-file write, but for backup purposes, I'd recommend the rsync command with the bwlimit parameter (1000 or 2000 or so, see the forum threads which contain bwlimit.; it seems to go hayware much less often (sata devices and firmware...), and when it does, it is simple to fsck_ffs -y (despite the SUJ journal disappearing, never to return sometimes, rendering the /dev/ad10.journal simple /dev/ad10, to fsck_ffs the latter rather than the former... OTOH, I have not used USB drives in years, others could maybe answer with more direct solutions to the question.
    Further, the usb drivers were IIRC entirely rewritten since that time (referenced in my first sentences above).
     
  3. wblock@

    wblock@ Administrator Staff Member Administrator Moderator Developer

    Messages:
    11,196
    Likes Received:
    14
    That is not necessary. What filesystem is on the USB drive? Please don't say NTFS.

    It won't happen. dump(8) does not cross filesystems.

    dump(8) can do that, but it makes the backup more fragile. Restores take the original level 0 dumpfile plus all the ones made since then. I personally don't use anything but level 0.

    No, but that won't quite work. /usb is a drive. Write to a file on that drive:
    Code:
    # dump -C16 -b64 -0aLuf /usb/backup-2013-02-02.dump /dev/mirror/root
    
    -C16 -b64 will increase the speed.
     
  4. Understudy

    Understudy New Member

    Messages:
    87
    Likes Received:
    0
    No it is ufs. I used it before to backup a freebsd 8 laptop that now has been upgraded. That is why I said this.

    Okay I am liking this.

    Here is the fun thing.

    Code:
    spider# ls -a /
    .               backup          home            proc            usb
    ..              bin             lib             rescue          usr
    .cshrc          boot            libexec         root            var
    .profile        dev             media           sbin
    .snap           entropy         mnt             sys
    COPYRIGHT       etc             nfs             tmp
    
    Within the / is usb which if I execute the command makes me worry that it will go into a loop. Is there any cause for worry on that? I know you said it does not cross filesystems but the the usb is ufs.

    My reason for doing an incremental dump(8) was that the usb drive is basically the same size as the hard drive on the server. So I figured as the server had more room taken up it did not have to do a complete overwrite each time. It would only do a dump of the new or changed items. From what I understand in your post you are saying it is easier to just do a daily dumps of a few hundred gigs of data?

    Sincerely,

    Brendhan
     
  5. wblock@

    wblock@ Administrator Staff Member Administrator Moderator Developer

    Messages:
    11,196
    Likes Received:
    14
    The USB drive is mounted on /usb, but it is not part of that filesystem, it is a separate filesystem. A separate newfs(8) command was used to format it. So no, dump(8) will not cross from the filesystem being dumped over into other filesystems that are mounted.

    As far as backup schemes, it really depends on what you are doing, what is available, and what the budget allows. If higher-level dumps are required, do that. It would be a good idea to practice restoring some sample files from a set of those backups. That's a good idea for any type of backup, for that matter.
     
  6. kpa

    kpa Member

    Messages:
    4,001
    Likes Received:
    8
    The word "filesystem" has a few different meanings depending on context. A filesystem can be of certain type, UFS, FAT, ZFS etc. Or the word can mean data stored on the disk using a certain filesystem as files and directories and that filesystem mounted at a mountpoint. Wblock@ used the latter meaning here. In other words, dump(8) does not cross mountpoints.
     
  7. Understudy

    Understudy New Member

    Messages:
    87
    Likes Received:
    0
    My budget is I have a gpart(8) RAID 1 mirror on 2 drives. I have a usb drive.

    I agree that doing restores is a good idea. I want to understand my dump methods properly first.

    Baby steps.

    Sincerely,

    Brendhan
     
  8. Understudy

    Understudy New Member

    Messages:
    87
    Likes Received:
    0
    As I learn more I thought that dump(8) at 0 would make a full backup and than the incremental backup would update that dump file. The more I read on this the more it seems like that is not the case. Still learning.

    Perhaps the idea under my current thinking is that I would have a full dump on Sunday and do incremental backups the other 6 days and than start the process over again. I would do this with a script and a cron(8). Currently this is where my head is. Subject to more confusion as I continue to learn and ask questions.

    Sincerely,

    Brendhan
     
  9. wblock@

    wblock@ Administrator Staff Member Administrator Moderator Developer

    Messages:
    11,196
    Likes Received:
    14
    dump(8) writes a new file each time. Level zero saves all files, higher levels only save files that have changed. So if you accidentally delete a file on Thursday, you have to go back through the dumpfiles looking for it. If it changed on Wednesday, it will be in that incremental backup. Otherwise, you may have to try each one all the way back to Sunday, the level zero dump.

    sysutils/rsnapshot works well as an addition to other backup. It uses net/rsync and hard links to keep snapshots of directories you pick. Because of the links, it is highly space-efficient, only using more space for files that have changed. It can store the backup directories on other systems with SSH. Not a replacement for other backups, but a very nice accidental file deletion protection.