# FreeBSD Dump to usb drive



## Understudy (Feb 3, 2013)

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. 


```
$ 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:


```
$ 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:


```
# dump -OaLuf /usb /dev/mirror/root
```


I assume the follow up command is going to be something like:

```
# dump -1aLuf /usb /dev/mirror/root
```

Sincerely,

Brendhan


----------



## jb_fvwm2 (Feb 3, 2013)

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).


----------



## wblock@ (Feb 3, 2013)

Understudy said:
			
		

> I have a live server. I want to do a complete dump to a usb hard drive.
> The setup looks like this:
> 
> 
> ...



That is not necessary.  What filesystem is on the USB drive?  Please don't say NTFS.



> 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.



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



> 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.



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.



> So if I do the following am I screwed:
> 
> 
> ```
> ...



No, but that won't quite work.  /usb is a drive.  Write to a file on that drive:

```
# dump -C16 -b64 -0aLuf /usb/backup-2013-02-02.dump /dev/mirror/root
```

-C16 -b64 will increase the speed.


----------



## Understudy (Feb 3, 2013)

wblock@ said:
			
		

> That is not necessary.  What filesystem is on the USB drive?  Please don't say NTFS.



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. 



> Now this is till early on so let me not freak anyone out. The /usb (da0s1) will be zero out before I get started.





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



Okay I am liking this. 

Here is the fun thing. 


```
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


----------



## wblock@ (Feb 3, 2013)

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.


----------



## kpa (Feb 3, 2013)

> I know you said it does not cross filesystems but the the usb is ufs.



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.


----------



## Understudy (Feb 3, 2013)

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


----------



## Understudy (Feb 3, 2013)

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


----------



## wblock@ (Feb 3, 2013)

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.


----------



## vince66 (Mar 18, 2018)

Hello guys,

please, let me ask some informations about usbdump.

Plugging in an hard disk into the sata hot-port, I've noticed that the inserting operation was detected by the chip and a counter inside its memory has been incremented by one every time the hatd disk was inserted. So a write operation has been happen !!!!!! The drive in question is a solid hard disk SSD 1TB Samsung 850 EVO Sata III.
This test, however, has been done on a Linux O.S that is a very disaster in terms of security policy, due to the demons of the GUI !

That sounds more like something done by the BIOS, as discussed in the thread: file permissions at boot level.

If I enclose the hard disk into a usb box, can I use usbdump to keep track on (sniff)  events that transit from the bios to the usb drive ?

Any tips are appreciated.

Thanks a lot in advance.


----------

