Other Backing up to an ext4 external disk

[CShell]

1. boot into linux in order to copy/write a file from an ext4 partition to a Fat32 partition.
then
2. reboot into FreeBSD in order to copy/write that file from the Fat32 partition to UFS/ZFS.

So .. ya .. I have pushed one-to-many files using FAT32 between FreeBSD and Linux (or) Linux and FreeBSD in the past but not with full on backups. I was moving a lot of smallish individual files around between FreeBSD and Linux and that was a fast and easy was to do that.

(BUT) you can run into MAX SIZE file issues with FAT32 so it's not a slam dunk. In fact I had to abort (one of my) copies because something I was moving was too large for FAT32 and FAT32 did not like it. It wasn't a deal breaker because I could (also) push the files FAT32 was unhappy with over the network (aka sftp, SAMBA/CIFS, etc) between the hosts.

For full on backups I would NOT recommend doing this.

 

[CShell]

Ah ok - I think you are indicating that when you "turn on your PC" you have a "boot menu" and then you select either FreeBSD or Linux (and/or Windows?) to boot. Got it - I did that as well many years ago and it worked fine. I actually purchased "PC software" that set this up for me on boot back in the day -- today most people use Grub or similar.

I think Alain De Vos has given you a good solution to try

I use ext3 to backup. FreeBSD is good at working with ext3.

So then you just install/connect the backup drive either (into the PC case or just connect drive using USB A or C) formatted using either ext3 (and Kent Dorfman even recommends ext2) -- and if both Linux and FreeBSD can recognize the drive after you boot -- you are good to go!

If you have a Windows piece that you (also) want boot and work with as well that could be trickier? You would need to find a way to mount an ext2 or ext3 formatted drive to Windows.

 

[willie]

"boot menu"

My pc, an older Lenovo thinkpad actually, can be provisioned with 3 internal disks. So while I have in the past dual booted multiple OS's from the same disk, I find it simpler to choose a disk from the BIOS boot menu, and that way keep disks dedicated to a single OS install. My backup SSD disk tethers with a USB.

formatted using either ext3 (and Kent Dorfman even recommends ext2) -- and if both Linux and FreeBSD can recognize the drive after you boot -- you are good to go!

Using UFS presently and still need to see if the linux install will at least mount a UFS partition ro.
My original question was about best practices, so I will assume the advice posted thus far is qualified as such. That said, I am surprised that many here suggest Fat32 or ext2,3 as a go between for read only let alone write. I do think I will incorporate a UFS partition on my backup disk, even if it has to live alongside a FAT32 and a ext2/3/4 partition.

 

[T-Aoki]

That said, I am surprised that many here suggest Fat32 or ext2,3 as a go between for read only let alone write.

It would be because external filesystems are usually developed for read-only, then, developed for writes if there are known huge enough number of requests. So write supports are usually far more delayed to be implemented.

Supporting reads can be done by analyzing written disks / partitions with known structure and contents, by the skilled and experienced developers (UNLIKE me), even if precise documentations does NOT exist.

But supporting writes are far more difficult to be safe.
Imagine if some specific things (i.e., long filenames, extended attributes and any other system-specific data depending on OS to sanely access files / work with it) is NOT stored in the filesystem structure itself, like EA DATA.SF in OS/2 FAT or rr_moved in Rock Ridge extention in CD-ROMs. And considerations is needed that these system files can be fragmented or not. Etc, etc.

So the older and widely-used the filesystem is, more possibilities to sanely write into by multiple OS'es. ext4 is tooooooo new. But ZFS has OpenZFS implementation that is for multiple OS'es in mind. But ZFS is quite special case.

 

[cracauer@]

using ZFS for transportable backups is foolish and I'd chastise my engineers with "bad engineer! no cookie!" for such a path. a low denominator like EXT2 or FAT32 would be preferred, especially when layering backup data in something like tar and limiting archive filesize. KISS, keep it simple, stupid.

How is using a tarfile in a filesystem for backup KISS? It's stupid. You start the tarfile over every time you do a backup. If you lose some hardware during this time you lose both primary and backup data. Of course fat32 is entirely unsuitable for tarfiles because of the file size limitation.

ZFS is not the simplest filesystem but lacking a regular simple filesystem with enough functionality and acceptance of platforms it is the next best thing.

 

[Alain De Vos]

Local you do :

tar -cf - /path/to/source | split -b 1g - backup_part.tar.

Then you just copy them over from ufs/zfs to anything ...

 

[kent_dorfman766]

How is using a tarfile in a filesystem for backup KISS? It's stupid. You start the tarfile over every time you do a backup. If you lose some hardware during this time you lose both primary and backup data. Of course fat32 is entirely unsuitable for tarfiles because of the file size limitation.

ZFS is not the simplest filesystem but lacking a regular simple filesystem with enough functionality and acceptance of platforms it is the next best thing.

Then you are not using tar correctly. It recognizes and accepts mutl-volume backups. Thereby bypassing the FAT32 size restriction. I realize ZFS is the freeBSD golden haired baby but it is way complex and convoluted for a backup media base. Historically tar is the universal archive format. Stick with what has history behind it, especially if the data might need to be moved to a non BSD system, or worse translated into a different encoding type. and as far as starting tar over...well, it DOES allow for incremental backups based on a parallel metadata file listing of content.

Actually I will concede that FAT32 has serious limitations for large backups/files, but EXT2 doesn't...and ZFS is still stupid/silly if transportability is an issue.

 

[Alain De Vos]

To share between linux & freebsd my take is ext3.
Maximum file size of fat32 is 4GB, so "split -b 1g" is ok.

 

[willie]

ZFS is not the simplest filesystem but lacking a regular simple filesystem with enough functionality and acceptance of platforms it is the next best thing.

I have created a ZFS internal test disk to familiarize my self with some of its benefits. (The redundancy of snapshots primarily).

cracauer@
Can you suggest a way to store ZFS snapshots on a non ZFS external disk should I want to also use snapshots for backups?

kent_dorfman766
much to said for KISS and tar.

incremental....based on a parallel metadata file listing of content.

Not sure I follow...
are you using tar with -u (--update) or gtar?