Differences

This shows you the differences between two versions of the page.

--- bare_metal_linux_backups_with_rdx [2019/02/15 16:10] – [Using Dump for Backups] sgriggs
+++ bare_metal_linux_backups_with_rdx [2019/02/15 16:29] – sgriggs
@@ Line 36: / Line 36: @@
 So, how does one use dump? Well, for starters the [[https://linux.die.net/man/8/dump|man page]] is the best reference for it. Keep in mind dump will work against a raw device like a tape drive or RDX drive just as easily as it will to a file on a file system. So, you really have two choices:
   - Dump straight to your RDX as if it was a tape drive.
   - Create a filesystem on your RDX, mount it, and then dump to a file on the RDX.
-The first method is more simple and mimics how tape drives work for those really used to tape. The second is more friendly to someone who might come along later and wonder what is on that drive. The second method also gives you the option to compress the dump before writing it to the filesystem. That's more complicated and makes things that much more opaque if you use compression with a direct-to-device dump. So, for most folks, I'd recommend going ahead with using a filesystem as it provides better clarity and usability with compression.
+The first method is more simple and mimics how tape drives work for those really used to tape. The second is more friendly to someone who might come along later and wonder what is on that drive. The second method also gives you the option to compress the dump before writing it to the filesystem. That's more complicated and makes things that much more opaque if you use compression with a direct-to-device dump. So, for most folks, I'd recommend going ahead with using a filesystem as it provides better clarity and usability with compression. Another big drawback is that you'd need to use some kind of tape marker to separate backups if you wanted to take more than one using the no-filesystem method.
 === Dump Prerequisites ===
@@ Line 107: / Line 107: @@
+=== Dump Straight to RDX ===
+This is a similar process as using a filesystem without the partitioning and mounting step. So, having gone over some of the process, I'll condense this example somewhat.
+<code>
+## Double check my filesystems so I know what I'm dumping
+$ mount
+## Find my RDX Drive by exploring the drives on the system
+fdisk -l
+ls /dev/disk/by-id
+## Perform the dump straight to the RDX without mounting it.
+## in this case, my RDX was found to be /dev/sdb and I ignore
+## any partitions on it, going straight to the raw device
+dump -0f /dev/sdb /
+## Remember we can only dump one filesystem unless we use tape marks.
+## so don't use this method unless really know what you are doing.
+</code>
+==== Using Tar for system backups ====
+Tar (and by extension other file archivers like **pax** and **cpio**) can also work for system backups. Here are the pros and cons.
+Advantages of using **tar** for backups:
+  * Tar is fast
+  * Tar is broadly compatible. You'll be able to dig into the archive with many tools on many OSes.
+  * Tar doesn't implement compression, leaving you free to compress tar files with anything you want
+  * It can go direct to a tape or disk device like **dump** but it also to a file.
+Drawbacks of using **tar** for system backups:
+  * Tar doesn't do estimates of when it'll complete. It just goes and goes sequentially until done.
+  * Tar isn't as pedantic about weird files like named-pipes or FIFO files. It might not archive them as well as **dump** but most people don't care and don't need that to work anyway as most of those types of files are created dynamically.
+  * By default, tar won't care if it crosses a filesystem boundry. This can cause problems and I recommend you use the **--mount**  or **--xdev** flags when doing system backups to avoid this issue. Backup the filesystems separately or use exclude lists
+  * Tar isn't smart enough to automatically avoid synthetic filesytems like **/proc** or **/sys**, or
+=== Tar examples ===
+For doing system backups there are two things I recommend you do that are not tar's default behavior.
+  - Do not let it cross file systems.
+  - Do not let it backup in-memory filesystems like /proc
+So, in my example, let's say I have three critical filesystems that are part of my OS build. They are **/**, **/usr**, and **/home**. I want to dump them to an RDX with a filesystem because I don't want to fiddle with any direct-to-device backups. Here goes.
+<code>
+## Double check my filesystems so I know what I'm dumping
+$ mount
+## Find my RDX Drive by exploring the drives on the system
+fdisk -l
+ls /dev/disk/by-id
+## Put a partition on the RDX drive, in this case /dev/sdb
+fdisk /dev/sdb
+## If the disk has partitions you want to delete, do so with "d"
+## Then use "n" for new partition and take the defaults. It defaults to Linux
+## then hit "w" to save/write and quit from fdisk.
+## Put a filesystem on the partition
+mkfs /dev/sdb1
+## Mount the RDX filesystem on the /backup directory
+mount /dev/sdb1 /backup
+## Perform the tar backups one FS at a time using GZIP compression
+tar -c --one-file-system -vzf /backup/root_backup.tar.gz /
+tar -c --one-file-system -vzf /backup/usr_backup.tar.gz /usr
+tar -c --one-file-system -vzf /backup/home_backup.tar.gz /home
+</code>