Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
May I point out that all a RAID1 does is sync the blocks between two drives. It won't protect against writing something dumb that would mess up the filesystem, it will just dutifully sync it.
You should be able to back up ext data from a filesystem on a RAID array, unless I'm confused about what e2image actually does. Are you trying to use it on the underlying drive devices by any chance? You have to point it at the RAID device on top of them, something like /dev/md1 rather than /dev/sda1.
This sounds like a good extra backup to have but don't let it lull you into a false sense of security. It may help recover from a very specific kind of mistake but the recovery may be very specific as well. It's not file backup.
Oh you're right it does work... well fuck knows what I was doing wrong before.
Yeah this is a backup in case I like, mv file to /dev/sda1 or something.
Not a backup of the files, but a backup of the structure.
The script takes the drives as arguments:
$ pwd
/usr/lib/systemd/system
$ cat drive_backup.service
[Unit]
Description=backup fdisk + e2image
Wants=drive_backup.timer
[Service]
Type=oneshot
ExecStart=/usr/bin/backup_meta_data.sh /dev/sdc1 /dev/sdb1
[Install]
WantedBy=multi-user.target
Set to run at 3:40am every day, but probably could be once weekly really.
$ cat drive_backup.timer
[Unit]
Description=timer to run drive backup
Requires=drive_backup.service
[Timer]
Unit=drive_backup.service
OnCalendar=*-*-* 03:40:00
[Install]
WantedBy=timers.target
Should be fairly self-explanatory.
$ cat /usr/bin/backup_meta_data.sh
#!/bin/bash
working_dir=/home/st/drive_recovery/working
backup_dir=/home/st/drive_recovery
backup_date=$(date +%Y%m%d-%H%M)
mkdir -p $working_dir
sudo fdisk -x > $working_dir/$backup_date.fdisk
for var in "$@"
do
clean=$(echo $var | sed 's;/;-;g')
sudo e2image $var $working_dir/$backup_date.$clean
done
sudo 7z a $backup_dir/$backup_date.archive $working_dir/"$backup_date"*
sudo rm $working_dir/"$backup_date"*
I'm really curious as to why go to all this trouble instead of using a proper file level backup and restore solution.
For fun and learning. It's just another tool to go with file level backup.
And the backup for this is 40mb and really fast, but backing up files even when compressed would be hundreds of GB, maybe terabytes, and then you're paying for that amount of storage online somewhere, uploading for hours..
Picture this: you open and edit one of your documents and save it.
The filesystem promptly allocates some blocks and updates the inodes. Maybe the inode table changed, maybe not. Repeat for some other files. Now your "inode backup" has a completely different picture of what is going on on your disk. If you try to recover the disk using it, all you will achieve is further corruption of the filesystem.