|
From: Tobias <spe...@gm...> - 2014-06-02 17:27:32
|
Hi Denis, thank you very much for your explanation, that's what I was thinking about. In conclusion I would say the most important points are: 1) the user should not even notice that the backup is running 2) daily backup 3) system wide managed backup of /home (e.g. backup.servce) and user wide managed backup of /home/user (e.g. ba...@us..., when using systemd) As btrfs is getting stable and is available within the most distros, I would like to take advantage from the snapshot feature (only as an option, to don't wont to brake compatibility with the ext filesystem). It allows to freeze the actual filsystem and mount it somewhere. This allows me to create a consistent backup while the user is working. When it comes to restore, there is another cool feature of btrfs. You can restore the backup to a new subvolume and make this to the new default volume when the filsystem is remounted (e.g. after a reboot). So you don't get in conflict with open file handlers. To get a better feeling about the performance of inc vs diff backup I'm extending my python backup script (it just calls dar CLI) to use both methods and write a report to compare these to techniques. Within this I also so want to test the dar_manager database. As fare as I have results I will send them on the mailing list. Regards, Tobias Am Samstag, den 24.05.2014, 10:30 +0200 schrieb Denis Corbin: > On 24/05/2014 01:08, Tobias Specht wrote: > > Hi Denis, > > Hi Tobias, > > > > > my plan is to release version 1.0 as soon as possible. I only want > > to improve stability. Then I can commit gdar to the official > > package repositories of the major Linux distributions, so that it > > will be easy to install gdar. To release a new version won't be > > that difficult then. > > OK, now I understand better what you want to do. > > > > > Version 2.0 will be all about creating a backup. As gdar is a GUI > > application the main target will be a Desktop system, especially > > for those users who are not that experienced with Linux. It > > shouldn't be just a GUI that provides all features of dar, like the > > dar CLI but with a graphical interface. > > Right, some libdar features are not very needed by GUI like gdar. > > > Rather then it should guide the user though the process of creating > > a backup schedule and for example manage the referencing backup > > when creating incremental backups based on the schedule. > > That's interesting and makes sense. If I properly understand your > idea, doing regular backup through a GUI is a constraint a user may > skip or forget. cron/fcron/other scheduling is a better choice as it > makes the backup process transparent and configured once and for all. > Having a GUI for programming it is the perfect target, as you > mentioned for users that are not that experienced with Linux. Do I > understand correctly the direction you follow? > > > About the details I'm currently not sure and would like to get some > > other opinions: * the backup source would be /home or /home/bob > Depends to whom it addresses. If it is most common that one user (home > user) manages a computer for the others (the rest of the family for > example) it makes sense to propose /home as default choice. But > implies some privileges to run the backup as. > > > * the backup destination should be a external HD > Right, not the same disk if you want the backup be available in case > of crash disk. > > > * full backup frequency one of > > yearly/quarterly/monthly/weekly/daily > IMHO, quarterly basis for full backup is a good compromise between > security and work load (I mean the time the computer will be loaded to > create the full backup, which may be annoying when doing other thing > with the computer). It also allows longer data retention without > wasting disk space. However, in CLI the use of "ionice -c 3 nice -n 19 > dar ..." leverage low priority facilities provided by the system to > make the backup process quite invisible to the user. > > > * differential/incremental one of > > yearly/quarterly/monthly/weekly/daily > Seen my current usage at home, doing incremental backups tend to save > at each cycle the same data that change often, while a lot of the rest > do not change often. For home directories, IMHO, a differential backup > seems more interesting. The other point is that it makes the > restoration more simple and quicker (restore the full backup then the > last differential backup). > For the frequency, IMHO, daily backup (or maybe weekly but not > larger): Users do not want to loose the most precious data they have > at current time: the one they are working on. > > > * when it's time for a backup, the user will be queried to start > > the process * when should the backup be executed? * at the > > beginning (fix date, not depending on when the backup has been > > started the last time. e.g. 1th of month) * or after the period has > > expired (variable date, depending on when the backup has been > > started the last time) > Having a fixed time for the backup in particular on laptops which are > powered on at random time makes it difficult to define what time is > better than another. In the other hand there is some asynchronous > scheduling features in fcron or anacron (but not in cron) that let the > scheduling take place once a day/week/month. The backup will then > start as soon the laptop is powered on if it is a newer day/week/month > than the day the previous backup ran. > > > * all the specific settings should only be visible in some advanced > > mode * a one-click setup would be nice > 100% agreed > > > > > I'm not sure if this is the right place to discuss this, but I'm > > happy on every input I can get. > It is *a* right place, but there is not many active users on the today > 60 subscribed ones in this mailing-list. > > You may try asking on dar-support, which has a larger audience, asking > for support about dar way of use stays in topic :-) ... and all that > applies to dar about backup scheduling, backup perimeter (/home, ...), > backup location, and so on, also applies to gdar :-) > > > > > Regards, Tobias > > > > Regards, > Denis. > ------------------------------------------------------------------------------ |
