How to do a full system backup of freebsd so i can boot from it if my current system fails

Hi I'm very new to FreeBSD. Anyone know how I would go about doing a full system backup of FreeBSD that I could keep to boot from and restore my system in case my install gets corrupted?
I have been looking for what utilities to use and the steps to use them to create an exact replica of my FreeBSD system in case I need to restore to new hardware.
I have the "data" backed up already by other means, but I would like to know if there is a way to create an image of the current system that could be restore in the event of a disaster.
Disk space is not a concern, I have terabytes of disk space.
I live in an areas where we have fairly frequent violent lightning storms and our electricity goes out. I do have UPS power backups. But want to make sure if something bad happens I can restore to new hardware very quickly without having to re-install FreeBSD again.
In windows this is very, very easy. In Linux Ubuntu this is very, very easy. Seems to be very limited info on how to do this for FreeBSD.
 
In windows this is very, very easy. In Linux Ubuntu this is very, very easy. seems to be very limited info on how to do this for FreeBSD.
In FreeBSD it is sane.

Backup:
Prepare a list of installed packages:
pkg prime-list > pkglist
Backup your settings and home directory (following is an example, change it to match yours):
Code:
mkdir -p /backup/boot
mkdir -p /backup/usr/local
rsync -a /boot/loader.conf /backup/boot
rsync -a /etc /backup
rsync -a /usr/local/etc /backup/usr/local
rsync -a /usr/home /backup/usr

Restore:
Install FreeBSD in the usual way.
Install packages:
cat pkglist | xargs pkg install
Restore settings and home directory:
Code:
rsync -a /backup/boot/loader.conf /boot
rsync -a /backup/etc /
rsync -a /backup/usr/local/etc /usr/local
rsync -a /backup/usr/home /usr
 
Let’s assume, you prepared the recovery disk /dev/adaX as follows (here X is the placeholder for the actual index of the disk’s device identifier):
Code:
gpart destroy -F adaX
gpart create -s GPT adaX
gpart add -b 40 -s 128 -t freebsd-boot adaX
gpart add -s 1880 -t efi adaX
gpart add -s 4G -t freebsd-swap -l SWAP adaX
gpart add -t freebsd-ufs -l RECOVER adaX

gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 adaX
gpart bootcode -p /boot/boot1.efifat -i 2 adaX
gpart set -a bootme -i 4 adaX

newfs -ntEU /dev/adaXp4
tunefs -a enable /dev/adaXp4
Then you could use sysutils/clone to make a perfect clone of your system’s startup disk as follows:
Code:
mount -o noatime /dev/gpt/RECOVER /mnt
clone -c rwoff / /mnt
After the file system cloning has finished, you only would need to edit /mnt/etc/fstab:
Code:
# Device            Mountpoint      FStype  Options Dump    Pass#
/dev/gpt/RECOVER    /               ufs     rw      1       1
/dev/gpt/SWAP       none            swap    sw      0       0
proc                /proc           procfs  rw      0       0
Ready.

PS: clone(1) can be used to keep file systems synchronized, and you would use the very clone command together with the -s flag for keeping your recovery disk updated. In this mode only changed files would be copied and synchronization needs much less time than the initial full cloning process.
 
but want to make sure if something bad happens i can restore to new hardware very quickly without having to re-install FreeBSD again.
It can be quite useful to start again with many operating systems - cleans out all the cruft from previous installs, updates, etc. so I tend to focus on copying my /home directory and maybe /etc (and others depending on the machine.)

But I understand if you just want to get things up and running after a power event you won't want to spend the time re-installing so I appreciate I'm not answering your question so 🤐
 
The "howto" section is not for asking how to do things. Thread moved.
 
It's defined in /usr/local/etc/pkg.conf, as are a few other nice aliases.

Code:
ALIAS              : {
  all-depends: query %dn-%dv,
  annotations: info -A,
  build-depends: info -qd,
  cinfo: info -Cx,
  comment: query -i "%c",
  csearch: search -Cx,
  desc: query -i "%e",
  download: fetch,
  iinfo: info -ix,
  isearch: search -ix,
  prime-list: "query -e '%a = 0' '%n'",
  prime-origins: "query -e '%a = 0' '%o'",
  leaf: "query -e '%#r == 0' '%n-%v'",
  list: info -ql,
  noauto = "query -e '%a == 0' '%n-%v'",
  options: query -i "%n - %Ok: %Ov",
  origin: info -qo,
  provided-depends: info -qb,
  rall-depends: rquery %dn-%dv,
  raw: info -R,
  rcomment: rquery -i "%c",
  rdesc: rquery -i "%e",
  required-depends: info -qr,
  roptions: rquery -i "%n - %Ok: %Ov",
  shared-depends: info -qB,
  show: info -f -k,
  size: info -sq,
  }
 
What's missing is my standard disclaimer: message: 'query '[%C/%n] %M'' IMHO it should be added, it's really usefull to do pkg message|less after installing a bunch of packages, e.g. a GUI. Many issues are rooted in people not reading through these messages & do not configure their system. Especially Linux users, because there, the package manager does the configuration for them (optionally, but enabled by most). I did not find out how to do an rmessage alias.
 
bgillette , you might want to have look in this thread. The OP sets up a mirror, pulls out one disk so the mirror runs in degraded mode. Then, periodically s/he puts in the drive, lets the mirror resilver and pulls it out again ( zpool on/offline). That's not a perfect solution (no extra dedicated backup), but an easy way to always (strictly spreaking, very likely in most cases) have a method to quickly get up the system in case of a failure.
 
Time. Taking too long to complete. One accident and have to start again. That's my uneducated thoughts. correct me if I'm wrong. thanks.
The secret of dd(1) is to choose the right blocksize. Then it's fast. BUT I wouldn't recommend it, at least not for different disk models. It's much safer to do dump(8)/restore(8) (UFS) or ZFS replication.
 
  • Like
Reactions: a6h
On UFS IMHO dump(8)/restore(8) is the most reasonable. Insert the I/O scheduler (search the thread usefull scripts for my post) and then it's fast enough (espc. the incremental backups). In general, it's perfectly OK to just backup data incl. configuration and do a reinstall when a system has crashed. This whole topic highly depends on personal & business (use-case) preferences, it's no surprise that there are so many solutions available in the ports. E.g. I'm about to bring my previous laptop back to life, and will then periodically mirror (with zfs send/receive) my personal data & config files between two laptops, excluding what can easily be rebuild or downloaded. For these parts, a list (e.g. pkg prime-list) is sufficient. YMMV. It's funny that today we see some rather creative use of storage configuration setup here in the forum ;)
 
  • Like
Reactions: a6h
bgillette , you might want to have look in this thread. The OP sets up a mirror, pulls out one disk so the mirror runs in degraded mode. Then, periodically s/he puts in the drive, lets the mirror resilver and pulls it out again ( zpool on/offline). That's not a perfect solution (no extra dedicated backup), but an easy way to always (strictly spreaking, very likely in most cases) have a method to quickly get up the system in case of a failure.
That's more or less what I'd personally do. Except that I'd have the spare drive connected most of the time via eSATA and just disconnect it when there's lightning in the forecast. This would require 3 disks to maintain the mirroring. I don't typically run ZFS without it. Obviously, I'm assuming that this isn't a daily occurrence. Make sure that the mirror drive is more or less a clone of the others and that it has the relevant bootcode. That way you can be up and running immediately.

We don't get much lightning around here, so I just have a pair of internal HDD like that, but I've replaced mirrors multiple times without ill effect. The big challenge is that you need to have both drives with the same amount of space, exactly. Copying the partitioning to a slightly larger disk should work just fine.

And obviously, the OP would still need regular backups as this would only deal with a specific source of data loss, not the more common fat fingering that can happen.
 
Some points to keep in mind:
  1. It's a good idea to have a backup stored at a distant place (different room at least), that is safe in case of a fire, severe tempest or other catastrophy (earthquake, vandalism, robbery, ...)
  2. As disk sizes grow, the probability of bit failures rises. Simple statistics. For disks bigger than approx. 9 TB, a 2-way mirror or standard RAID can not be considered safe anymore. A 3-way mirror or RAIDZ-2 (or 3) is then strongly advised.
  3. A permanent online mirror or RAID does not help in case of a human (admin's) mistake, or e.g. a virus causing data corruption. Snapshots might help, but not in all cases (silent data corruption). Only a backup can provide cure in these cases. RTFM dump(8) for common proven backup strategies.
  4. Check & verify the backup! Train a restore manœvre regulary (annually). Have a recipe written down on paper and note any tips & tricks in a logbook.
  5. Make shure you can access the backup with least effort/indirections/additional tools as possible.
    How will you download all the additional tools when your internet connection is cut for a week after a hurricane? Ideally, only tools from the OS base should be involved. If not, have the additions on your recovery thumb drive (for instance).
 
Please forgive my ignorance, but the above statement makes not sense to me.
Is it a sense of humour thing I am missing......
As an Administrator and moderator of the forums, he's working to keep things organized according to plan, by moving your thread into the proper section. No big deal, just taking care of business. Nothing wrong with your thread, it just got started in the wrong section. Welcome to the forums!

Please review rule #8:

... and the guidelines for the how-to section:
 
I have installed a fresh copy of FreeBSD (the same version of the source installation) on another disk and then I've copied all its files to a directory called "old" ; then I came back to the FreeBSD system that I have configured like I want and I did :

Code:
cd /
rsync -avxHAX * /mnt/da0p2

as final step I've gone inside the old folder and I've copied the fstab file from old to /. the end. it worked. I think that rsync allows me to update only the new files produced on the source system to the new system,not everything everytime.
 
Please forgive my ignorance, but the above statement makes not sense to me.
I think the point is that the "howto" section is for supplying instructions on how to do something. So how to set up graphics, how to set up sound, how to set up MySQL. Giving solutions/instructions.

It's not for ASKING how something is done - so it's not for questions or requests for help on how to do a task - ask that sort of question in the appropriate area.

Maybe the discussion around your question will make someone go "oh, this should be written up in the how to section".
 
For those using rsync(1), beware that archive mode does not preserve hard links, ACLs, sparse files, or extended attributes.
This presents a serious issue for "correctness" if you are just using rsync -av. For example, there's a lot of hard links in FreeBSD file systems:
Code:
[f13.146] $ sudo find / -mount -type f -links +1 | wc -l
   15183
[f13.147] $ sudo find /usr -type f -links +1 | wc -l
   13491
None of these hard links are preserved by default with rsync. And any restoration of these data would be compromised.
The emphasis that rsync places on performance over correctness is disappointing. Caveat emptor. I always use rsync -SHAXax.
 
Back
Top