View previous topic :: View next topic |
Author |
Message |
yzg Guru
Joined: 18 Jun 2005 Posts: 493
|
Posted: Wed Dec 06, 2017 7:03 am Post subject: profile 17 backup |
|
|
What is the minimum backup required to reset the computer to its initial state before the profile 17 update if something goes wrong?
Full backup is out of questions because of the size and time.
Are the following directories enough to restore the computer to its initial state?
Quote: |
/boot
/etc
/var only cache, db, lib
/bin
/sbin
/lib32
/lib64
/usr/bin exclude src, portage
grub boot??
|
|
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9679 Location: almost Mile High in the USA
|
Posted: Wed Dec 06, 2017 7:59 am Post subject: |
|
|
If you also don't want to re-emerge anything, all of /usr/lib /usr/share needs to be backed up too; but I think the best is a full image backup... _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
Maxxx Guru
Joined: 12 Jan 2016 Posts: 595 Location: Italia
|
Posted: Wed Dec 06, 2017 8:01 am Post subject: |
|
|
I use ""dd" command for clone entire HD. |
|
Back to top |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Wed Dec 06, 2017 8:35 am Post subject: |
|
|
Well, you need your world file and our config files at minimum.
But this really isn't a make or break situation. Nothing is just going to stop working. Worst case is a few hours to sort out a couple of emerge failures. _________________ First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
Back to top |
|
|
Irre Guru
Joined: 09 Nov 2013 Posts: 434 Location: Stockholm
|
Posted: Wed Dec 06, 2017 9:44 am Post subject: |
|
|
I always take full image backups (from another system):
1) first fill free space in file system with zeroes: dd if=/dev/zero of=/zero; rm /zero
then:
2) dd if=/dev/sdaX | gzip>backupfile
to restore:
zcat backupfile | dd of=/dev/sdaX
backupfile are only between 1 .. 3 Gb for my systems. Userdata, distfiles, portage etc are somewhere else. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21635
|
Posted: Thu Dec 07, 2017 2:52 am Post subject: |
|
|
Irre: shouldn't you remount the filesystem read-only before step 2? Otherwise, the kernel might write to it partway through your copy. Generally, bit-perfect backups are a special-case that should be used only if you need a perfect reproduction of the data (e.g. for data forensics). In most cases, filesystem level backups are a better choice. |
|
Back to top |
|
|
Irre Guru
Joined: 09 Nov 2013 Posts: 434 Location: Stockholm
|
Posted: Thu Dec 07, 2017 7:27 pm Post subject: |
|
|
Hu wrote: | Irre: shouldn't you remount the filesystem read-only before step 2? Otherwise, the kernel might write to it partway through your copy. Generally, bit-perfect backups are a special-case that should be used only if you need a perfect reproduction of the data (e.g. for data forensics). In most cases, filesystem level backups are a better choice. |
Yes, I always run from another system. So it is not mounted. I also use to check "fsck /dev/sdaX" prior to "DD". |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Thu Dec 07, 2017 8:08 pm Post subject: |
|
|
Code: | dd if=/dev/sdaX | gzip>backupfile |
Try zstd instead of gzip. It's faster and gives you a smaller backupfile (better compression).
Quote: | zcat backupfile | dd of=/dev/sdaX |
Even if you created your backupfile with gzip, you can use zstd to decompress. It's much faster. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Thu Dec 07, 2017 9:22 pm Post subject: |
|
|
Bare minimum depends on your filesystem. If possible use a Btrfs/LVM snapshot, it's instant and you only pay for what you use. A tarball is the traditional way to make system backups and will work, but it's very hard to get right - you have to pay close attention to keep xattrs and permissions intact. Cloning the disk is easy but inefficient, and you explicitly said you don't have the space or time for that... |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21635
|
Posted: Fri Dec 08, 2017 1:31 am Post subject: |
|
|
Irre wrote: | Yes, I always run from another system. So it is not mounted. I also use to check "fsck /dev/sdaX" prior to "DD". | If it isn't mounted, how do you write the file that zero-fills all the data blocks in the filesystem? Your earlier post said "(from another system)", which avoids some of the difficulties with disk-level cloning (in particular, inability to remount read-only due to in-use writable files on a live filesystem), but you still need to mount the filesystem on some system to write the zero file. Your instructions don't mention remounting read-only / unmounting after that, but failing to do so can cause inconsistencies. Similarly, you should flush the zero file to disk before deleting it. In theory, a kernel with sufficient free RAM could defer writing some of (or all of with the right disk / memory ratio) the zero blocks long enough that the file is unlinked, at which point the kernel declares the file to be garbage and discards all pending writes to it. An explicit sync, or an implicit sync through a remount read-only, should force all such writes out, so that the disk is as zero-filled as you intend.
Of course, disk cloning is a usually a bad idea on systems with limited write cycles. It's acceptable but suboptimal on mechanical drives and probably most SSDs. |
|
Back to top |
|
|
|