1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<link href="style.css" rel="stylesheet">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
<title>DAR's FEATURES</title>
</head>
<body>
<div class=top>
<img alt="Dar Documentation" src="dar_s_doc.jpg" style="float:left;">
<h1>DAR's FEATURES</h1>
</div>
<p>
This table lists the main
features of dar/libdar tool. For each feature an overview is presented with
some pointers you are welcome to follow for a more detailed
information.
</p>
<table class=lean>
<tr>
<th style="width: 33%">
HARD LINK CONSIDERATION
</th>
<td>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
</td>
</tr>
<tr>
<td colspan=2>
<p>
hard links are properly saved in any case and properly restored if possible. For example, if restoring across
a mounted file system, hard linking will fail, but dar will then
duplicate the inode and file contents, issuing a warning. Hard link
support includes the following inode types: plain files, char devices,
block devices, symlinks (Yes, you can hard link symbolic links! Thanks to Wesley Leggette for the info ;-) )
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">SPARSE FILES
</th>
<td>
references: <a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
--sparse-file-min-size, -ah
</td>
</tr>
<tr>
<td colspan="2">
<p>
By default Dar takes care of sparse files, even if the underlying filesystem does
not support sparse files(!).
</p>
<p>
When a long sequence of zeroed bytes is
met in a file during backup, those are not stored into the backup file but
the number of zeroed bytes is stored instead (structure known as a "hole").
When comes the time to
restore that file, dar restores the normal data but when a hole is met
in the backup, dar directly skips at the position of the data following
that hole. If the underlying filesystem supports sparse files,
this will (re)create a hole in the restored file, making a sparse file.
</p>
<p>
Sparse files can report to be several hundred gigabytes large while they
need only a few bytes of disk space. Not being able to properly save and restore them
can lead to storage waste to hold backups, but also to the impossibility to restore your
data on a disk of the same size.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
EXTENDED ATTRIBUTES (EA)
</th>
<td>
references: <a href="man/index.html">man dar</a><br>
</td>
</tr>
<tr>
<td>
</td>
<td>
keywords: -u -U -am -ae --alter=list-ea
</td>
</tr>
<tr>
<td colspan="2">
<p>
Dar is able to
save and restore EA, all or just those matching a given pattern.
</p>
<p>
File Forks (MacOS X) are implemented over
EA as well as Linux's ACL, they are thus transparently saved, tested,
compared and restored by <i>dar</i>.
Note that ACL under MacOS seem to not rely on EA, thus while they are
marginally used they are ignored by <i>dar</i>
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
FILESYSTEM SPECIFIC ATTRIBUTES (FSA)
</th>
<td>
references: <a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
</td>
<td>
keyword: --fsa-family
</td>
</tr>
<tr>
<td colspan="2">
<p>
Since release 2.5.0 dar is able to take care of filesystem specific
attributes. Those are grouped by family strongly linked to the
filesystem they have been read from, but perpendicularly each FSA is
designated also by a function. This way it is possible to translate FSA
from a filesystem into another filesystem when there is a equivalency
in role.
</p>
<p>
currently two families are present:
</p>
<ul>
<li>HFS+ family contains only one function : the <i>birthtime</i>.
In addition to ctime, mtime and atime, dar can backup, compare and
restore all four dates of a given inode (well, ctime is not possible to
restore).
</li>
<li><i>extX</i> family
contains 12 functions (append_only, compressed, no_dump, immutable,
journaling, secure_deletion, no_tail_merging, undeletable,
noatime_update, synchronous_directory, synchronous_update,
top_of_dir_hierarchy) found on ext2/3/4 and some other Linux
filesystems. Dar can thus save and restore all of those for each file
depending on the capabilities or permissions dar has at restoration
time.
</li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
DIRTY FILES
</th>
<td>
references: <a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
keywords: --dirty-behavior , --retry-on-change<br>
</td>
</tr>
<tr>
<td colspan="2">
<p>
At backup time, dar checks whether each saved file had not changed at the
time it was read. If a file has changed in that situation, dar retries
saving it up to three times (by default) and if it is still changing, is
flagged as "dirty" in the backup, and handled differently from other
files at restoration time. The dirty file handling is either to warn
the user before restoring, to ignore and avoid restoring them, or to ignore
the dirty flag and restore them normally.
</p>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
FILTERS
</th>
<td>
references: <a href="man/index.html">man dar</a> <a href="usage_notes.html#filtering">command line usage notes</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>keywords: -I -X -P -g -[ -] -am --exclude-by-ea
</td>
</tr>
<tr>
<td colspan="2">
<p>
<i>dar</i> is able to backup from a total file system to a single
file, thanks to
its filter mechanism. This one is dual headed: The first head let one
decide which part of a directory tree to consider for the operation
(backup, restoration, etc.) while the second head defines which type of
file to consider (filter only based on filename, like for example the
extension of the file). <br>
</p>
<p>
For backup operation, files and directories can also be filtered out
if they have been set with a given user defined EA.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
NODUMP FLAG
</th>
<td>
references: <a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
keywords: --nodump
</td>
</tr>
<tr>
<td colspan="2">
<p>
Many filesystems, like ext2/3/4 filesystems provide for each inodes a
set of flags, among which is the "<span >nodump</span>" flag. You can
instruct dar to avoid saving files that have this flag set, as does
the so-called <i>dump</i> backup program.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
ONE FILESYSTEM
</th>
<td>
references: <a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
keywords: -M
</td>
</tr>
<tr>
<td colspan="2">
<p>
By default <i>dar</i>
does not stop at filesystems boundaries unless the filtering mechanism
described above excludes a mount point.
But you can also ask dar to avoid recursing into a given filesystem, or
at the opposite a list of filesystems to only recurse into,
without the burden of finding and listing the directories to be
excluded from the backup, which can be even more complicated when
<i>bind mount</i> are used (i.e. a given filesystem mounted several times).
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
CACHE DIRECTORY TAGGING STANDARD
</th>
<td>
references: <a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
keywords: --cache-directory-tagging
</td>
</tr>
<tr>
<td colspan="2">
<p>
Many software use cache directories
(<a href="http://www.mozilla.org/">mozilla web browser</a> for example),
directories where is stored temporaneous data that is not interesting to
backup. The
<a href="http://www.brynosaurus.com/cachedir/">Cache Directory Tagging Standard</a>
provides a standard way for software applications to identify this type
of data, which let dar (like some other backup softwares) ignore cache data designated
as such by other applications.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
DIFFERENTIAL BACKUP
</th>
<td>
references: <a href="man/index.html">man dar</a>/<a href="Tutorial.html">TUTORIAL</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
keywords: -A
</td>
</tr>
<tr>
<td colspan="2">
<p>
When making a backup
with dar, you have the possibility to make a <i>full backup</i> or a
<i>differential backup</i>.
</p>
<p>
A full backup, as expected, makes backup of all
files as specified with the optional filtering mechanisms.
</p>
<p>
Instead, a differential backup, saves
only files that have changed since a given reference backup.
Additionally, files that existed in the reference backup and which do
no more exist at the time of the differential backup are recorded in
the backup as "been removed". At recovery time, (unless
you deactivate it), restoring a
differential backup will update changed files and new files, but also
remove files that have been recorded as "been removed".
</p>
<p>
Note that the
reference backup can be a full backup or another differential backup
(this second method is usually designed as <i>incremental backup</i>).
This way you can make a first full backup, then many incremental
backups, each taking as reference the last backup made, for example.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">DECREMENTAL BACKUP</th>
<td>
references: <a href="man/index.html">man dar</a> /
<a href="usage_notes.html#Decremental_Backup">Decremental backup</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
keywords: -+ -ad
</td>
</tr>
<tr>
<td colspan="2">
<p>
As opposed to <i>incremental backups</i>, where the older one is a
full backup and each subsequent backup contains only the changes
from the previous backup, a <i>decremental backup</i> let the full
backup be the more recent while the older ones only contain changes
compared to the just more recent one.
</p>
<p>
This
has the advantage of providing a single backup to use to restore a whole
system in its latest known state, while reducing the overall amount
of data to retain older versions of files (same amount required as with
differential backup). It has also the advantage to not have to keep
several set of backup as you just need to delete the oldest backup when
you need storage space. However it has the default to require at each
new cycle the creation of a full backup, then the transformation of
the previous full backup into a so-called decremental backup.
Yes, everything has a cost!
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">DELTA BINARY
</th>
<td>
references: <a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>
keywords: --delta sig, --include-delta-sig, --exclude-delta-sig,
--delta-sig-min-size, --delta no-patch
</td>
</tr>
<tr>
<td colspan="2">
<p>
Since release 2.6.0, for incremental and differential backups only,
instead of saving an entire whole file when it has changed, dar/libdar provides
the ability to save only the part that has changed in it. This feature
called binary delta relies on librsync library. It is not activated by
default considering the non null probability of collision between two
different versions of a file. This is also the choice of the dar user
community.
</p>
<p>
However it gives you one step further the differential backup, in terms of
backup space optimization and network data transfer reduction.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
PREVENTING ROOTKITS AND OTHER MALWARES
</th>
<td>
references:<a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>keywords: -asecu
</td>
</tr>
<tr>
<td colspan="2">
<p>
At backup time when a<i> differential, incremental or decremental backup</i>
is done, dar compares the status of inode on the filesystem to the
status they had at the time of the last backup. If the ctime of a file
has changed while no other inode field changed, <i>dar</i> issues a warning
considering that file as suspicious. This does not mean that your
system has been compromised but you are strongly advised to check
whether the concerned file has recently been updated (Some package
manager may lead to that situation) or has its Extended Attributes
changed since last backup was made. In normal situation this type of
warning does not show often (false positive are rare but possible).
However in case your system has been infected by a virus, compromised
by a rootkit or by a trojan, dar will signal the problem if the intruder
tried to hide its forfait.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">DIRECTORY TREE SNAPSHOT</th>
<td>
references: <a href="man/index.html">man dar</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>keywords: -A +<br>
</td>
</tr>
<tr>
<td colspan="2">
<p>
Dar can make a
snapshot of a directory tree and files or even of a whole system,
recording the inode status of
each files. This may be used to detect changes in filesystem, by "diffing" the
resulting snapshot with the filesystem at a later time. The resulting
snapshot can also be used as reference to save files that have changed
since the snapshot has been done.
</p>
<p>
A snapshot is just a special <i>dar</i> backup, that is very small
compared to the corresponding full backup but of course, it cannot be used to
restore any data. As a dar backup, it can be created using compressed, slices,
encryption...
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">SLICES</th>
<td>
references: <a href="man/index.html">man dar</a>/
<a href="Tutorial.html">TUTORIAL</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>keywords: -s -S -p -aSI -abinary</td>
</tr>
<tr>
<td colspan="2">
<p>
Dar stands for Disk
ARchive. From the beginning it was designed to be able to split an
archive (or backup) over several removable media whatever their number is and
whatever their size is. To restore from such a splitted archive, dar
will directly fetch the requested data in the correct slice(s).
<i>dar</i> is suitable for backup over old floppy disk,
CD-R, DVD-R, CD-RW, DVD-RW, Zip, Jazz, but also cloud computing, when
some have restriction on the maximum size a file can have.
</p>
<p>
Given the size, <i>dar</i> will split the archive/backup in several files
(called SLICES), eventually pausing before creating the next one, and/or
allowing the user to automate any action (like un/mount a medium,
burn the file on CD-R, send it to the cloud, and so on)
</p>
<p>
Additionally, the size of the first slice
can be specified separately, if for example you want first to fulfill a
partially filled disk before starting using empty ones. Last, at
restoration time, dar will just pause and prompt the user asking a
slice only if it is missing, and allowing here too user to automate
any particular action (dowloading the slice from the cloud,
mount/unmounting a removable media and so on).
</p>
<p>
You can choose to have either more than one
slice per medium without penalty from dar (no extra user interaction
than asking the user to change the removable media when it has been read),
or just one slice per medium
or even a backup without slice, which is a single file,
depending on your need.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">COMPRESSION</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td>
<br>
</td>
<td>keywords: -z</td>
</tr>
<tr>
<td colspan="2">
<p>
<i>dar</i> can use compression.
Actually gzip, bzip2, lzo, xz/lzma, zstd, lz4 algorithms
are available, and there is still room available for any other
compression algorithm. Note that, compression is made before slicing,
which means that using compression together with slices, will not make
slices smaller, but will probably make less slices in the backup.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">SELECTIVE COMPRESSION </th>
<td>
references: <a href="man/index.html">man dar</a>/
<a href="samples/index.html">samples</a>
</td>
</tr>
<tr>
<td>
<br>
</td>
<td>keywords: -Y -Z -m -am</td>
</tr>
<tr>
<td colspan="2">
<p>
dar can be given a special
filter that determines which files will be compressed or not. This way
you can speed up the backup operation by not trying to compress *.mp3,
*.mpg, *.zip, *.gz and other already compressed files, for example.
Moreover another mechanism allows you to say that files below a given
size (whatever their name is) will not be compressed.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">STRONG ENCRYPTION </th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td>
<br>
</td>
<td>
keywords: -K -J -# -* blowfish, twofish, aes256, serpent256, camellia256, --kdf-param
</td>
</tr>
<tr>
<td colspan="2">
<p>
Dar can use blowfish, twofish, aes256, serpent256 and camellia256 algorithms to encrypt the
whole backup. Two "elastic buffers" are inserted and encrypted with
the rest of the data, one at the beginning and one at the end of the
archive to prevent a clear text attack or codebook attack.
</p>
<p>
For symmetric key encryption several <i>Key Derivation Functions</i> are available, from
the legacy PBKDF2 (PKCS#5 v2) to the modern Argon2 algorithm. The user has the possibility
to set the hash algorithm for the first and the interation count for both algorithms.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">PUBLIC KEY ENCRYPTION</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: -K, --key-length
</td>
</tr>
<tr>
<td colspan="2">
<p>
Encryption based on GPG public key is available. A given backup
can be encrypted for a recipient (or several recipients without
visible overhead) using its public key. Only the recipient(s)
will be able to read such encrypted backup.
</p>
<p>
The advantage over ciphering the backup as a whole is that you don't
have to uncipher it all to extract a particular file or set of file,
which brings a huge gain of CPU usage and execution time.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">PRIVATE KEY SIGNATURE</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: --sign</td>
</tr>
<tr>
<td colspan="2">
<p>
When using encryption with public key it is possible in addition to sign an
archive with your own private key(s). Your recipients can then be sure
the archive has been generated by you, dar will check the signature
validity against the corresponding public key(s) each time the archive
is used (restoration, testing, etc.) and a
warning is issued if signature does not match or key is missing to
verify the signature. You can also have the list of signatories of the archive
while listing the archive content.
<p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tbody>
<tr>
<th style="width: 33%">SLICE HASHING</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>--hash, md5, sha1, sha512, whirlpool</td>
</tr>
<tr>
<td colspan="2">
<p>
When creating a backup, dar can compute an md5, sha1,
sha512 or whirlpool hash before the backup is even written to disk and produce
a small file compatible with md5sum, sha1sum or sha512sum that
let verify that the medium has not corrupted the slices of the backup.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">DATA PROTECTION </th>
<td>
references: <a href="man/index.html">man dar</a> /
<a href="usage_notes.html#Parchive">Parchive integration</a>
</td>
</tr>
<tr>
<td><br></td>
<td>keywords: -al</td>
</tr>
<tr>
<td colspan="2">
<p>
Dar is able to detect corruption in any part of a dar backup,
but it cannot fix it.
</p>
<p>
Dar relies on the <a href="usage_notes.html#Parchive">Parchive</a>
program for data
protection against media errors. Thanks to dar's ability to run user
command or script and thanks to the ad hoc provided scripts, dar can use Parchive
as simply as adding a word (<code>par2</code>) on command-line. Depending on the
context (backup, restoration, testing, ...), dar will by this mean
create parity data for each slice, verify and if necessary repair the
archive slices.
</p>
<p>
Without
Parchive, dar can workaround a corruption, skipping the
concerned file and restoring all others. For some more vital part of the backup files, like the
"catalog" which is the table of contents, dar has the ability to use an
isolated catalog at rescue of the internal catalog of the corrupted backup. It
can also make use of tape marks that are used inside the backup for
sequential reading as a way to overcome catalog corruption. The other
vital information is the slice layout which is
replicated in
each slice and let dar overcome data corruption of that part too. As
a last resort, Dar also
proposes a <i>"lax" mode</i> in
which the user is asked questions (like the compression algorithm used,
...) to help dar recover very corrupted archives and in which, many
sanity checks are turned into warnings instead of aborting the
operation. However this does not
replace using Parchive. This "lax" mode has to be considered as the
last resort
option.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">TRUNCATED ARCHIVE/BACKUP REPARATION</th>
<td>reference: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keyword: -y</td>
</tr>
<tr>
<td colspan="2">
<p>
Since version 2.6.0 an truncated archive (due to lack of disk space, power
outage, or any other reason) can be repaired. A truncated archive lacks
a table of content which is located at the end of the archive, without
it you cannot know what file is saved and where to fetch its data from,
unless you use the sequential reading mode which is slow as it implies
reading the whole archive even for restoring just one file. To allow
sequential reading of an archive, which is suitable for tape media,
some metadata is by default inserted all along the archive. This
metadata is globally the same information that should contain the
missing table fo content, but spread by pieces all along the archive.
Reparing an archive consists of gathering this inlined metadata and
adding it at the end of the repaired archive to allow direct access
mode (default mode) which is fast and efficient.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">DIRECT ACCESS</th>
<td><br></td>
</tr>
<tr>
<td><br></td>
<td></td>
</tr>
<tr>
<td colspan="2">
<p>
Even using compression and/or encryption <i>dar</i> has not
to read the whole backup to extract one file. This way if you just want
to restore one file from a huge backup, the process will be very quick.
Dar first reads the catalogue (i.e. the contents of the
backup), then it goes directly to the location of the saved file(s) you
want to restore and then proceeds to restoration. In particular using slices,
dar will ask only for the slice(s) containing the file(s) to restore.
</p>
<p>
Since version 2.6.0 dar can also read a backup from a remote host by
mean of FTP or SFTP. Here too dar can leverage its direct access
ability to only download the necessary stuff in order to restore some
files from a large backup, or list the backup content and even compare
a set of file with the live filesystem.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">SEQUENTIAL ACCESS</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td>
(suitable for tapes)
</td>
<td>--sequential-read, -at</td>
</tr>
<tr>
<td colspan="2">
<p>
The direct access feature seen above is well adapted to random access media
like disks, but not for tapes. Since release 2.4.0, dar provides a
sequential mode in which dar sequentially read and write archives. It
has the advantage to be efficient with tape but suffers from the same
drawback as tar archive: it is slow to restore a single file from a
huge archive. The second advantage is to be able to repair a truncated
archive (lack of disk space, power outage, ...) as described above.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">MULTI-VOLUME TAPES</th>
<td>references: <a href="man/index.html">man dar_split</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: --sequential-read</td>
</tr>
<tr>
<td colspan="2">
<p>
The independant <i>dar_split </i>program
provides a mean to output <i>dar</i> but also <i>tar</i> archives to several tapes.
If takes care of splitting the archive when writing to tapes and gather
pieces of archive from several tapes for dar/tar to work as if it was a
single pieced archive.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">ARCHIVE/BACKUP TESTING</th>
<td>
references: <a href="man/index.html">man dar</a>
/ <a href="Tutorial.html">TUTORIAL</a> /
<a href="Good_Backup_Practice.html">Good Backup Practice</a>
</td>
</tr>
<tr>
<td><br></td>
<td>keywords: -t</td>
</tr>
<tr>
<td colspan="2">
<p>
thanks to CRC (cyclic redundancy checks), dar is able to detect
data corruption in a backup. Only the file where data corruption
occurred will not be possible to restore, but dar will restore the
others even when compression or encryption (or both) is used.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">ISOLATION</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: -C -A -@</td>
</tr>
<tr>
<td colspan="2">
<p>
The <i>catalogue</i> (i.e.: the contents of a
backup), can be extracted as a copy (this operation is called
<i>isolation</i>) to a small file, that can in turn be used as
reference for differential backup and as rescue of the internal catalogue
(in case of backup corruption).
</p>
<p>
There is then no need to provide a backup to be able to create
a differential backup based on it, just its <i>isolated catalogue</i>
can be used instead. Such an isolated <i>catalogue</i>
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">FLAT RESTORATION </th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: -f</td>
</tr>
<tr>
<td colspan="2">
<p>
It is possible to restore any
file without restoring the directories and subdirectories it was in at
the time of the backup. If this option is activated, all files will be
restored in the (-R) root directory whatever their real position is
recorded inside the backup.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">USER COMMAND BETWEEN SLICES</th>
<td>
references: <a href="man/index.html">man dar dar_slave dar_xform</a> /
<a href="usage_notes.html#command_from_dar">command line usage notes</a>
</td>
</tr>
<tr>
<td><br></td>
<td>keywords: -E -F -~</td>
</tr>
<tr>
<td colspan="2">
<p>
several hooks are provided for dar
to call a given command once a slice has been written or before reading
a slice. Several macros allow the user command or script to know the
requested slice number, path and backup basename.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">
USER COMMAND BEFORE AND AFTER SAVING A DIRECTORY OR A FILE
</th>
<td>references: <a href="man/index.html">man dar</a>
/ <a href="usage_notes.html#command_from_dar">command line usage notes</a>
</td>
</tr>
<tr>
<td><br></td>
<td>keywords: -< -> -=</td>
</tr>
<tr>
<td colspan="2">
<p>
It is possible to define a set of file that will have a command executed
before dar starts saving them and once dar has completed saved them.
Before entering a directory dar will call the specified user command, then it
will proceed to the backup of that directory. Once the whole directory
has been saved, dar will call again the same user command again (with
slightly different arguments) and then continue the backup
process. Such user command may for example run a particular command which
output will be redirected to a file of that directory, suitable for backup.
Another purpose is to force auto-mounting filesystems that else would not be
visible and thus not saved.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">CONFIGURATION FILE </th>
<td>references: <a href="man/index.html">man dar</a> /
<a href="usage_notes.html#user_targets">conditional syntax and user targets</a>
</td>
</tr>
<tr>
<td><br></td>
<td>keywords: -B<br>
</td>
</tr>
<tr>
<td colspan="2">
<p>
dar can read parameters from
file. This is a way to extends the command-line limited length
input. A configuration file can ask dar to read (or to include) other
configuration files. A simple but efficient mechanism forbids a file to
include itself directly or not, and there is no limitation in the
degree of recursion for the inclusion of configuration files.
</p>
<p>
Two special configuration files $HOME/.darrc and /etc/darrc are read if
they exist. They share the same syntax as any configuration file which
is the syntax used on the command-line, eventually completed by
newlines and
comments.
</p>
<p>
Any configuration file can also receive conditional statements, which
describe which options are to be used in different conditions.
Conditions are: "extract", "listing", "test", "diff", "create",
"isolate", "merge", "reference", "auxiliary", "all", "default" (which may be
useful in case or recursive inclusion of files) ... more about their
meaning and use cases in dar man page.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">REMOTE OPERATIONS</th>
<td>
references: <a href="usage_notes.html#dar_remote">command line usage notes</a>
/ <a href="man/index.html">man dar/dar_slave/dar_xform</a>
</td>
</tr>
<tr>
<td><br></td>
<td>keywords: -i -o - -afile-auth</td>
</tr>
<tr>
<td colspan="2">
<p>
dar is able to read and write a backup to a remote server in
three different ways:
</p>
<ol>
<li>
<i>dar</i> is able to produce an
backup to its standard output or to a named pipe and is able to read
a backup from its standard input or from a named pipe
</li>
<li>
if the previous approach is fine to write down a backup over
the network (through an ssh session for example), reading
from a remote sever that way (using a single pipe) requires dar to read
the whole backup which may be inefficient to just restore a
single file. For that reason, dar is also able to read
a backup through a <i>pair of pipes</i> (or named pipes)
using <i>dar_slave </i> at the other side of the pipes. From
the pair of pipes, one pipe let dar asking to
dar_slave which portion of the backup file it has to send through
the other pipe. This makes a remote restoration much more
efficient and still allows these bidirectional exchanges
to be encrypted over the network, simply running dar_slave
through an ssh session.
</li>
<li>
last, since release 2.6.0 dar can make use FTP or SFTP protocols to
read or write a backup from or to a remote server. This method does
not rely on anonymous or named pipes, is as efficient as option 2 for
reading a remote backup and is compatible with slicing and slice
hashing. however this option is restricted to these two network
protocols: FTP (low CPU usage but insecure) SFTP (secure)
</li>
</ol>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">DAR MANAGER</th>
<td>references: <a href="man/index.html">man dar_manager</a></td>
</tr>
<tr>
<td><br></td>
<td><br></td>
</tr>
<tr>
<td colspan="2">
<p>
The advantage of differential
backup is that it takes much less space to store and time to complete
than always making full backup. But, in the other hand, it may lead you having a
lot of them due to the reduces space requirements. Then if you want to restore a particular file, you may
spend time to figure out in which backup is located the most recent version.
To solve this, <i>dar_manager</i> gathers contents information of all your backups into a database
(a <i>Dar Manager Database</i> which ends as a single file). At restoration
time, it will call dar for you to restore the asked file(s) from the
proper backup.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">RE-SHAPE SLICES OF AN EXISTING ARCHIVE/BACKUP</th>
<td>references: <a href="man/index.html">man dar_xform</a></td>
</tr>
<tr>
<td><br></td>
<td><br></td>
</tr>
<tr>
<td colspan="2">
<p>
The provided program named <i>dar_xform</i> is able to change
the size of slices of a given backup. The resulting backup
is totally identical to the one directly created by dar. Source
backup can be taken from a set of slice, from standard input or
even a named pipe. Note that dar_xform can work on encrypted
and/or compressed data without having to decompress or even
decrypt it.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">ARCHIVE/BACKUP MERGING</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: -+ -ak -A -@</td>
</tr>
<tr>
<td colspan="2">
<p>
From version 2.3.0, dar supports the merging of two
existing archives into a single one. This merging operation is assorted by
the same filtering mechanism used for archive creation. This let the
user define which file will be part of the resulting archive.
</p>
<p>
By extension, archive merging can also take as single source archive
as input. This may sound a bit strange at first, but this let you make
a subset of a given archive without having to extract any file to disk.
In particular, if your filesystem does not support Extended Attributes
(EA), thanks to this feature you can still cleanup an archive from
files you do not want to keep anymore without loosing any EA or
performing any change to standard file attributes (like modification
dates for example) of files that will stay in the resulting archive.
</p>
<p>
Last, this merging feature give you also the opportunity to change the
compression level or algorithm used as well as the encryption algorithm
and passphrase. Of course, from a pair of source archive you can do all
these sub features at the same time: filtering out files you do not
want in the resulting archive, use a different compression level and
algorithm or encryption password and algorithm than the source
archive(s), you may also have a different archive slicing or no slicing
at all (well <i>dar_xform</i> is more efficient for this feature
only, see above "<i>RE-SHAPE SLICES OF AN EXISTING ARCHIVE/BACKUP</i>"
for details).
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">ARCHIVE SUBSETTING</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: -+ -ak</td>
</tr>
<tr>
<td colspan="2">
<p>
As seen above under the "archive merging" feature description,
it is possible to define a subset of files from an archive and put them into
a new archive without having to really extract these files to disk.
To speed up the process, it is also possible to avoid uncompressing/recompressing
files that are kept in the resulting archive or change their compression,
as well change the encryption scheme used. Last, you may manipulate this
way files and their EA while you don't have EA support available on your system.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">DRY-RUN EXECUTION</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: -e</td>
</tr>
<tr>
<td colspan="2">
<p>
You can run any feature without effectively performing the action.
Dar will report any problem but will not create, remove or modify
any file.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">ARCHIVE/BACKUP USER COMMENTS</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: --user-comment, -l -v, -l -q</td>
</tr>
<tr>
<td colspan="2">
<p>
The backup header can hold a message from the user. This message
is never ciphered nor compressed and always available to any one listing
the archive summary (-l and -q options). Several macro are available to
add more confort using this option, like the current date, uid and gid,
hostname, and command-line used at backup creation.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">PADDED ZEROS TO SLICE NUMBER</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: --min-digits</td>
</tr>
<tr>
<td colspan="2">
<p>
Dar slice are numbered by integers starting by 1. Which makes filename of
the following form: archive.1.dar, archive.2.dar, ..., archive.10.dar,
etc. However, the lexicographical order used by many directory listing
tools, is not adapted to show the slices in order. For that reason, dar
let the user define how much zeros to add in the slice numbers to have
usual file browsers listing slices as expected. For example, with 3 as
minimum digit, the slice name would become: archive.001.dar,
archive.002.dar, ... archive.010.dar.
</p>
</td>
</tr>
</table>
<br>
<br>
<table class=lean>
<tr>
<th style="width: 33%">MULTI-THREADING</th>
<td>references: <a href="man/index.html">man dar</a></td>
</tr>
<tr>
<td><br></td>
<td>keywords: --multi-thread</td>
</tr>
<tr>
<td colspan="2">
<p>
Since release 2.7.0, compression can use several threads when the new
compression per block is used (by opposition to the streaming
compression used so far, which is still available).
Encryption can also be processed with multiple threads even for
old backups (no change at encryption level). The user defines the
number of threads he wants for each process,
compression/decompression as well as ciphering/deciphering.
</p>
</td>
</tr>
</table>
</body>
</html>
|
