From: Cees de G. <cg...@tr...> - 2004-01-04 10:40:12
|
So far I've used UML with NFS roots, which works dandy on our webhosting environment (fast connections, fast separate boxes, etcetera); as this turned out to be a very good idea on my home environment I reworked my config scripts to use UBD devices. I am fond of using rdiff-backup to do disk-disk backups - you always have the most recent version available in plain files of a disk set, so in case of trouble you can fail over relatively painless and very fast. However, rdiff-backup doesn't know about sparse files and doesn't really like to make incremental backups of 1G UBD images - it has been running all night now, and it only backed up 3 out of 6 ubd files... Is there something somewhere that'll give me the same ease of use as rdiff-backup (including keeping incremental older versions - that's the whole idea of a backup, after all) but will work with acceptable performance on ubd files? -- Cees de Groot http://www.tric.nl <cg...@tr...> tric, the new way helpdesk/ticketing software, VoIP/CTI, web applications, custom development |
From: BlaisorBlade <bla...@ya...> - 2004-01-04 11:02:52
|
Alle 10:40, domenica 4 gennaio 2004, Cees de Groot ha scritto: > I am fond of using rdiff-backup to do disk-disk backups - you always > have the most recent version available in plain files of a disk set, so > in case of trouble you can fail over relatively painless and very fast. > However, rdiff-backup doesn't know about sparse files and doesn't really > like to make incremental backups of 1G UBD images - it has been running > all night now, and it only backed up 3 out of 6 ubd files... > Is there something somewhere that'll give me the same ease of use as > rdiff-backup (including keeping incremental older versions - that's the > whole idea of a backup, after all) but will work with acceptable > performance on ubd files? If rdiff hasn't got an option for sparse files (I don't know this program) and the author doesn't implement it at your request, you can always tar the file with --sparse (you should get a file big only as the *real* size of the file, not the nominal one; if you use 300 Mega of your UBD, you should get a 300 mega file, even if the UBD is 2Giga wide) and then rdiff the resulting file. I don't know if the performance are good enough... just try and tell us back, even on success (so the next with this need will have a tested solution). Bye -- cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729 EOSIGN |
From: Chris W. <cn...@hf...> - 2004-01-04 12:27:39
|
At 10:40 AM 04/01/2004 +0100, you wrote: >Is there something somewhere that'll give me the same ease of use as >rdiff-backup (including keeping incremental older versions - that's the >whole idea of a backup, after all) but will work with acceptable >performance on ubd files? I've had more-or-less flawless results with rsync. It handles sparse files, hard links and other odd things quite well and can perform incremental changes on files (copying only modified parts, this tends to work quite well for large filesystem images). AFAIR rsync tends to be unhappy if a file changes while it's being read. I typically use rsync to perform a backup from an inactive filesystem or an LVM snapshot rather than the real live filesystem. |
From: Cees de G. <cg...@tr...> - 2004-01-05 08:49:06
|
Chris Watt <cn...@hf...> said: >AFAIR rsync tends to be unhappy if a file changes while it's being read. > As I don't have these files on an LVM setup, I wonder how UML reacts to a STOP signal while doing the backup... -- Cees de Groot http://www.tric.nl <cg...@tr...> tric, the new way helpdesk/ticketing software, VoIP/CTI, web applications, custom development |
From: BlaisorBlade <bla...@ya...> - 2004-01-05 19:27:21
|
Alle 09:23, luned=EC 5 gennaio 2004, Cees de Groot ha scritto: > Chris Watt <cn...@hf...> said: > >AFAIR rsync tends to be unhappy if a file changes while it's being read. > > As I don't have these files on an LVM setup, I wonder how UML reacts to > a STOP signal while doing the backup... Think about a STOP signal *before* the backup. Normally, when I start UML f= rom=20 a shell, Ctrl-Z (i.e. a SIGTSTP) and fg just work. Try it with another UML= =20 first, but since UML is interrupted a lot of times by the scheduler (as any= =20 process), SIGSTOP should really work. Obviously you can't change the file=20 (but a backup will not). However, if you want to try LVM, that can solve even the "hacker or anythin= g=20 such" problem: just use snapshots. I.e. you make a snapshot of the disk, an= d=20 then you can always revert there(don't ask me for more info as I don't use= =20 LVM). Maybe you could also like EVMS (from IBM). Bye =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729 EOSIGN |
From: <s-...@rh...> - 2004-01-04 23:09:32
|
> I am fond of using rdiff-backup to do disk-disk backups - you always > have the most recent version available in plain files of a disk set, so > in case of trouble you can fail over relatively painless and very fast. > However, rdiff-backup doesn't know about sparse files and doesn't really > like to make incremental backups of 1G UBD images - it has been running > all night now, and it only backed up 3 out of 6 ubd files... > > Is there something somewhere that'll give me the same ease of use as > rdiff-backup (including keeping incremental older versions - that's the > whole idea of a backup, after all) but will work with acceptable > performance on ubd files? Instead of using this rdiff-backup thing you could set up two block devices, one on each physical server (either with one ubd over nfs or a network block device), and then use raid (md) within the uml to mirror the two block devices. If one physical host fails, you can use the mirrored filesystem on the other host to start the uml right back up where it left off (as if it just went through a power failure). This will probably keep the devices more up to date than rsync-backup will. You could also intentionally shut down access to one of the block devices temporarily to take a backup of it and then enable it again and the raid should sync it back up. -Steve |
From: Cees de G. <cg...@tr...> - 2004-01-05 08:19:07
|
<s-...@rh...> said: >This will probably keep the devices more up to date than rsync-backup will. > I know, but the point of making backups is *not* to have the latest version available. It is to have a number of latest versions available, so that you can 'roll-back' in case someone messes up (a hacker, or yourself, or whatever). That's what I like about rdiff-backup (which is, apart from the failure to handle sparse files, an awesome backup tool). I'll try the tar thing. And rsync instead of rdiff-backup - I like rdiff-backup's incremental backup feature a whole lot better than rdiff-backup's, but sparse file handling is a must when backing up ubd's. Thanks for the suggestions (wasn't aware that rsync did handle sparse files). -- Cees de Groot http://www.tric.nl <cg...@tr...> tric, the new way helpdesk/ticketing software, VoIP/CTI, web applications, custom development |