LEARN. PRACTICE. GROW.Concept and mechanism
An application may resolve names through system-configured sources, including local files and DNS. dig queries DNS; getent observes databases according to NSS configuration. If results differ, compare hosts and the relevant nsswitch.conf order before changing zones. The hypothesis should match the path the application actually uses. A client with its own cache or embedded resolver may require additional observation; do not assume one command reproduces every application.
Guided application
For recovery, listing an archive with tar is not equivalent to restoring a service. Review members before extraction, use an isolated destination, and confirm contents, permissions, and dependencies. The aim is to demonstrate that the application can use the result. For incidents preceding reboot, select the correct boot and unit in the journal, provided records were retained. Retention should be defined before the incident. A date in a backup filename or a currently active process is insufficient evidence of recoverability.
tar -tf backup.tar lists members. A controlled restoration should then confirm service configuration; journalctl -b -1 helps inspect the previous boot when available.
Common pitfalls
Treating dig as equivalent to NSS; extracting without reviewing destination; declaring a backup valid from creation alone; losing logs on reboot.
Related topics: Services, users, and scheduling · Security applied to operations
Validate the consumer’s actual path and effective service recovery.
Reference: tar(1) · XK0-006 V8