NAS Backup Exclusions: What To Exclude?

Dec 8, 2025 by Alex Johnson 40 views

Hey there! So, you're looking to get your Odroid HC4 set up with a great backup script, and you've hit a snag with exclusions. That's totally understandable – when it comes to NAS devices and backup strategies, getting the exclusions right is super important to avoid headaches and ensure your backups are efficient and reliable. Let's dive into how to handle exclusions for your setup, especially when dealing with mounted drives and Btrfs.

Understanding Backup Exclusions

First off, let's chat about why exclusions are so crucial, especially for a NAS like your Odroid HC4. When you're running a backup script, its main job is to copy files from a source to a destination. However, not everything needs to be backed up, and sometimes, backing up certain things can cause more harm than good. Think about temporary files, cache directories, or even the backup destination itself! If you accidentally include the folder where your backups are stored within the backup process, you'll end up with a recursive nightmare – your backup folder will contain a copy of itself, which will contain another copy, and so on, leading to massive, unusable backup files and potentially filling up your storage faster than you can say "oops." This is where the exclusions.txt file comes in handy. It's your secret weapon for telling the backup script, "Hey, skip this stuff!"

Your Odroid HC4 Setup: A Closer Look

Now, let's apply this to your specific situation with the Odroid HC4. You've got a Btrfs filesystem mounted at /srv/btrfs, and within that, you have your data, snapshots, and a backup directory: /srv/btrfs/data, /srv/btrfs/.snapshot, and /srv/btrfs/backup. Your goal is to save the backup image to /srv/btrfs/data/backup. This is a common and smart way to organize things: keeping your primary data and your backup repository on the same underlying filesystem, but in separate logical locations. However, the potential for a recursive backup is very real here.

The Big Question: `/srv/*` Exclusion?

You're asking if you should add /srv/* to your exclusions.txt file. This is a great question, and the answer is it depends on your overall backup strategy and what else might be under /srv. If /srv only contains your Btrfs mount point (/srv/btrfs), then excluding /srv/* would effectively exclude /srv/btrfs. This is likely not what you want, as you need to back up your data which resides within /srv/btrfs/data.

Instead of a broad /srv/* exclusion, it's usually much safer and more precise to exclude the specific directories that should not be backed up. In your case, the most critical exclusion is your backup destination itself. If your backup script is targeting /srv/btrfs/data (or the entire /srv/btrfs mount point if that's your source), you absolutely must exclude /srv/btrfs/data/backup to prevent that recursive backup loop.

Let's consider the other directories you mentioned:

`/srv/btrfs/data: This is likely your primary data directory, and you want to back this up. So, you definitely do not want to exclude this from your main data backup.
**/srv/btrfs/.snapshot**: **Btrfs snapshots are special. They are point-in-time, read-only copies of your filesystem. If your backup script is designed to handle Btrfs intelligently, it might be able to back up the *live* data without needing to explicitly back up the snapshots themselves. However, if you want to preserve specific snapshots as part of your backup strategy, you would include them. If your goal is to back up the *current state* of /srv/btrfs/data, then excluding .snapshot` might be a good idea to avoid backing up redundant data, as snapshots are essentially deltas or full copies of data at a specific point.** This depends on the backup tool's capabilities. For many general-purpose backup tools, excluding snapshots is often recommended to avoid backing up metadata or potentially large, historical data blocks that are already accounted for in your live data backup.
**/srv/btrfs/backup**: **This is your *target* directory for storing backups. You absolutely *must* exclude this from the source path being backed up. If your script's source is /srv/btrfsand its destination is/srv/btrfs/data/backup, then /srv/btrfs/backup` needs to be in your exclusion list.**

So, to directly answer your question: Do not add /srv/* to your exclusion list if your data resides under /srv/btrfs. Instead, focus on excluding the specific backup destination directory, which appears to be /srv/btrfs/data/backup.

The `-t` Parameter: What Does It Do?

Now, about the -t parameter. Typically, -t in backup scripts stands for "test" or "dry run." This is an invaluable feature! When you run a backup script with the -t or --test parameter, it will go through all the motions of creating a backup – it will scan your source files, determine what needs to be backed up, and identify any exclusions – but it will not actually copy any data or create the backup files. It's like a dress rehearsal for your backup.

Using the -t parameter is highly recommended, especially when you're configuring exclusions or making significant changes to your backup job. It allows you to verify that your exclusions are working correctly and that the script is targeting the right files without the risk of corrupting data or wasting time and disk space on an incorrect backup. After running the script with -t, you should carefully review the output to ensure that the files you want to back up are listed, and the files you want to exclude are indeed being skipped. Once you're confident that the dry run looks perfect, you can then run the script without the -t parameter to perform the actual backup.

Putting It All Together: Your Exclusion Strategy

Based on your description, here's a recommended strategy:

Identify Your Source and Destination:
- Source: Let's assume you want to back up everything under /srv/btrfs except your backup directory and possibly snapshots. So, your source might be /srv/btrfs.
- Destination: You want to store backups in /srv/btrfs/data/backup.
Configure exclusions.txt:
- Add the full path to your backup destination to prevent recursion. So, your exclusions.txt should contain at least:
```
/srv/btrfs/data/backup
```
- Consider excluding Btrfs snapshots if your backup tool doesn't handle them specially and you don't need them as part of this backup. If /srv/btrfs/.snapshot contains active snapshots you want to preserve, you might need to be more selective or use a tool that understands Btrfs. For most general backup scripts, excluding it is often the safest bet to avoid redundant data:
```
/srv/btrfs/.snapshot
```
- Important: Do NOT exclude /srv/btrfs/data unless it contains subdirectories that you specifically want to omit (like temporary files or cache folders within your data). You want to back up your actual data!
Perform a Dry Run (-t):
- Execute your backup script with the -t parameter, specifying your source and destination, and pointing to your exclusions.txt file. For example (this is a hypothetical command, adjust to your script's actual syntax):
```
your_backup_script.sh --source /srv/btrfs --destination /srv/btrfs/data/backup --exclude-file /path/to/your/exclusions.txt --test
```
- Carefully review the output. Does it show it's backing up your data from /srv/btrfs/data? Does it explicitly state that it's skipping /srv/btrfs/data/backup and /srv/btrfs/.snapshot?
Run the Actual Backup:
- Once you are 100% satisfied with the dry run results, remove the -t parameter and run the script again to perform the live backup.

In summary: You should exclude your backup destination directory (/srv/btrfs/data/backup) to avoid recursive backups. You might also consider excluding Btrfs snapshots (/srv/btrfs/.snapshot). Do not exclude the entire /srv/* path, as this will likely prevent your data from being backed up. Always use the -t (test/dry run) parameter first to verify your configuration before committing to a full backup.

Happy backing up!

For more detailed information on Btrfs filesystem features and best practices, you can check out the official Btrfs wiki on Kernel.org. Additionally, for general NAS and data management advice, NASCompares offers a wealth of resources and reviews.