I have a copy of FreeNAS running off a live USB disk. And I'd like to make a backup of it.

While trying to avoid breaking a perfectly working system, would I be able to dd the disk while the OS is running?

Or would I have to shut the machine down and run dd off another machine?


You can run dd on the running disk. Doing so when there are heavy changes to the disk structure should be avoided. Also you should fschk the destination once you are done. The quieter the system is during the backup the better.

Running a cold backup (file system unmounted) is the best option if you want to use `dd'.

There are better options for backing up a running system.

  • tar or cpio will read the files and deals reasonably well with open files. You will likely miss some of the changes which occur during the backup.
  • rsync behaves like tar in respect to open files, and missing changes during the backup. It can be used to do the initial backup and does incremental backups very well. When running an incremental backup it can skip copying unchanged portions of file.

If you are backing up a file system with database datafiles investigate support for hot backups.

  • Good points on using higher-level tools - tar, cpio and rsync all work within the filesystem, so this may be appropriate. dd, OTOH, works directly with disk blocks, bypassing the FS. – Piskvor left the building Mar 4 '12 at 16:26

It is technically possible (as in "shooting-yourself-in-the-foot"), but highly unadvisable, especially if any of the disk's partitions are writable.

Picture this scenario:

  • dd starts reading the disk at the start, and merrily makes its way towards the end.
  • When it's halfway there, the OS writes a file to the disk. The file is somewhat fragmented though - one part of it is physically located towards the beginning of the disk, and another towards the end.
  • No problem for the OS - it writes the file just fine, and pushes it out of its write caches; it is now correctly written on the disk.
  • The problem is with your backup: dd has already gone past and copied the first part of the file, so it will capture an inconsistent state when it gets to the second part - each part will be from a different version!

If you're capable of remounting all the partitions on the USB disk as read-only, this problem shouldn't occur (emphasis on "should not"); this requires significant up-front install/offline preparation and boot-time setup for the / partition though - I don't think you can normally remount / r/o on-the-fly, there will be multiple things hanging off that requiring r/w access.

So, running the copy probably won't break the running system, but won't give you a workable backup, rendering the task moot. I highly recommend making the copy offline - which would require shutting down the machine.

  • 1
    Thanks for a great answer, I was hoping for an easy way out, but you are correct, I can't imagine a good scenario arising out of what you pointed out. – stuartc Mar 4 '12 at 16:49
  • 1
    @stuartc: It would require major cooperation from the FS driver - informing the copying process of every change that has happened since the copy started, and whether it gets to a consistent state. If this is a major issue, look into filesystems which support snapshotting, such as btrfs. – Piskvor left the building Mar 4 '12 at 16:54

You should never create an image of a mounted partition. No matter if you booted from it or not.

But you'll have a hard time trying to unmount the partition you booted from.


For this, I use dump(8) on FreeBSD. E.g. dump -auLf /mnt/some-other-disk/root.dmp /

The -L option allows the copying of a live file system by taking a snapshot.

The dumps can be restored by using restore(8).

It might only work with UFS; I am not sure about that.


It's amazing how many backup tips don't mention the following:

The linux system (and most multi-thread OS's) generally need to be quiescent while you are backing up and restoring.

This is most easily achieved by not running an OS on it while you're trying to image it.

For backup and restore, it can be mounted, and in-fact probably must be, but not by the running OS as its root (/).

Reason: In every multi-tasking operating system, linux included, there are simultaneous code threads running affecting files which makes it impossible to do accurate system-wide file-set backups or restores.

In particular, while you're grabbing files, there might be some other task creating or deleting files such that your backup won't represent a true and accurate image of the file-system at any given moment in time. If you try to restore this backup you will have data corruption which will lead to crashes, and other anomalies.

Options: Backups need to be either done by special software and/or disk systems (like Acronis on Windows for example which can backup a running OS), or by an external secondary OS accessing the non-running OS's files that you're trying to backup or restore.

!!! So when you see web pages telling you to use Deja-dup for example to do your backups, this only works for /home and then ONLY if you aren't running any programs affecting /home while you are running deja-dup. (And even then you might want to cross your fingers unless you really know what might possibly touch your files via a daemon.)


I already do this with sucess on test environment, with fsck and rsync in the end to improve the chances of a good device copy.

  • 2
    Can you explain how you use rsync to improve a whole-disk (whole-filesystem) dump made with dd? (And, if you have access to rsync, why wouldn’t you just use it as your primary backup tool rather than a secondary, companion one?) … … … … … … … … … … … Please do not respond in comments; edit your answer to make it clearer and more complete. – Scott Jun 28 '19 at 23:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.