Re: continuous backup solution for freebsd?
On Mon, Oct 06, 2008 at 12:58:30PM +0300, Evren Yurtesen wrote: Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. R1soft says they need help to develop FreeBSD support in their product. Do you know anybody who can help r1soft on this issue? Please see: http://forum.r1soft.com/showpost.php?p=3414postcount=9 Would the GEOM gate class handle this? See ggatec(8) and ggated(8). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
continuous backup solution for freebsd?
Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. R1soft says they need help to develop FreeBSD support in their product. Do you know anybody who can help r1soft on this issue? Please see: http://forum.r1soft.com/showpost.php?p=3414postcount=9 Thanks, Evren ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
Bacula ? http://www.bacula.org I use it at work to backup linux and freebsd boxes and it works like a charm. On Mon, 2008-10-06 at 04:20 -0700, Jeremy Chadwick wrote: On Mon, Oct 06, 2008 at 12:58:30PM +0300, Evren Yurtesen wrote: Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. R1soft says they need help to develop FreeBSD support in their product. Do you know anybody who can help r1soft on this issue? Please see: http://forum.r1soft.com/showpost.php?p=3414postcount=9 Would the GEOM gate class handle this? See ggatec(8) and ggated(8). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
Jeremy Chadwick wrote: On Mon, Oct 06, 2008 at 12:58:30PM +0300, Evren Yurtesen wrote: Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. R1soft says they need help to develop FreeBSD support in their product. Do you know anybody who can help r1soft on this issue? Please see: http://forum.r1soft.com/showpost.php?p=3414postcount=9 Would the GEOM gate class handle this? See ggatec(8) and ggated(8). I am not saying it is impossible. They just need somebody to put them to right track I guess. I personally cant do that. It would be nice if somebody who has knowledge in this area contacts r1soft. At the very least r1soft seems to be willing to communicate on this issue. Continuous backups as well as bare-metal-restore seem to be a key feature for many hosters. FreeBSD is loosing users because of this issue. Thanks, Evren ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
Julien Cigar wrote: Bacula ? http://www.bacula.org I use it at work to backup linux and freebsd boxes and it works like a charm. On Mon, 2008-10-06 at 04:20 -0700, Jeremy Chadwick wrote: On Mon, Oct 06, 2008 at 12:58:30PM +0300, Evren Yurtesen wrote: Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. R1soft says they need help to develop FreeBSD support in their product. Do you know anybody who can help r1soft on this issue? Please see: http://forum.r1soft.com/showpost.php?p=3414postcount=9 Would the GEOM gate class handle this? See ggatec(8) and ggated(8). Bacula does not support continuous backups as far as I know. It has to scan all the files to find new/changed files to backup. The r1soft agent monitors file system writes and backs up changed parts immediately. This does allow r1soft backup to restore the system to its latest state (10-15minutes ago state, thus continuous backup is achieved) as it continually updates the backups. Also has much less stress on the systems where the writes are not so much since it doesnt have to check every file at each backup cycle. Also r1soft cdp has support for MySQL where you can easily restore mysql data in table level if required. It is as well supported by a wide variety of web hosting automation systems for example H-Sphere ( http://www.parallels.com/hsphere/ ) etc. through plugins. Please see the info about continuous data protection: http://en.wikipedia.org/wiki/Continuous_Data_Protection Otherwise I am currently using BackupPC (which is pretty good in my opinion and easier to use compared to Bacula) to take nightly backups of the servers. Thanks, Evren ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
On Mon, Oct 06, 2008 at 05:36:32PM +0300, Evren Yurtesen wrote: Jeremy Chadwick wrote: On Mon, Oct 06, 2008 at 12:58:30PM +0300, Evren Yurtesen wrote: Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. R1soft says they need help to develop FreeBSD support in their product. Do you know anybody who can help r1soft on this issue? Please see: http://forum.r1soft.com/showpost.php?p=3414postcount=9 Would the GEOM gate class handle this? See ggatec(8) and ggated(8). I am not saying it is impossible. They just need somebody to put them to right track I guess. I personally cant do that. It would be nice if somebody who has knowledge in this area contacts r1soft. At the very least r1soft seems to be willing to communicate on this issue. First and foremost, the URL you gave is terse and out of context. Let people read the entire thread: http://forum.r1soft.com/showthread.php?p=3414 So let me throw around some ideas. First and foremost, David appears to be saying We'll take FreeBSD seriously if we can get proper documentation, and it needs to be thorough, that explains how to interface with devices on a block level so we can perform block-level backups and write our software appropriately. AFAIK we don't have any documentation that outlines that in a clear, concise manner. With regards to providing protocol documentation and letting the open-source community write the software, R1Soft is generally right. Time and resources are the biggest problem with open-source; do not think for a moment that just because millions of users can look at source code means they understand it, or even know how to write it, or will even *want* to. The majority do/will not. That said, I'd like to know exactly how low-level R1Soft's software truly is. dump(8), AFAIK, is block-level -- and that's a userland program. Does R1Soft's software *truly* require kernel-land? I have more to say on that issue (not against R1Soft, but speaking with regards to the current state of FreeBSD's developer count) if it truly does. I'm somewhat surprised that their software focuses on Linux and Windows and not Solaris and Linux, especially given that they're interested in dedicated server markets. Solaris is always the first OS that comes to my mind when talking about hardcore server operating systems. Continuous backups as well as bare-metal-restore seem to be a key feature for many hosters. Regarding continuous backups: the GEOM gate class could be used for this. Meaning, I think it could be used as an alternate to R1Soft's software. Regarding bare-metal restoration I'm not aware of how to do that under FreeBSD, Linux, or even Solaris with ease. In most cases, companies develop their own PXE-booting environments which wipe the disks and reinstall + restore data as they see fit. There is no standard. FreeBSD is loosing users because of this issue. Why does the number of FreeBSD users matter? Quantity does not necessarily represent quality. I'm sorry for sounding anti-FreeBSD, but the reality is that people should use whatever solutions work best for them -- if that's using Windows, Solaris, or Linux, great! Remember that open-source is about choice: and choice means supporting the possibility that someone chooses something else. Blind one-sided advocacy is very damaging to the open-source model and concept. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
First of all, I am not an r1soft advocate, but they seem to be making a software which is popular and affordable and interested in giving FreeBSD support... r1soft is not the issue here, the problem is that there is no way to do near continuous backups on FreeBSD servers. Jeremy Chadwick wrote: That said, I'd like to know exactly how low-level R1Soft's software truly is. dump(8), AFAIK, is block-level -- and that's a userland program. Does R1Soft's software *truly* require kernel-land? I have more to say on that issue (not against R1Soft, but speaking with regards to the current state of FreeBSD's developer count) if it truly does. I think you might not have understood the concept of near continuous backups. The R1Soft backup monitors the filesystem operations and backs up written blocks. So it has to know what is written and when to be able to back it up. The dump command simply reads/writes the blocks. It cant only read changed blocks. It has to read the whole thing (inefficient). Continuous backups as well as bare-metal-restore seem to be a key feature for many hosters. Regarding continuous backups: the GEOM gate class could be used for this. Meaning, I think it could be used as an alternate to R1Soft's software. The GEOM gate allows mirroring to a remote machine, am I not right? That would be more or less same as same as using RAID. The continuous backup (or near continuous) means that you can restore the filesystem to a point like 15 minutes ago, or 1 hour ago. Besides, I hear geom might have network delay problems and it is much more complicated setup to build two machines in mirror configuration just for backup purposes as well as you cant restore to a point in the past. Regarding bare-metal restoration I'm not aware of how to do that under FreeBSD, Linux, or even Solaris with ease. In most cases, companies develop their own PXE-booting environments which wipe the disks and reinstall + restore data as they see fit. There is no standard. OK. Actually there is more than one solution which can do bare-metal-restores for FreeBSD also. However those solutions at best rely on nightly backups of the filesystems. With R1Soft, you can restore the system to only few minutes before the total meltdown. Unrelated to bare metal restore, with normal backups you are not taking backups of files which are created/deleted often. For example this can be customer mails or if a hacker hacks the box and removes his trails. Even sometimes customers upload some file and remove from their computer the same they and then accidentally remove from the server. With R1Soft backup the data would go into the backup server right away and you an restore every single file independent of when it was put or removed. FreeBSD is loosing users because of this issue. Why does the number of FreeBSD users matter? Quantity does not necessarily represent quality. Thats a perfectly fine statement. But a quality product would be nothing without users. As well as this problem effects the quality. Consider a system which has sensitive data which shouldnt get lost, with continuous data protecton you can restore such failed system to only few minutes before the failure point. Doing this is currently impossible with FreeBSD. Best we can do is to return to previous snapshot taken (which might be a day old). This is an important design criteria since restoring the lost data might be time consuming and expensive. Thge issue is not even r1soft, they are just the most popular company giving such solution, only if there was at least one backup solution which could provide near continuous data protection... In addition to this, near continuous backups create less load on boxes with a lot of reads but little writes. Standart backups have to scan all the files to detect which files were changed. I'm sorry for sounding anti-FreeBSD, but the reality is that people should use whatever solutions work best for them -- if that's using Windows, Solaris, or Linux, great! Remember that open-source is about choice: and choice means supporting the possibility that someone chooses something else. Blind one-sided advocacy is very damaging to the open-source model and concept. I agree, and please dont shoot the messenger :) I just have a bunch of customers who would use FreeBSD but not using only because of this problem. In addition to that I myself would like to use near continuous backups as well. I was just trying to inform the FreeBSD community here so if somebody can have some time to divert to giving the right advices to r1soft then we all could benefit from it. It doesnt even have to be free even, with a reasonable price they can probably hire somebody to work for building the basics of this feature. So the real question is, is there anybody who is willing and have the experience to help on this issue? Thanks, Evren ___
Re: continuous backup solution for freebsd?
On Mon, Oct 06, 2008 at 12:58:30PM +0300, Evren Yurtesen wrote: Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. I don't think so. The closest thing I know of is rsnapshot (http://www.rsnapshot.org/). My solution is to run rsync in a cron job. In my situation this takes about 5 minutes for approximately 100GB of data. The time it takes will obviously depend on the rate of change in the data. You could also use local snapshots with mksnap_ffs(8), to solve the oh shit I deleted my files situation. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpy2oCjkIRDg.pgp Description: PGP signature
Re: continuous backup solution for freebsd?
On Mon, Oct 06, 2008 at 08:07:30PM +0300, Evren Yurtesen wrote: First of all, I am not an r1soft advocate, but they seem to be making a software which is popular and affordable and interested in giving FreeBSD support... r1soft is not the issue here, the problem is that there is no way to do near continuous backups on FreeBSD servers. Jeremy Chadwick wrote: That said, I'd like to know exactly how low-level R1Soft's software truly is. dump(8), AFAIK, is block-level -- and that's a userland program. Does R1Soft's software *truly* require kernel-land? I have more to say on that issue (not against R1Soft, but speaking with regards to the current state of FreeBSD's developer count) if it truly does. I think you might not have understood the concept of near continuous backups. The R1Soft backup monitors the filesystem operations and backs up written blocks. So it has to know what is written and when to be able to back it up. The dump command simply reads/writes the blocks. It cant only read changed blocks. It has to read the whole thing (inefficient). It depends on how it's implemented, but in general, yes, I guess this would advocate reliance on GEOM, which would be kernel. The thing is, the GEOM gate class could be extended to handle this situation -- it's a class intended for filesystem replication in real-time, over a network. That said, I shall unleash with the comments I had originally planned on including, but removed them since I felt it might be too hasty of me. The sad reality with FreeBSD is that we do not have enough clueful folks who are familiar with the kernel innards. Those who are clueful are very busy (with other things, and with real life), and often do not have the time to give direct/constant focus on a single item for long periods of time. I have a mental list of those who are absolutely incredible FreeBSD developers (and I will name one of them: pjd@, who should be given tens of thousands of dollars, IMHO, for his work on bringing ZFS to FreeBSD), but the list is small compared to how many *users* we have. The learning curve for getting familiar with pieces of the FreeBSD kernel is astoundingly large. I myself have tried it on a couple of occasions, but lack of concise and up-to-date documentation makes it very difficult to accomplish. (I'm familiar with very old operating systems, such as MS-DOS, ProDOS, and GS/OS on the Apple IIGS -- FreeBSD is far from those). Books are also not of much help, as I've been told that the existing book which covers FreeBSD engineering models is long outdated and that many pieces now are completely different. A complete and total moral killer right there. The book is for FreeBSD 5.2, by the way. We cannot rely on the FreeBSD Documentation folks to write the necessary docs either, because they do not have the knowledge of the kernel to write such. As someone who's written software, I can assure you that the only way to get good documentation for low-level pieces is to write the documentation in parallel to the code; otherwise, you end up with lots of after-the-fact reverse engineering efforts, which takes tons of time, and requires a lot of communication between the code author(s) and the documenters. We're talking thousands of hours here. Requiring the user/developer to reverse-engineer hundreds of thousands of lines of C code is not reasonable/plausible; hardly anyone is willing to do that for free. This is why Linux often has the upper hand: they have multiple eyes and individuals fully familiar with different pieces of the kernel. If one or two people go on hiatus or disappear (death, life, whatever), the existing kernel piece does not sit in limbo for years -- there are other people to pick up the responsibilities. Much of the FreeBSD kernel and device layer does not have this degree of freedom; much is single-person, single-maintainer, single-point-of-failure. Then there's commercial company support -- by that I mean, actual hardware vendors that support the OS. FreeBSD has some of this, but most are very small companies (few employees), with limited funds, or have very *very* limited/specific focus; there are a couple big ones, but they are few and far between. Linux has hundreds, and many of the vendors are *very* large. In fact, the support is so large that freelance Linux developers are able to get things like development PCI boards for new NICs from the vendors directly; FreeBSD? Rare. What this means is that the commercial world takes Linux seriously, while FreeBSD not so. Sorry, but that's reality. It amazes me how easy someone can pick up programming something in kernel-land for Linux, while for FreeBSD it just doesn't happen on a regular basis. When I see it happen, it's bizarre -- suddenly out of no where comes this one fellow (we'll call him Bob), appearing on a mailing list with a bunch of patches. Heard of him before? Nope, but here he is, and somehow he engineered all of
Re: continuous backup solution for freebsd?
On Monday 06 October 2008 19:07:30 Evren Yurtesen wrote: First of all, I am not an r1soft advocate, but they seem to be making a software which is popular and affordable and interested in giving FreeBSD support... r1soft is not the issue here, the problem is that there is no way to do near continuous backups on FreeBSD servers. Jeremy Chadwick wrote: That said, I'd like to know exactly how low-level R1Soft's software truly is. dump(8), AFAIK, is block-level -- and that's a userland program. Does R1Soft's software *truly* require kernel-land? I have more to say on that issue (not against R1Soft, but speaking with regards to the current state of FreeBSD's developer count) if it truly does. I think you might not have understood the concept of near continuous backups. The R1Soft backup monitors the filesystem operations So does ggate. But read on. So it has to know what is written and when to be able to back it up. The dump command simply reads/writes the blocks. It cant only read changed blocks. It has to read the whole thing (inefficient). But Jeremy's point being, dump(8) does not need /dev/special_device to read/write at block level. Continuous backups as well as bare-metal-restore seem to be a key feature for many hosters. Regarding continuous backups: the GEOM gate class could be used for this. Meaning, I think it could be used as an alternate to R1Soft's software. The GEOM gate allows mirroring to a remote machine, am I not right? That would be more or less same as same as using RAID. The continuous backup (or near continuous) means that you can restore the filesystem to a point like 15 minutes ago, or 1 hour ago. Besides, I hear geom might have network delay problems and it is much more complicated setup to build two machines in mirror configuration just for backup purposes as well as you cant restore to a point in the past. I think once you and R1soft step out of the I need a block level device paradigm, you will see that modifying ggate with a copy and fall through mode, as well as a mechanism to block writes to the local provider, when the remote provider wants to write is the best solution all around and your best bet to get support for it. Right now, ggate does intercept and redirect, but the concept of copy and fall through is not that far away. Bringing the R1soft devs in contact with the FreeBSD geom list and having them browse the sys/geom/ggate sources to see how trivial it is to hook into filesystem operations would be the course of action I'd recommend. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
Sorry for once more but: you can make incremental backups every x minutes with Bacula too .. it only takes one or two minutes on my box to scan for changed files for ~150GB (even faster if you tweak it a bit). It's not really a true continuous backup solution, but it's perfectly possible to restore directories/files for changes which occurred x minutes ago, and with retention periods of x days/months/years. On Mon, 2008-10-06 at 19:38 +0200, Roland Smith wrote: On Mon, Oct 06, 2008 at 12:58:30PM +0300, Evren Yurtesen wrote: Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. I don't think so. The closest thing I know of is rsnapshot (http://www.rsnapshot.org/). My solution is to run rsync in a cron job. In my situation this takes about 5 minutes for approximately 100GB of data. The time it takes will obviously depend on the rate of change in the data. You could also use local snapshots with mksnap_ffs(8), to solve the oh shit I deleted my files situation. Roland ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
Roland Smith wrote: On Mon, Oct 06, 2008 at 12:58:30PM +0300, Evren Yurtesen wrote: Hello, Is there a known continuous backup solution similar to r1soft backup for FreeBSD? I googled a lot but couldnt find anything. I don't think so. The closest thing I know of is rsnapshot (http://www.rsnapshot.org/). My solution is to run rsync in a cron job. In my situation this takes about 5 minutes for approximately 100GB of data. The time it takes will obviously depend on the rate of change in the data. You could also use local snapshots with mksnap_ffs(8), to solve the oh shit I deleted my files situation. Thanks I am using BackupPC for such task already. Although it takes more than 5 minutes to traverse millions of files using rsync independent of if they were changed or not (since rsync has to scan all the files to detect what is changed or not even if it only checks modification times, this takes time for so many files). I just was curious about if anybody could contact r1soft and ask for a pile of money to implement a driver for FreeBSD, since I couldnt do it even if I wanted to :) Thanks, Evren ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
Jeremy Chadwick wrote: What I'm saying is that Linux has the upper hand here. More eyes, more people, more developers, larger community, larger vendor support, and much **much** faster turn-around time on fixes/bugs. We can sit here and argue about those facts all we want (it's the equivalent of doing burn-outs in an AMC Pacer in a parking lot -- wasted time, zero gain), but nothing changes the facts. Sorry, I had to remove the whole bunch of text that you wrote :) but I get the point. I think it is a funny historical fact that BSD was commercially licensed way too long to allow Linux to be developed at first place. If BSD was not commercial at that times, Linus Torvalds probably wouldnt have started writing the Linux kernel. Thus we wouldnt be having this sort of conversation now and it might as well be that Microsoft wouldnt have become so huge. If we look at this from that point of view then eventually all BSD and Linux etc. are bound to disappear in time and Microsoft will stand all alone. But things can change one step at a time. I prefer(or try) to look at this positively. I thought it wouldnt hurt to ask for help if somebody could contact r1soft and perhaps ask a pile of money to develop a driver. It would have been a win-win situation eh? Right. We're definitely talking about snapshots, at least in concept. The fact that you're able to restore data within *minutes* is pretty impressive. I'm curious what sort of disk requirements are needed though (I guess it depends on how often changes happen on the filesystem). Well it is not so fine grained (5 to 10 minutes intervals as mentioned). http://www.r1soft.com/CDP.html (there is more information in the link above, with links to outside sources on the concept such as wikipedia articles etc.) I know some large hosters who use this technology with Linux servers. As a matter of fact the only reason they went with Linux instead of FreeBSD is because they cant get CDP with FreeBSD. I can ask how much space it is using and return back to you. But if you think about it for a second, a traditional backup program would copy the whole file even if there was 1 byte changed in it. Lets say 10mbyte file and 1 byte is changed. R1soft copies only 1 byte. Sure enough the tables can turn around if the filesystem was modified really a lot. But it looks like this type of solution is mostly effective (at least I didnt see anywhere that anybody is complaining that it is using too much disk space yet). The best is, all it would take for FreeBSD users to be able to utilize this technology is a driver to interface with r1soft agent and buy a license. Now I am not expecting anybody to write this for free or nobody is obligated to help. I just dont know anybody who can help so I thought I would drop in a line here so... I for one have never correlated snapshots and backup restorations (bare-metal recovery). I consider them completely separate things, and handled *very* differently. I have a feeling that no one's done this on FreeBSD because the amount of effort required is quite large. Someone did mention HAMMER on DragonflyBSD, but I have no knowledge of it or what it provides -- that said, Matt (Dillon)'s stuff is usually very, very good. I also dont know much about HAMMER either. But it doesnt look like it will make mainstream usage anytime soon on FreeBSD if it ever does. Actually I found a nice document here: http://www.dragonflybsd.org/hammer/hammer.pdf http://www.dragonflybsd.org/hammer/index.shtml It depends on how the filesystem is done. For example, with UFS2+SU snapshots, snapshot generation can take literally hours: completely unreasonable. While with ZFS, snapshot generation usually takes 2-3 seconds -- even on massive changes (e.g. take a snapshot, then rm a 600MB ISO image, then compare present vs. snapshot -- the diff is something like 40KBytes). Yes, but r1soft backup can restore a single file at a consistent state without restoring the whole filesystem from a graphical user interface and can restore mysql databases at a table level. While I agree that there might be different solutions that I dont know about, it just takes a driver to get this functionality on current FreeBSD systems without everybody to change to ZFS or HAMMER. One has to think, would people change their filesystems or install a driver? :) I would rather pay license fee to a backup program and use the driver. The price of the software is very well justified if I can return back to 5min before in my backups. The data I might loose is much more expensive. I'm sorry for sounding anti-FreeBSD, but the reality is that people should use whatever solutions work best for them -- if that's using Windows, Solaris, or Linux, great! Remember that open-source is about choice: and choice means supporting the possibility that someone chooses something else. Blind one-sided advocacy is very damaging to the open-source model and
Re: continuous backup solution for freebsd?
Mel wrote: I think once you and R1soft step out of the I need a block level device paradigm, you will see that modifying ggate with a copy and fall through mode, as well as a mechanism to block writes to the local provider, when the remote provider wants to write is the best solution all around and your best bet to get support for it. Right now, ggate does intercept and redirect, but the concept of copy and fall through is not that far away. Bringing the R1soft devs in contact with the FreeBSD geom list and having them browse the sys/geom/ggate sources to see how trivial it is to hook into filesystem operations would be the course of action I'd recommend. Would it be too much to ask if you can send this information to R1Soft and refer to the post I linked? I just dont think that I can be an efficient gateway of information here :) Thanks, Evren ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: continuous backup solution for freebsd?
rsync via cron or raid? Brian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
