Re: [Discuss] full disk backups
On Mon, 26 Aug 2019 06:44:58 -0400 Kent Borg wrote: > I read about btrfs years ago and it sounded really cool, and really > scary. I figured I would play with it when it got stable, when there > was an fsck for it...but I haven't gotten around to it. I don't understand why anyone would want fsck for Btrfs or ZFS. The designs of the filesystems make traditional fsck unnecessary. I also don't see what's "scarey" about it. My experience is that Btrfs is stable for day to day use, and SuSE agree: it's their default filesystem for the OS volumes on SLES. Data volumes on SLES are XFS because random access databases don't work so good on COW storage. Regarding ZFS licensing: the only "problem" with distributing ZFS modules is a (probably well-meaning) misuse of the terms "derivative work" and "combine". ZFS clearly is not derivative of the Linux kernel and loading a kernel module does not in and of itself constitute "combining" software. -- Rich Pieri ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On 8/25/19 6:30 PM, Dan Ritter wrote: I used btrfs for two years and lost data twice... both times while doing a scrub operation on a RAID-1 mirror. I read about btrfs years ago and it sounded really cool, and really scary. I figured I would play with it when it got stable, when there was an fsck for it...but I haven't gotten around to it. -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
Ian Kelling wrote: > > Dan Ritter writes: > > > > 4. use ZFS > > pro: lightweight snapshots, zfssend/zfsrecv > > con: not simple to set up > > 4.5 use btrfs. I use btrbk for snapshots and send. I've been using it > for over 4 years now, recovered from several failed disks with raid 1, > works great for me. > > I don't know why people like zfs so much when it has a license > compatiblity problem so its not supported or reviewed by upstream linux, > and isn't used or supported by most major gnu/linux companies. Also > btrfs is simpler and more flexible from what I've read. I used btrfs for two years and lost data twice... both times while doing a scrub operation on a RAID-1 mirror. ZFS works. The ZFS on Linux project is now the official root of all the open ZFS versions, including those for FreeBSD and OpenSolaris's derivatives. Ubuntu ships it fully incorporated; their lawyers think this is acceptable. Debian ships it with the proviso that you have to run the compilation step (via DKMS) on your machine, which satisfies their interpretation of the license. I can't recommend btrfs to anyone in its current state, and I would recommend ZFS to people who are willing to read the fine documentation before poking at it. -dsr- ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On 8/21/19 4:57 PM, Bill Bogstad wrote: Another thought is that it might still be actively trying to remap bad blocks. That could take a while (multiple seconds?), Minutes. Like 10 or 15, I forget. if it is having to retry. It didn't feel like that. It had the random-access quality of real work. But it is umounted, so I don't think the OS was directing it. Maybe doing some checksum verifications? These drives are doing some crazy impressive densities these days. I don't know what preventative maintenance they might come up with. If you aren't already monitoring the drive for bad blocks (smartctl), you probably should. I think I carefully felt for the same activity on a completely different 4TB WD drive and noticed the same thing, but only three or four minutes worth. I ping-pong between several drives in different locations, doing backups, so if one died no big deal. I am going to let them quiet down in the future before unplugging, however. Thanks, -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On Wed, Aug 21, 2019 at 1:39 PM Kent Borg wrote: > > On 8/18/19 1:36 AM, Steve Litt wrote: > > When I reformat my thumb drives as EXT4 they're much more reliable. > > Something I've noticed recently: When my link-dest rsync encrypted back > up to a recent model USB-3 WD disk is done, unmounted, and ready to be > unplugged...I can still feel it vibrating and doing something. > > I've decided this must be some useful housekeeping, and have waited > until it quieted down. > > Anyone know what it is? Guessing... Can you tell if this is caused simply by the spindle rotating or are the heads actively seeking? If the drive has some kind of auto spindown after going unused for a while, then it is likely to rotate for quite a while after you unmount it. That may be what you are seeing. Unplugging it early shouldn't be a problem. If it is actively seeking, that seems a little strange. It is unlikely that the drives write cache can hold too much data. Still it is possible that if the final writes were not contiguous, it might take a little while (maybe a second or two?). Another thought is that it might still be actively trying to remap bad blocks. That could take a while (multiple seconds?), if it is having to retry. If you aren't already monitoring the drive for bad blocks (smartctl), you probably should. It is harder to do on a USB drive; but if you fiddle with the right options to the software, you can usually make it work. You really want to know if your backup drive is failing... Good Luck, Bill Bogstad ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
WRT: Restoring individual files. Rsync-based backups, such as rsnapshot and backintime tend to be pretty simple. For instance, rsnapshot uses an "hourly", "daily", "weekly", "monthly", and "yearly" snapshot. The way this works is: The "Hourly" is just when cron triggers it during the day. You can have any number of these. "Daily" is simply a rename operation. It renames the dailies to that daily_0 becomes daily_1 ... then renames the oldest hourly(as I remember) backup set to daily_0 Weekly, monthly and yearly do about the same. backintime does a similar thing except the backup sets use a date-based name Since each backup set is complete, you don't have to worry about incrementals. On Sat, Aug 17, 2019 at 2:03 PM Dan Ritter wrote: > Eric Chadbourne wrote: > > > > I've been using Kali Linux Light for my daily driver. Works great. > However I need to make full disk backups and be able to recover since this > is used for work. I'm always screwing with it and if it's broken I'm not > getting paid those hours. > > > > Any recommendations for something to use for a full disk backup and easy > recovery? My first thought was dd or rsync. However Clonezilla looks > pretty cool. I remember years back one of their devs being on the BLU > email list. > > > > Several options. > > 1. dd > pro: simple, guaranteed to copy all state > con: guaranteed to read and write all state > > 2. rsync > pro: reasonably simple, restartable, more efficient than dd > con: lots of small files make it slow > > 3. rsnapshot > pro: reasonably simple, enforces cron usage, built on rsync, > multiple snapshots possible > con: same as rsync, plus multiple snapshots can make things > messy > > 4. use ZFS > pro: lightweight snapshots, zfssend/zfsrecv > con: not simple to set up > > 5. buy another machine and stop futzing with your work machine > pro: work machine remains stable, damage from futzing > limited to other machine > con: potentially expensive > > I have used all of these techniques. > > -dsr- > ___ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > -- Jerry Feldman Treasurer, Boston Linux and Unix http://www.blu.org ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On 8/18/19 1:36 AM, Steve Litt wrote: When I reformat my thumb drives as EXT4 they're much more reliable. Something I've noticed recently: When my link-dest rsync encrypted back up to a recent model USB-3 WD disk is done, unmounted, and ready to be unplugged...I can still feel it vibrating and doing something. I've decided this must be some useful housekeeping, and have waited until it quieted down. Anyone know what it is? -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On Mon, 19 Aug 2019 20:17:48 + Timothy Lyons wrote: > Secure: Restic uses cryptography to guarantee confidentiality and > integrity of your data. The location where the backup data is stored > is assumed to be an untrusted environment (e.g. a shared space where > others like system administrators are able to access your backups). Read up on the Code Spaces breach because I'm not talking about encryption when I say "secure" and "cloud" don't go together. -- Rich Pieri ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
That looks like a nice simple solution. my concern would be with it's dependence on EncFs, which they admit may have significant flaws. "EncFS is probably safe as long as the adversary only gets one copy of the ciphertext and nothing more. EncFS is not safe if the adversary has the opportunity to see two or more snapshots of the ciphertext at different times. EncFS attempts to protect files from malicious modification, but there are serious problems with this feature." If your backups are local or to remote hardware you *fully* control, then it's probably sufficient. Thanks for the share - always good to know of alternatives! Kindest Regards, --Tim --- Timothy M. Lyons, CISSP ly...@geekcq.com +1-978-309-9595 This message contains confidential information and is intended only for the individual(s) named. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From: Discuss on behalf of Jerry Feldman Sent: Monday, August 19, 2019 11:19 Cc: Boston Linux and Unix Subject: Re: [Discuss] full disk backups I currently use Back In Time https://backintime.readthedocs.io/en/latest/ This is a snapshot like system with a GUI front end. I used to use rsnapshot. Both are based on rsync. The reason I switched was because Dick Miller swears by it and I wanted to try it. I actually preferred the rsnapshot format, but backintime essentially does the same thing. On Mon, Aug 19, 2019, 10:38 AM Rich Pieri wrote: > On Mon, 19 Aug 2019 14:00:52 + > Timothy Lyons wrote: > > > Sorry if I'm jumping into this late but I'd be remiss if I didn't > > throw restic into the mix. Simple, SECURE and flexible backups with > > multiple target options (local, cloud, etc). Fully configurable as > > Sorry... but... the terms "backup", "secure" and "cloud" do not belong > in the same sentence. If it's in a public cloud then it can be > compromised by a third party bad actor. Witness the Code Spaces breach. > Not saying you shouldn't use public cloud storage; saying you should be > cautious in your trust of it. > > On the subject of Clonezilla: it's not a backup tool. It's an imaging > tool. It can be used as part of a backup system: the physical volume > analogue to copying a virtual machine's vdisk files to other storage. > Using it this way is cumbersome on Linux systems where realistically > the only thing that needs a low-level copy is the boot block of the > boot device and that only once. It would be more useful on a dual-boot > Windows/Linux machine using Clonezilla command line to clone the > Windows system volumes. > > -- > Rich Pieri > ___ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
I assumed some level of competence in setting up storage (local or cloud) with at-rest encryption - while also encrypting the backup. Secure: Restic uses cryptography to guarantee confidentiality and integrity of your data. The location where the backup data is stored is assumed to be an untrusted environment (e.g. a shared space where others like system administrators are able to access your backups). Restic is built to secure your data<https://restic.readthedocs.io/en/latest/100_references.html#design> against such attackers, by encrypting it with AES-256 in counter mode and authenticating it using Poly1305-AES. My requirements dictated a mobility-enabled solution. Cloud fits that bill perfectly - for me. But, I've also spent the last 6-years securing large-scale enterprise-cloud in one form or another. It's all about what works for the user. Kindest Regards, --Tim --- Timothy M. Lyons, CISSP ly...@geekcq.com +1-978-309-9595 This message contains confidential information and is intended only for the individual(s) named. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From: Discuss on behalf of Rich Pieri Sent: Monday, August 19, 2019 10:37 To: discuss@blu.org Subject: Re: [Discuss] full disk backups On Mon, 19 Aug 2019 14:00:52 + Timothy Lyons wrote: > Sorry if I'm jumping into this late but I'd be remiss if I didn't > throw restic into the mix. Simple, SECURE and flexible backups with > multiple target options (local, cloud, etc). Fully configurable as Sorry... but... the terms "backup", "secure" and "cloud" do not belong in the same sentence. If it's in a public cloud then it can be compromised by a third party bad actor. Witness the Code Spaces breach. Not saying you shouldn't use public cloud storage; saying you should be cautious in your trust of it. On the subject of Clonezilla: it's not a backup tool. It's an imaging tool. It can be used as part of a backup system: the physical volume analogue to copying a virtual machine's vdisk files to other storage. Using it this way is cumbersome on Linux systems where realistically the only thing that needs a low-level copy is the boot block of the boot device and that only once. It would be more useful on a dual-boot Windows/Linux machine using Clonezilla command line to clone the Windows system volumes. -- Rich Pieri ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
I currently use Back In Time https://backintime.readthedocs.io/en/latest/ This is a snapshot like system with a GUI front end. I used to use rsnapshot. Both are based on rsync. The reason I switched was because Dick Miller swears by it and I wanted to try it. I actually preferred the rsnapshot format, but backintime essentially does the same thing. On Mon, Aug 19, 2019, 10:38 AM Rich Pieri wrote: > On Mon, 19 Aug 2019 14:00:52 + > Timothy Lyons wrote: > > > Sorry if I'm jumping into this late but I'd be remiss if I didn't > > throw restic into the mix. Simple, SECURE and flexible backups with > > multiple target options (local, cloud, etc). Fully configurable as > > Sorry... but... the terms "backup", "secure" and "cloud" do not belong > in the same sentence. If it's in a public cloud then it can be > compromised by a third party bad actor. Witness the Code Spaces breach. > Not saying you shouldn't use public cloud storage; saying you should be > cautious in your trust of it. > > On the subject of Clonezilla: it's not a backup tool. It's an imaging > tool. It can be used as part of a backup system: the physical volume > analogue to copying a virtual machine's vdisk files to other storage. > Using it this way is cumbersome on Linux systems where realistically > the only thing that needs a low-level copy is the boot block of the > boot device and that only once. It would be more useful on a dual-boot > Windows/Linux machine using Clonezilla command line to clone the > Windows system volumes. > > -- > Rich Pieri > ___ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On Mon, 19 Aug 2019 14:00:52 + Timothy Lyons wrote: > Sorry if I'm jumping into this late but I'd be remiss if I didn't > throw restic into the mix. Simple, SECURE and flexible backups with > multiple target options (local, cloud, etc). Fully configurable as Sorry... but... the terms "backup", "secure" and "cloud" do not belong in the same sentence. If it's in a public cloud then it can be compromised by a third party bad actor. Witness the Code Spaces breach. Not saying you shouldn't use public cloud storage; saying you should be cautious in your trust of it. On the subject of Clonezilla: it's not a backup tool. It's an imaging tool. It can be used as part of a backup system: the physical volume analogue to copying a virtual machine's vdisk files to other storage. Using it this way is cumbersome on Linux systems where realistically the only thing that needs a low-level copy is the boot block of the boot device and that only once. It would be more useful on a dual-boot Windows/Linux machine using Clonezilla command line to clone the Windows system volumes. -- Rich Pieri ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
Sorry if I'm jumping into this late but I'd be remiss if I didn't throw restic into the mix. Simple, SECURE and flexible backups with multiple target options (local, cloud, etc). Fully configurable as to retention. I run it as a userland systemd scheduled job on my systems, backing up locally and to the cloud with different retention policies for each repository. Great article I wish existed when I was hacking this together https://fedoramagazine.org/automate-backups-with-restic-and-systemd/ Project website:https://restic.net/ Design & Security information: https://restic.readthedocs.io/en/latest/100_references.html Kindest Regards, --Tim --- Timothy M. Lyons, CISSP ly...@geekcq.com +1-978-309-9595 This message contains confidential information and is intended only for the individual(s) named. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From: Discuss on behalf of Derek Atkins Sent: Monday, August 19, 2019 08:43 To: Eric Chadbourne Cc: BLU Subject: Re: [Discuss] full disk backups Eric Chadbourne writes: >> 2. rsync >>pro: reasonably simple, restartable, more efficient than dd >>con: lots of small files make it slow >> >> 3. rsnapshot >>pro: reasonably simple, enforces cron usage, built on rsync, >> multiple snapshots possible >>con: same as rsync, plus multiple snapshots can make things >> messy There is also a system called "rdiff-backup" which is sort of like rsnapshot but different. Let's you set up which directories or files get backed up. Always gives you a "current full image" with incrementals back as far as you want to go. FWIW, this is what I use to backup my servers. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com<http://www.ihtfp.com> Computer and Internet Security Consultant ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
Eric Chadbourne writes: >> 2. rsync >>pro: reasonably simple, restartable, more efficient than dd >>con: lots of small files make it slow >> >> 3. rsnapshot >>pro: reasonably simple, enforces cron usage, built on rsync, >> multiple snapshots possible >>con: same as rsync, plus multiple snapshots can make things >> messy There is also a system called "rdiff-backup" which is sort of like rsnapshot but different. Let's you set up which directories or files get backed up. Always gives you a "current full image" with incrementals back as far as you want to go. FWIW, this is what I use to backup my servers. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
sudo rsync -avxHPS / /media/eric/USB1TB/ That was the magic. I misunderstood -a. Thanks Rich and all for your help! - Eric ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On Sat, 17 Aug 2019 14:02:36 -0400 Dan Ritter wrote: > Eric Chadbourne wrote: > > > > I've been using Kali Linux Light for my daily driver. Works great. > > However I need to make full disk backups and be able to recover > > since this is used for work. I'm always screwing with it and if > > it's broken I'm not getting paid those hours. > > > > Any recommendations for something to use for a full disk backup and > > easy recovery? My first thought was dd or rsync. However > > Clonezilla looks pretty cool. I remember years back one of their > > devs being on the BLU email list. > > Several options. > > 1. dd > pro: simple, guaranteed to copy all state > con: guaranteed to read and write all state Another con: copies everything, even empty space. Needs an even bigger disk to copy to. Also, not built to handle a disk with bad spots. ddrescue can do that. > > 2. rsync > pro: reasonably simple, restartable, more efficient than dd > con: lots of small files make it slow I use rsync for backup. I back up to a backup server and run the program on that backup server, so fast or slow doesn't matter that much. Rsync con: Backs up files, not sectors, so you need more for bootability on restore. > 5. buy another machine and stop futzing with your work machine > pro: work machine remains stable, damage from futzing > limited to other machine > con: potentially expensive Sounds like an excellent idea to me, if you have the space to accommodate a second computer and monitor. Or put them on KVM switches. Why hurt your work with experimentation gone wrong. Of course, on the other hand, I do a lot of experiments on my Daily Driver Desktop, which handles all my Troubleshooters.Com work. Do as I say, not as I do. :-) By the way, the following describes my backup system: http://troubleshooters.com/lpm/200609/200609.htm Yeah, I've been using it 13 years now. So far so good. SteveT Steve Litt August 2019 featured book: Twenty Eight Tales of Troubleshooting http://www.troubleshooters.com/28 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On 8/17/19 6:17 PM, Rich Pieri wrote: So... most of that exclude bit can be subsumed by "-x" (don't cross filesystem boundaries) Very useful option! -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On Sat, 17 Aug 2019 21:59:43 GMT
Eric Chadbourne wrote:
> This is the command I ended up running:
>
> sudo rsync -a --delete -exclude=
> {"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost
> +found"} / /media/eric/USB1TB/
So... most of that exclude bit can be subsumed by "-x" (don't cross
filesystem boundaries).
You need to replicate hard links correctly: -H
Depending on your data you may also need to treat sparse files
efficiently: -S
Feedback is good so you can see what is going on.
Be verbose: -v
Show progress: -P
sudo rsync -avxHPS / /media/eric/USB1TB/
--
Rich Pieri
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
What happens if you use the following options?
--no-specials --no-devices
On 8/17/19 5:59 PM, Eric Chadbourne wrote:
This is the command I ended up running:
sudo rsync -a --delete
-exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"}
/ /media/eric/USB1TB/
After letting it run for an hour and a half I killed it. My laptop is
pretty fast and there were a lot of errors. Such as "rsync: mkstemp"
and "rsync: symlink" with invalid argument.
Did I accidentally make a loop of some type? Fiddling with it now.
Suggestions welcome!
Thanks,
Eric
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
This is the command I ended up running:
sudo rsync -a --delete
-exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"}
/ /media/eric/USB1TB/
After letting it run for an hour and a half I killed it. My laptop is pretty fast and there were a
lot of errors. Such as "rsync: mkstemp" and "rsync: symlink" with invalid
argument.
Did I accidentally make a loop of some type? Fiddling with it now.
Suggestions welcome!
Thanks,
Eric
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
> On Aug 17, 2019, at 2:02 PM, Dan Ritter wrote: > > Eric Chadbourne wrote: >> >> I've been using Kali Linux Light for my daily driver. Works great. However >> I need to make full disk backups and be able to recover since this is used >> for work. I'm always screwing with it and if it's broken I'm not getting >> paid those hours. >> >> Any recommendations for something to use for a full disk backup and easy >> recovery? My first thought was dd or rsync. However Clonezilla looks >> pretty cool. I remember years back one of their devs being on the BLU email >> list. >> > > Several options. > > 1. dd >pro: simple, guaranteed to copy all state >con: guaranteed to read and write all state > > 2. rsync >pro: reasonably simple, restartable, more efficient than dd >con: lots of small files make it slow > > 3. rsnapshot >pro: reasonably simple, enforces cron usage, built on rsync, > multiple snapshots possible >con: same as rsync, plus multiple snapshots can make things > messy > > 4. use ZFS >pro: lightweight snapshots, zfssend/zfsrecv >con: not simple to set up > > 5. buy another machine and stop futzing with your work machine >pro: work machine remains stable, damage from futzing > limited to other machine >con: potentially expensive > > I have used all of these techniques. > > -dsr- Nice overview. Thanks DSR. I can't afford #5 right now. New apartment, bills, etc. Well after what you and Kent said I'm going to try rsync right now with USB 3 external drive. See how long it takes and if I can boot from it. Great suggestions! Eric Chadbourne https://never.blue/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
On 8/17/19 11:06 AM, Eric Chadbourne wrote: Any recommendations for something to use for a full disk backup and easy recovery? My first thought was dd or rsync. I suggest rsync to an external disk. The result is mountable and requires no special anything to use. For doing routine backups I use a homebrew script and rsync's link-dest feature: The result is a I get incremental backups, each is it's own directory, but common files are hard links to one copy of the file. I imagine having so many directory entries for relative few files might cause some resource problems with some file systems, but it seems to work with me. I ping-pong between different disks so I don't have all my data plugged together at once. The result is pretty cool...yet it still doesn't require anything special to use. Oh, and I do a fully encrypted file system, so it does require the passphrase to use. -kb ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] full disk backups
Eric Chadbourne wrote: > > I've been using Kali Linux Light for my daily driver. Works great. However > I need to make full disk backups and be able to recover since this is used > for work. I'm always screwing with it and if it's broken I'm not getting > paid those hours. > > Any recommendations for something to use for a full disk backup and easy > recovery? My first thought was dd or rsync. However Clonezilla looks pretty > cool. I remember years back one of their devs being on the BLU email list. > Several options. 1. dd pro: simple, guaranteed to copy all state con: guaranteed to read and write all state 2. rsync pro: reasonably simple, restartable, more efficient than dd con: lots of small files make it slow 3. rsnapshot pro: reasonably simple, enforces cron usage, built on rsync, multiple snapshots possible con: same as rsync, plus multiple snapshots can make things messy 4. use ZFS pro: lightweight snapshots, zfssend/zfsrecv con: not simple to set up 5. buy another machine and stop futzing with your work machine pro: work machine remains stable, damage from futzing limited to other machine con: potentially expensive I have used all of these techniques. -dsr- ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
