Hello, niedz., 16 paź 2022 o 18:31 Marco Gaiarin <g...@lilliput.linux.it> napisał(a):
> Mandi! Radosław Korzeniewski > In chel di` si favelave... > > >> Ah, simply i put on tape the 'alpha.0' directory, the 'most recent > backup' > >> in rsnapshot lingo. > >> It is marely a folder with all the file within. > > So you are using a tar command for that, right? Then how do you restore > data > > directly from tape? > > No, sorry. 'rsnapshot' is a simple frontend to rsync, that, barely, create > a > folder tree using levels by default at alpha, beta, gamma, ... > rsnapshot use hard links to reduce space on disk. > > So, if i need to put the backup on some media (eg, tape) i can simpy put > 'alpha.0', the most recent backup at the most lower level, instead of the > original content. > > I hope i was clear now. > I never used rsnapshot with tapes, so I'm just curious how you manage it to span multiple tapes? What I know, until you use LTFS, you can't simply store a directory tree on tape and you have to use any type of "tree archival" tool which saves your tree structure in a single archive file - something like "tar". If "alpha.0" is a directory tree, then you can't put it on tape (without LTFS) without an additional translation utility like tar, right? > > > > Virtual Full simply creates the next media and copies all required data > from > > source media (your 3 current media in the pool). > > During copy Bacula skip all files marked as deleted in all Incremental or > > Differential backups. This procedure makes new (Virtual) Full backup > > indistinguishable from backup performed on the backup client. > > I thing i've missed a point here... i've defined as 'Next Pool' the pool > itself, and i think it is not permitted: i need a pool for incremenetal, > and > a pool for the full. Right? > The requirements for separate pools comes from a need to avoid deadlocks where a device which reads a media blocks other devices from writing new virtual full to the same media. Separate pools avoid this kind of deadlock. But I successfully managed virtual full on a single pool for any backup level. Let's assume you have the following backup chain, every backup on single volume, then Virtual full is as simple as: F1 + I1 + I2 = F2 Bacula will create (if file and not already available) a new volume F2 and put all backup data from F1, I1, I2 respecting if it is add/mod/del of the file in incremental. > > > If yes and your network transfer speed is a main limiting factor in this > case > > then the best solution is to make a small first "Full" and gradually add > data > > to backup with incremental or differential levels. > > You mean 'gradually' poking with filesets (eg, today dir 'a', tomorrow dir > 'b') or i can define a job that transfer at most 1GB (for example) and > simply do a (very!) long sequence of incremental job? > > Both are possible solutions, depending on your situation. Unfortunately all require manual operation and management. Radek -- Radosław Korzeniewski rados...@korzeniewski.net
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
