# Using DUMP to backup FreeBSD



## Kreme (Jan 7, 2018)

In preparation for moving to new hardware I am using dump to try to backup the entire OS, the problem is it appears to be skipping /usr/ even though that is not a separate mount point, which is fine as it is the documented behavior. The toruble is if I try to use dump to backup /usr, it tells me it is an "Unknown file system"

Also, 15 hours seems a very long time to backup a little over 30GB maximum (and that is assuming it is, despite appearances, backing up /usr/ which is half that)

Or should I be doing something else entirely?

https://www.freebsd.org/doc/handbook/backup-basics.html


----------



## ShelLuser (Jan 7, 2018)

Dump only backs up entire UFS slices. So no separate directories; if /usr isn't a separate file system then you cannot back it up individually using dump.

Can't really comment on the rest because you're not giving enough information for that. For example: the time to make a backup doesn't only depend on the size. If you copy your data onto another machine (for example using ssh and dd) then it can take a lot longer than if you dump it directly onto another HD.


----------



## obsigna (Jan 7, 2018)

dump(8)/restore(8) has always been slow, see https://forums.freebsd.org/threads/37447/#post-207475

PS:
Since then, clone(1) has made it into the ports, see sysutils/clone


----------



## chrbr (Jan 7, 2018)

Kreme said:


> I am using dump to try to backup the entire OS, the problem is it appears to be skipping /usr/ even though that is not a separate mount point


May be the nodump flag is set for /usr. This flag is useful for intentional skipping of parts of a file system. Please see chflags(1).


Kreme said:


> Also, 15 hours seems a very long time to backup a little over 30GB maximum


This is by far too long. In my opinion the best reference is http://www.wonkity.com/~wblock/docs/html/backup.html. There are explanations and examples with best practice settings of as blocksizes and so on. And if you have not been aware of this page do not miss the other articles.


----------



## SirDice (Jan 9, 2018)

It's typically faster to install a brand new OS and only migrating the data. As noted by others dump(8)/restore(8) is a very slow process.


----------



## Kreme (Jan 11, 2018)

SirDice said:


> It's typically faster to install a brand new OS and only migrating the data. As noted by others dump(8)/restore(8) is a very slow process.



If all goes well, that is what will happen. I now have three copies of everything on the drive in three different locations (external drive, Dropbox, my home computer).


----------



## gpw928 (Jan 11, 2018)

I echo the thoughts of SirDice. 

I have not used dump/restore in ages, and mostly rely on rsnapshot for backups (requires all hosts to trust root's RSA key on the ZFS server).

If I need to recover an O/S, I can rebuild it, and pick the config bits out of the last snapshot.

For recovering the user data (ordinary files and directories) from the snapshot or copying it to external media for off-site backup,  "rsync -SHAXax" duplicates tree hierarchies (fairly) faithfully, and is agnostic about the specific operating system(s) so long as they look like Unix.


----------

