eat, ride, sleep, repeat
Just to note keep the Cloned drive out of your system as far as booting goes they will be identical in every way. (Bit for Bit including uids) as this will cause problems when joined in booting.
This is after a successful clone. So to clarify Boot one or the other but not both together.
With realization of one's own potential and self-confidence in one's ability, one can build a better world.
Dalai Lama>>
Code Tags | System-info | Forum Guide lines | Arch Linux, Debian Unstable, FreeBSD
Just Give Me the Beans!
Good point...ThanksOriginally Posted by 1fallen
Just to note keep the Cloned drive out of your system as far as booting goes they will be identical in every way. (Bit for Bit including uids) as this will cause problems when joined in booting.
This is after a successful clone. So to clarify Boot one or the other but not both together.
make bzImage, not war
Howdy,
Ex-Windows users are always looking for a full backup program and it takes years for them to be convinced that it is generally a bad idea on Linux.
The point is that it is much easier and quicker to install a fresh copy of the latest version of Linux than to make and restore a tired old backup.
In general, it is better to only backup your data and when the time comes to recover a system, install a fresh copy of Linux and restore your data.
Just Give Me the Beans!
When you say "restore your data" does that include all 3rd party programs that are not part of the base Linux distribution ? Does that include all system settings that were tweaked over time ?
Quad Shot of Ubuntu
Not if you're somewhere with very poor internet connection, like I am a fair amount of the time and I many others live in.
make bzImage, not war
"When you say "restore your data" does that include all 3rd party programs that are not part of the base Linux distribution ? Does that include all system settings that were tweaked over time ?"
Consider that the Linux system keeps changing: Gnome 1, 2, 3 Unity, Gnome 3; X11, Wayland, Xorg; SysV Init, Upstart, Systemd and so on. The result is that your system settings and tweaks from an old version may not work on a new version.
If you always install special programs, make a little script for it, or use Preseed (or Kickstart) for a customized automatic install.
<--- Run xman to see that window.
LVM will let you create snapshots of active storage, which can be backed up by any other backup tool.
But LVM needs to be installed at install-time or prior to creating any file systems. The backup data needs to be completely quiesced to ensure against corrupt data being saved in the backup.
I doubt any other solution that doesn't perform 'snapshots' below the file system level will actually work, 100%.
Options to LVM are ZFS, and BTRFS, though I wouldn't trust my data to BTRFS, and I don't think ZFS can be booted, though for large data storage, ZFS is probably the best choice today.
I've used fsarchiver - it would work great with LVM snapshots. Outside of that, it needs to be booted from alternate boot media to ensure static data throughout a backup. The same applies to the other options provided above, IMHO. If you run any DBMS, you might or might not get lucky. There are non-snapshot methods, but those involve dump/restore of the DBMS data prior to the backups being taken.
Data integrity is important.
IMHO.
There are lots of long threads here about doing backups. I'm with Herman on not bothering to backup most of the OS. I backup system settings, system data, personal settings, personal data and a list of manually installed packages. Because installing a fresh OS is 15 minutes, storing all the programs isn't something I want. Putting the system and personally settings and data back take another 15 min. Installing the previously installed packages takes less than 15 minutes. Basically, I can a system back and working in 45 minutes. Only huge datasets which are stored outside those locations might take more time, but the core 100G will be back and available in 45min or less.
Most normal desktop users would be happy with the aptik solution. But it won't work for servers. Servers will require scripting. There isn't any point-n-click backup solution for many reasons. GUIs can't be automated. Servers don't have GUIs. GUIs are inefficient to manage from 500-24K miles away. Lots of other reasons. You'll need to build your own backup script or it will never be right. Just sayin'.
Using that method, reduces the needed backup storage hugely. Why backup the same 4-6GB on every system? With 10,20,30, or more systems, that is a huge waste. But if having a monkey perform the restore at 3am is the most important thing, then you'll need everything, taken from a snapshot-based backup.
As an example, I have an email gateway server that has 120 daily, versioned, backups. It doesn't hold any data and I don't backup any data on it. 120 days of versioned backups are less than 115MB ( I just checked).
That's a backup size report from the rdiff-backup summary. Having the OS included would have 4-6G, plus all the patched changes weekly.Code:$ more inc-sizes-spam2-2018-06-17 Time Size Cumulative size ----------------------------------------------------------------------------- Sun Jun 17 02:11:06 2018 114 MB 114 MB (current mirror) Sat Jun 16 02:11:07 2018 941 bytes 114 MB Fri Jun 15 02:11:07 2018 1.04 KB 114 MB ... Mon Feb 19 02:11:04 2018 1.10 KB 114 MB Sun Feb 18 02:11:06 2018 963 bytes 114 MB Sat Feb 17 02:11:06 2018 1.21 KB 114 MB
Anyways, that info is for your consideration.
Last edited by TheFu; June 24th, 2018 at 02:14 PM.
Just Give Me the Beans!
Since I have only a single Linux system that I need to back up, it does not seem like a huge waste to clone the 500GB system disk to an attached external disk, and then take periodic ZFS snapshots of the root file system.
I already take these snapshots every weekend and store a copy on a network share.
In case of system disk failure I can than boot from the clone and restore from the most recent snapshot. Would that be a practical plan ?
<--- Run xman to see that window.
Very practical, provided you've actually tested it and retain multiple snapshots on your backup disk. No backup solution is static. Things change and data gets corrupted. Bits rot from lack of use, I'm completely serious. After a yr to 5 yrs, bits start disappearing if they aren't accessed or refreshed. The access lets the HDD try to reread them and refresh them if necessary as they become weak.
Are you booting from ZFS? I didn't think that was possible on Ubuntu. So how are the boot area backups captured? Is ZFS just data or is it the OS and application code too? Data-only backups are fine, assuming you don't mind re-setting up the system from scratch. I always love getting the power management stuff perfect or the nginx config files just right with the SSL certs.
But the main issue is that we spend 20 hrs setting up a backup solution and 0 minutes testing the restore. Untested backups are just "hope". Hope is good, but it isn't the same as a plan that has been tested to work. What happens if the new HDD is 1% smaller than the original? Will the restore work? What happens if the source disk is 512b sectors and the target disk is 4kb sectors? Little things change.
Just Give Me the Beans!
In fact I agree that backup solutions need to be tested.
That is why I created a full disk image of the system disk using Clonezilla and I am trying to restore the image into a mirror disk attached to the system as another external HD.
However, seems Clonezilla does not handle well the Linux partitions that exist on the Ubuntu system disk.
I thought the disk to disk backup and restore should be a bit by bit cloning but at least with Clonezilla it does not work.
I need to look for another tool that can create a a viable clone disk of the system disk, one that I can hope to boot from in case of system disk failure
Adv Reply
Bookmarks