The previous chapters covered tar and rsync — the tools that create backups. This chapter covers the step that matters most: restoring. A backup that has never been restored is not a backup. It is an unverified copy of data that may or may not be usable when you need it. The LFCA exam places…
The previous chapter covered tar — the archive tool that bundles files into a single stream. This chapter covers rsync — the synchronization tool that copies only what changed. They solve different problems. tar creates a portable archive that can be stored, moved, and restored as a single file. rsync keeps two directories in sync,…
The previous chapter covered the theory of full, differential, and incremental backups. This chapter puts that theory into practice with the tool that has been the standard for Linux backups since the 1970s: tar. Its name comes from “tape archive” — it was designed for writing backups to magnetic tape — but it is used…
A backup strategy is not a single tool or a single command. It is a plan that answers three questions: what to back up, how often, and how to restore it. The three fundamental backup types — full, incremental, and differential — are the building blocks of that plan. Each one trades storage space, backup…
The previous chapter covered CPU and memory monitoring — the resources that determine whether the system is under computational pressure. This chapter covers the other two pillars: disk and network. A system can have idle CPU and plenty of RAM and still be unusable because the disk is full or the network is saturated. These…
In the previous chapters, you learned the router’s event stream, the navigation lifecycle, and the guard types that gate navigation. This chapter puts those pieces together for the specific problem that almost every production application faces: authentication and authorization. How do you know who the user is, what they are allowed to see, and how…
The previous chapter covered the router’s event stream and the guards that gate navigation. Those are the mechanisms you use every day. But the Angular Router has a deeper set of features that solve specific, less common problems: standalone route components that lazy-load without loadChildren, route-level providers that scope services to a feature, component input…
The Angular Router is one of the framework’s most used features and one of its least understood. You configure routes, navigate with routerLink, and read parameters from ActivatedRoute. That is the API surface most developers interact with. But underneath, the router is a state machine that runs through a specific sequence of events for every…
In the previous chapters, you set up Angular Universal for server-side rendering and learned how hydration makes the server-rendered HTML interactive. But SSR is not the only way to deliver pre-rendered HTML. When your content is the same for every user — marketing pages, blog posts, documentation, product catalogs with stable data — rendering on…
In the previous chapter, you set up Angular Universal and sent your first server-rendered page to the browser. The server produced HTML, the browser painted it immediately, and the user saw content before the JavaScript bundle finished downloading. That is the promise of SSR. But there is a second act that determines whether the promise…