Samba, backups i sistemes RAID

Samba Security Levels and Share Configuration

Understanding the SMB (Server Message Block) protocol is essential for anyone managing file sharing on Linux or Windows networks. Samba implements SMB, allowing Linux servers to act as file and print servers for Windows clients. This section explains the different security levels of SMB and the key Samba parameters that control access to shared resources.

SMB Security Levels

SMB defines four security levels that determine where a password is verified:

• Share‑level: The password is associated with each shared resource. This is the level that allows a distinct password for every share.
• User‑level
• Server‑level
• Domain‑level

In Samba, the share‑level security model is rarely used because it limits flexibility and auditability. However, it is the only level that lets you assign a password directly to a share, which is useful in very simple environments.

Key Samba Parameters for Access Control

Samba’s main configuration file, smb.conf, contains a series of directives that define who can access a share and how. The most common parameters are:

• valid users: Lists the users allowed to connect to the share. This parameter must be present when you use write list to grant write permissions.
• write list: Specifies which of the valid users may write to the share.
• browseable: Determines whether the share appears in the server’s list of available resources. Setting this to yes makes the share visible; no hides it.
• guest ok: Allows anonymous access without authentication.

When configuring a share, you typically combine valid users with write list to ensure that only authorized users can modify files, while others may have read‑only access.

Mapping Unauthenticated Users to Guest

The map to guest directive controls how Samba treats login attempts that fail authentication. The most useful option for mixed environments is Bad User. With map to guest = Bad User, Samba treats a login attempt with a non‑existent username as a guest connection, while still rejecting attempts with an existing username and a wrong password. This provides a graceful fallback for users who may mistype their username.

Backup Strategies: Incremental vs Differential

Data protection is a cornerstone of system administration. Two common backup methods—incremental and differential—are often confused. Understanding their differences helps you design efficient backup schedules that balance storage space and recovery speed.

Incremental Backup (Level 2)

An incremental backup records only the changes made since the last backup of any type. After a full (level 0) backup, each subsequent incremental backup contains only the files that have changed since the previous backup, regardless of whether that previous backup was full or incremental. This results in minimal storage consumption and faster backup windows, but restoration requires the full backup plus every incremental backup in sequence.

Differential Backup (Level 1)

A differential backup captures all changes made since the last full backup. Each differential backup therefore grows larger over time until the next full backup is taken. Restoration is quicker than with incremental backups because you only need the last full backup and the most recent differential backup.

Choosing the Right Strategy

Use incremental backups when you need to minimize storage usage and can tolerate longer restore times. Opt for differential backups when faster recovery is a priority and you have sufficient storage for the growing backup sets.

Rsync: Powerful File Synchronization

Rsync is the go‑to tool for synchronizing files and directories across systems. Its flexibility comes from a rich set of command‑line options that let you include or exclude files based on patterns, preserve permissions, and transfer only the differences.

Excluding Files by Extension

To skip files with a specific extension, use the --exclude flag followed by a quoted pattern. For example, to exclude all .txt files, the command looks like:

rsync -av --exclude '*.txt' /source/ /destination/

This pattern matches any file ending in .txt in any subdirectory, ensuring they are not transferred. You can combine multiple --exclude options or use an exclude file for complex rules.

RAID 5 Fundamentals

RAID (Redundant Array of Independent Disks) provides fault tolerance and performance improvements. RAID 5 is one of the most popular levels for small‑to‑medium enterprises because it offers a good balance between capacity, speed, and redundancy.

Minimum Disk Requirement

RAID 5 requires a minimum of three disks. The array distributes data and parity information across all disks, allowing the system to survive the failure of any single disk without data loss. Adding more disks increases both usable capacity and read performance, while write performance is slightly impacted by parity calculations.

Key Benefits and Considerations

• Fault tolerance: One disk can fail without compromising data integrity.
• Efficient storage: Only one disk’s worth of space is used for parity, regardless of the total number of disks.
• Performance: Read operations are fast because data can be read from multiple disks simultaneously.
• Write penalty: Each write requires updating parity, which can reduce write speed compared to RAID 0.

Putting It All Together: A Practical Samba & Backup Scenario

Imagine you are tasked with setting up a secure file share for a development team, while also ensuring that the data is regularly backed up using both incremental and differential strategies. Below is a step‑by‑step guide that integrates the concepts covered above.

1. Configure the Samba Share

In /etc/samba/smb.conf, add a share definition:

[dev_projects]
   path = /srv/samba/dev_projects
   browseable = yes
   read only = no
   valid users = alice bob carol
   write list = alice bob
   map to guest = Bad User
   guest ok = no

This configuration ensures:

• The share is visible (browseable = yes).
• Only alice, bob, and carol can connect (valid users).
• Only alice and bob have write permissions (write list).
• Incorrect usernames are treated as guests, preventing unnecessary authentication failures (map to guest = Bad User).

2. Secure the Share with Share‑Level Passwords (Optional)

If you need a separate password for the share, enable security = share in the global section. This forces clients to provide a password specific to the share, matching the share‑level security model.

3. Set Up the Backup Routine

Assume the server uses a RAID 5 array with three disks for redundancy. Create a backup script that runs nightly:

# Full backup (Sunday)
rsync -av --delete /srv/samba/dev_projects /backup/full/$(date +%F)

# Differential backup (Monday‑Wednesday)
rsync -av --compare-dest=/backup/full/$(date -d 'last sunday' +%F) \
       /srv/samba/dev_projects /backup/diff/$(date +%F)

# Incremental backup (Thursday‑Saturday)
rsync -av --link-dest=/backup/last/$(date -d 'yesterday' +%F) \
       /srv/samba/dev_projects /backup/incr/$(date +%F)

# Exclude temporary text files from all backups
rsync --exclude '*.txt' …

This script demonstrates:

• A weekly full backup that serves as the base for both differential and incremental sets.
• Differential backups that capture changes since the last full backup.
• Incremental backups that capture changes since the previous backup of any type.
• Excluding unnecessary .txt files to save space.

4. Verify and Monitor

After configuring Samba and the backup script, perform the following checks:

• Use smbclient -L localhost -U alice to list shares and confirm browseable works.
• Attempt a write operation as bob and as carol to verify the write list restriction.
• Run the backup script manually and inspect the resulting directories for completeness.
• Test recovery by restoring a file from the incremental set, then from the differential set, and finally from the full backup.

5. Maintain RAID Health

Regularly check the RAID status with mdadm --detail /dev/md0 (or the appropriate device). Replace any failed disk promptly to keep the RAID 5 array in a healthy state.

Key Takeaways

• Share‑level security allows a password per share, but user‑level security is generally preferred for auditability.
• valid users must accompany write list to grant write access.
• map to guest = Bad User gracefully handles unknown usernames.
• Incremental backups store changes since the last backup of any type, while differential backups store changes since the last full backup.
• Use --exclude '*.txt' with rsync to omit specific file types.
• RAID 5 needs at least three disks and provides single‑disk fault tolerance.
• browseable controls share visibility in the server’s resource list.

By mastering these concepts, you can build secure, reliable, and efficient file‑sharing environments that protect data through robust backup and redundancy strategies.