Skip to main content

Posts

Showing posts from January, 2019

Backup Your Entire Linux System Using Rsync

First, insert your backup medium (USB thumb drive or External hard disk). Then find the drive letter using ‘fdisk -l’ command. In my case, my Pen drive id is /dev/sdb1 . Mount your drive to any location of your choice. I am going to mount it under /mnt . $ sudo mount /dev/sdb1 /mnt To backup the entire system, all you have to do is open your Terminal and run the following command as root user: $ sudo rsync -aAXv / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt This command will backup the entire root ( / ) directory, excluding /dev, /proc, /sys, /tmp, /run, /mnt, /media, /lost+found directories, and save the data in /mnt folder. Let us break down the above command and see what each argument does. rsync – A fast, versatile, local and remote file-copying utility -aAXv – The files are transferred in “archive” mode, which ensures that symbo...

How to backup Linux OS using “dd” Command

“dd” command can be really handy when it comes to taking an Operating System backup to clone the disk the OS is installed on. Here are few examples of using dd command for taking OS backup. NOTE : The target drive must be either of identical size to the drive being cloned or larger. The dd command will copy both used and unused space from the target. 1. Backup Entire Hard disk To another DISK 1. In Below example we want to clone disk “sda” and have an identical disk on the server as “sdb”. # fdisk -l Disk /dev/sda: 12.9 GB, 12884901888 bytes 255 heads, 63 sectors/track, 1566 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00010897 Device Boot Start End Blocks Id System /dev/sda1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 64 1567 12069888 8e Linux LVM Disk /dev/sdb: 12.9 GB, 12884901888 bytes Units = cyl...

IX Tips AIX LVM Cheat Sheet

A This is a quick and dirty cheat sheet on LVM using AIX, I have highlighted many of the common attributes for each command however this is not an extensive list, make sure you look up the command. First a quick review on some of the terminology that AIX LVM uses Examples What it means PHYSICAL VOLUME (PV) Represents a hard disk (hdisk0). PHYSICAL PARTITION (PP) The smallest allocation unit in the LVM. All PPs within a VG are the same size, usually 4 or 8 MB. VOLUME GROUP (VG) A set of one or more PVs which form a single storage pool. You can define multiple VGs on each AIX system. LOGICAL VOLUME (LV) One or more PPs. A file system resides on top of an LV. Only one LV is mapped to a file system. A LV can't span across a VG. Up to 255 LVs in a VG LOGICAL PARITITION (LP) One or more PPs. LP represents a mirrored copy of a PP. Up to two copies of a PP can be mirrored resulting in a LP count of three (2 mirrors plus original). Volume Group Descriptor Area(VGDA) Information abo...

Plumbing

In Rewriting History , I talked about the internal representation of a Git repository. I may have mislead you a bit. While the reflog, interactive rebasing, and resetting may be more complex features of Git, they are still considered part of the porcelain , as is every other command we’ve covered. In this module, we’ll take a look at Git’s plumbing —the low-level commands that give us access to Git’s true internal representation of a project. Unless you start hacking on Git’s source code, you’ll probably never need to use the plumbing commands presented below. But, manually manipulating a repository will fill in the conceptual details of how Git actually stores your data, and you should walk away with a much better understanding of the techniques that we’ve been using throughout this tutorial. In turn, this knowledge will make the familiar porcelain commands even more powerful. We’ll start by inspecting Git’s object database, then we’ll manually create and commit a snapshot using ...

Tips & Tricks

This module presents a broad survey of useful Git utilities. We’ll take a step back from the theoretical aspects of Git and focus on common tasks like preparing a project for release and backing up a repository. While working through this module, your goal shouldn’t be to master all of these miscellaneous tools, but rather to understand why they were created and when they might come in handy. Download the repositories for this module If you’ve been following along from the previous module, you already have everything you need. Otherwise, download the zipped Git repositories from the above link, uncompress them, and you’re good to go. Archive The Repository First, let’s export our repository into a ZIP archive. Run the following command in your local copy of my-git-repo . git archive master --format =zip --output =../website-12-10-2012.zip Or, for Unix users that would prefer a tarball: git archive master --format =tar --output =../website-12-10-2012.tar Thi...

Patch Workflows

Thus far, all of the collaboration workflows we’ve seen rely heavily on branches. For example, in the last module, a contributor had to publish an entire branch for us to merge into our project. However, it’s also possible to communicate directly on the commit level using a patch . A patch file represents a single set of changes (i.e., a commit) that can be applied to any branch, in any order. In this sense, the patch workflow is akin to interactive rebasing, except you can easily share patches with other developers. This kind of communication lessens the importance of a project’s branch structure and gives complete control to the project maintainer (at least with regards to incorporating contributions). Integrating on the commit level will also give us a deeper understanding of how a Git repository records project history. Download the repositories for this module If you’ve been following along from the previous module, you already have everything you need. Otherwise, d...

Distributed Workflows

Now that we know how to share information via a centralized workflow, we can appreciate some of the drawbacks of this collaboration model. While it may be convenient, allowing everyone to push to an “official” repository raises some legitimate security concerns. It means that for anyone to contribute content, they need access to the entire project. This is fine if you’re only interacting with a small team, but imagine a scenario where you’re working on an open-source software project and a stranger found a bug, fixed it, and wants to incorporate the update into the main project. You probably don’t want to give them push-access to your central repository, since they could start pushing all sorts of random snapshots, and you would effectively lose control of the project. But, what you can do is tell the contributor to push the changes to their own public repository. Then, you can pull their bug fix into your private repository to ensure it doesn’t contain any undeclared code. If y...