Backup and Restore of LINUX System Disk using "dd" command:

Backup and Restore of LINUX System Disk using "dd" command:

creating disk1:

# dd if=/dev/zero of=disk1 bs=1024000 count=2048

# mkdir d1

# mkfs.ext3 disk1

# mount disk1 d1 // It will end with error, so try,

# mount -o loop disk1 d1

creating disk2:

# dd if=/dev/zero of=disk2 bs=1024000 count=2048

#mkfs.ext3 disk2

# mkdir d2

# mount -o loop disk2 d2

# df -h -----  result will be,

We can also use conv=notrunc,noerror options with "dd" command ,

- The notrunc conversion option means do not truncate the output file — that is, if the output file already exists, just replace the specified bytes and leave the rest of the output file alone.

- Noerror means to keep going if there is an error. Dd normally terminates on any I/O error.

to confirm this,

# losetup -a
/dev/loop0: [fd00]:142387 (/root/disk1)
/dev/loop1: [fd00]:142390 (/root/disk2)

copy some file into d1 for example:

# wget http://ipv4.download.thinkbroadband.com/512MB.zip

shows like:

# ll /root/d1
total 541048
-rw-r--r--   1 root root  16589672 Dec 23 22:14 1GB.zip
-rw-r--r--   1 root root 536870912 May 30  2008 512MB.zip
drwxr-xr-x. 69 root root      4096 Dec 23 22:06 etc
drwx------   2 root root     16384 Dec 23 21:58 lost+found

Making image for /root/disk1:

Now it creates the image of /root/disk1.

[root@ranjith ~]# dd if=/root/disk1 of=~/d1backup.img
dd: writing to `/root/d1backup.img': No space left on device
3562841+0 records in
3562840+0 records out
1824174080 bytes (1.8 GB) copied, 47.1943 s, 38.7 MB/s

# pwd
/root/d2
# ls
lost+found

Restore the image on another partition:

# dd if=d1backup.img of=/root/disk2
3562840+0 records in
3562840+0 records out
1824174080 bytes (1.8 GB) copied, 46.6134 s, 39.1 MB/s

The above command will restore the image (d1backup.img) of /root/disk1 to /root/disk2.

# ll /root/d2
total 541048
-rw-r--r--   1 root root  16589672 Dec 23 22:14 1GB.zip
-rw-r--r--   1 root root 536870912 May 30  2008 512MB.zip
drwxr-xr-x. 69 root root      4096 Dec 23 22:06 etc
drwx------   2 root root     16384 Dec 23 22:05 lost+found

Comments

Post a Comment

Popular posts from this blog

Resolved: DOCKER: Error response from daemon: Could not attach to network / rpc error: code = 7 desc = network not manually attachable.

Image
I got this error: 'docker: Error response from daemon: Could not attach to network <nw-name>: rpc error: code = 7 desc = network <nw-name> not manually attachable.' when i try to create the container on the overlay network on swarm mode enabled, In docker 1.12 with swarm mode enabled, "Swarm" scoped networks (see the "SCOPE" column) cannot be used for docker run, only for services and now it has been rectified. I'm using updated version of docker, but still why i'm experiencing the error ? because the network just created but not manually attachable. To fix the issue we gonna use --attachable flag while creating network. [ --attachable             Enable manual container attachment ] (Need to create service on the overlay network, so that the overlay network will available / list on the worker node) docker inspect attnw (attnw is our test network)should show your own c
Read more

yum failed 6 times. Cannot continue!

Error while cPanel installation: (ERROR): - ssystem [EXIT_CODE] '/usr/bin/yum' exited with 1 (ignored) (DEBUG): - ssystem [END] (FATAL): yum failed 6 times. Cannot continue! fix: It looks like you have some name resolution issues on the server. Just run the following commands on your server and it will resolve the name resolution issues. #echo "nameserver 8.8.8.8" >> /etc/resolv.conf #echo "nameserver 8.8.4.4" >> /etc/resolv.conf if it is not working properly still facing same error, then here we go, # rpm -e --nodeps bind-chroot # rpm -e --nodeps bind # yum install bind
Read more

unexpectedly shrunk window (repaired) in dmesg log - TCP Peer

Don't Panic, This normally occurs when a client decides to reduce its TCP window size, without the server expecting it. This can be the case when fragmentation is an issue, or when the client is using an embedded device with very little NIC buffer memory. This is a completely normal behaviour, and you’re likely to see quite a few such packets in your log. The messages are informational only, and are used to debug networking issues. I’d be worried if you saw hundreds of thousands of these packets, since there are attacks that involve packet fragmentation and small window sizes, but otherwise it’s just the normal sort of noise you should expect to see on any internet-facing network. In fact, the “repaired” part of your message is showing that your network driver fixed the issue, which is usually done by concatenating the payloads of two fragmented packets together. Shouldn’t be an issue at all. … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … 
Read more