Не зная, какво е targetcli, но ram дискът не може ли да се мапне или монтира към директория, която да се прочете?
Май Ремо нещо такова показва.
И аз се допитах до ИИ, за да схвана, за какво точно става дума.
Цитата е Markdown и може да се види във всеки viewer или редактор на документи.
### What the Guy is Talking About
This is a Bulgarian-language forum post (likely from a tech support or sysadmin community) where the user describes a storage setup using Linux (Debian 12) as an iSCSI target server, exporting virtual disk images to a Windows Server 2019 machine. The setup involves:
- **Hardware/Storage Foundation**: A RAID5 array managed by the built-in Dell PERC 7xx controller (a hardware RAID adapter common in servers).
- **Software**: `targetcli` (the command-line tool for configuring the Linux-IO or LIO kernel target subsystem) to create iSCSI targets.
- **Backstores**: Specifically, `fileio` backstores, which treat regular files (e.g., `.img` disk image files) on the local filesystem as block devices. These are essentially virtual disks backed by files on the RAID5 storage.
- **Export**: The 9 image files are exposed as Logical Unit Numbers (LUNs) via iSCSI, allowing the Windows Server 2019 to mount and use them as local disks over the network.
Everything worked fine initially: The Windows server could read/write to these virtual disks without issues. The user is using this for some form of data storage (possibly backups, VMs, or databases, given the 6-month data span).
### What's Exactly the Problem
The issue arose after a server reboot (restart of the Debian 12 machine):
- **Symptom**: Writes to the image files stopped working at some point **before** the reboot. Specifically, data from the last ~6 months is missing or wasn't persisted.
- **Observation**: Right before the reboot, the data *appeared* complete (e.g., via checks on the Windows side or file sizes), but post-reboot inspection revealed the gap. The iSCSI targets likely came back online, but the underlying image files on the Debian server don't reflect recent changes.
- **Root Cause (Likely)**: This is a classic caching/flushing problem with `fileio` backstores in targetcli/LIO. When creating a `fileio` backstore, you can configure it in **write-back** mode (default in many setups, which enables filesystem caching for better performance) or **write-thru** mode (forces immediate writes to disk, safer but slower).
- In **write-back** mode, writes from the Windows initiator go to the Linux kernel's page cache (RAM) first, then get flushed to the actual `.img` files on disk asynchronously. If the system crashes, runs low on memory, or encounters I/O errors (e.g., RAID issues), unflushed data is lost.
- Evidence from similar cases: Performance-oriented setups often default to write-back, but it risks data loss on unclean shutdowns or if the cache isn't synced. The "stopped writing" suggests the cache filled up or a kernel-level stall occurred, and the reboot discarded pending writes without a proper `sync`.
- Other potential contributors:
- **Configuration Persistence**: Targetcli configs are saved to `/etc/target/saveconfig.json`, but if the `target.service` wasn't enabled (`systemctl enable target`), the iSCSI setup might not reload fully post-reboot, leading to stale mounts.
- **RAID/PERC Interaction**: Hardware RAID can sometimes cause subtle I/O delays or errors if the array is under load, exacerbating caching issues.
- **No Explicit Sync**: No mention of running `sync` or tools like `targetctl restore` before reboot.
This isn't a full data corruption (the older data is intact), but a partial loss of recent writes—common in high-performance but risky setups.
### Can the Missing Information Be Recovered, and Where to Look?
**Short Answer**: Recovery is **unlikely** without backups, as the data was probably lost in RAM (unflushed cache) rather than persisted anywhere else. However, here's a step-by-step diagnostic and recovery checklist:
1. **Verify the Image Files on Debian**:
- SSH into the Debian server and locate the `.img` files (likely in a directory like `/var/lib/target/backstores/` or wherever you created them—check with `targetcli /backstores/fileio ls`).
- Check file sizes and timestamps: `ls -lh /path/to/*.img` and `stat /path/to/file.img`.
- Mount each image read-only to inspect contents (assuming they're formatted filesystems like NTFS for Windows compatibility):
```
sudo apt install ntfs-3g # If NTFS
sudo mkdir /mnt/check
sudo mount -o loop,ro /path/to/file.img /mnt/check
ls -la /mnt/check # Look for the 6-month-old data
sudo umount /mnt/check
```
- If the data isn't there, it's truly lost from the images.
2. **Check for Kernel Logs or Errors**:
- Review dmesg for I/O or targetcli errors around the time writes stopped: `dmesg | grep -i 'iscsi\|lio\|fileio\|error\|write'`.
- System logs: `journalctl -u target -xe` (for target service) or `grep -i 'target\|iscsi' /var/log/syslog`.
- Look for OOM (Out of Memory) kills or cache pressure that might have halted flushes.
3. **Windows-Side Checks**:
- On the Windows Server 2019: Use Disk Management or `diskpart` to rescan disks and check event logs (Event Viewer > Windows Logs > System) for iSCSI errors (e.g., write failures).
- If the disks are still mounted, run `chkdsk /f` on them to rule out filesystem inconsistencies (but unmount first if possible).
4. **Recovery Options (Slim Chances)**:
- **Backups**: If you have snapshots (e.g., via LVM on the RAID5, or filesystem-level like `rsync`/`borg`), restore from there. The RAID5 might have older parity data, but it's not granular.
- **Undelete Tools**: If the files were on an NTFS volume inside the images, boot Windows into recovery mode and use tools like TestDisk/PhotoRec or Recuva on the mounted images—but this only works for deleted (not overwritten) blocks.
- **Forensic Recovery**: Professional tools like `foremost` or `scalpel` on the raw `.img` files might carve out old data fragments, but success rate is low for 6 months' worth.
- **No Luck?**: The data is probably irrecoverable. Focus on prevention (see below).
### Prevention for the Future
- **Switch to Write-Thru**: Recreate backstores with `write_back=false` in targetcli:
```
sudo targetcli
/backstores/fileio> delete old_backstore_name # Backup first!
/backstores/fileio> create new_backstore /path/to/new.img 10G write_back=false
# Then re-add to LUNs and saveconfig
/> saveconfig
```
This ensures immediate disk writes (safer for production).
- **Enable Persistence**: Run `systemctl enable --now target` to auto-start iSCSI on boot.
- **Regular Syncs**: Add cron jobs: `echo 1 > /proc/sys/vm/drop_caches` or `sync` every hour.
- **Monitor**: Use tools like `iotop` or Prometheus to watch I/O; consider block backstores (direct to RAID volumes) over fileio for better reliability.
- **Test**: Simulate with `dd` writes and reboots to verify.
If you share more details (e.g., exact targetcli config from `saveconfig.json` or logs), I can refine this further. This setup is solid for dev/lab but needs hardening for prod to avoid cache pitfalls.
Автор
Тема: Проблем с targetcli (Прочетена 801 пъти)